Spec vs. Prototyp — was wann besser validiert

In der Konzept-Phase einer App-Entwicklung steht eine Frage im Raum, die viele Teams falsch beantworten: schreiben wir eine Spec oder bauen wir einen Prototyp? Beide sind Werkzeuge für unterschiedliche Probleme. Eine Spec ist schnell zu schreiben und schnell zu revidieren, aber langsam zu validieren — ein Prototyp ist umgekehrt. Welches Artefakt wann besser trägt, ist keine Geschmacksfrage, sondern eine Eigenschaft des Problems.

Was Spec und Prototyp jeweils leisten

Drei Eigenschaften, die das Verhältnis erklären:

• Spec (geschriebenes Dokument). Schnell zu schreiben (1–3 Tage pro Use-Case), schnell zu revidieren, gut zur Klärung von Logik, Datenflüssen und Edge-Cases. Schwach in der Validierung — ein gelesenes Dokument liefert kein echtes Nutzungs-Signal.
• Prototyp (klickbares Mockup oder funktionierender V0). Langsam zu bauen (1–2 Wochen pro Use-Case-Strecke), langsam zu revidieren, stark in der Validierung — Endkunden klicken tatsächlich, das Verhalten ist beobachtbar.
• Spec liest der Auftraggeber, Prototyp benutzt der Endkunde. Das ist der entscheidende Unterschied. Ein gut gelesenes Dokument ist kein gut benutztes Produkt.

Wer beide Werkzeuge gleichbehandelt, optimiert die falsche Achse. Mehr zur Phase, in der diese Entscheidung fällt, im Sub-Guide Discovery vs. Sprint Zero.

Wann eine Spec reicht

Drei Konstellationen, in denen eine ordentliche Spec genügt:

1. Bekannte Use-Case-Klasse. Ein Login-Flow ist tausendfach geklärt — du brauchst keinen Prototyp, um zu wissen, ob „Email plus Passwort plus 2FA” funktioniert. Ein Absatz Spec reicht.
2. Internes Tool für definierten Nutzerkreis. 15 Mitarbeiter:innen mit klar dokumentiertem Workflow brauchen keinen Validierungs-Prototyp — sie sind die Spec.
3. Backend-lastige Architektur ohne UI-Risiko. Datenmodelle, API-Verträge, Auth-Logik werden in Spec geklärt. Der UI-Teil wird oft erst in der Build-Phase prototypisch entwickelt.

Eine gute Spec deckt pro Use-Case fünf Punkte ab: Auslöser, Vorbedingungen, Schritte, erwartetes Ergebnis, Edge-Cases. Wer das in zwei bis drei Seiten pro Use-Case zusammenkriegt, hat ausreichend Tiefe für den Build-Start.

Wann ein Prototyp nötig ist

Genauso klar: drei Konstellationen, in denen eine Spec allein nicht trägt.

• Neuer Workflow ohne Vorbild. Wenn die App einen Endkunden-Workflow einführt, den es so noch nirgends gibt — ein neuer Buchungs-Pfad, eine ungewöhnliche Datenvisualisierung, ein eigenes Onboarding-Konzept — kann nur ein Prototyp zeigen, ob er intuitiv ist. Spec liest sich gut, Prototyp klickt sich daneben.
• Hochwertiges Endkunden-Erlebnis. B2C-Apps, Premium-B2B-Tools, Apps mit Marketing-Anteil. Wenn das wahrgenommene Niveau Teil des Produkts ist, gehört eine UX-Validierung in die Konzept-Phase — nicht in V1.5.
• Mehrere Stakeholder mit konkurrierenden Bildern. Geschäftsführung sieht A, Vertrieb sieht B, Endkunde sieht C. Eine Spec macht den Konflikt nicht sichtbar — ein Prototyp tut es. Drei Klicks zeigen, wer was wirklich gemeint hat.

Ein Prototyp muss nicht perfekt sein. Ein klickbarer Figma-Flow oder ein Bubble-V0 mit drei Use-Cases reicht — siehe Custom-Dev vs. No-Code/Low-Code für die No-Code-Variante als Prototyp-Pfad.

Hybrid: Spec für Foundation, Prototyp für die kritischen Flows

In den meisten Projekten ist die Antwort nicht „Spec oder Prototyp”, sondern beides — jeweils dort, wo das jeweilige Werkzeug stärker ist. Die saubere Aufteilung:

• Spec für die Foundation. Datenmodell, Auth-Architektur, Edge-Cases, API-Verträge, DSGVO-Bestandsaufnahme. Schreiben, lesen, durchgehen, freigeben.
• Prototyp für die zwei bis drei kritischen Flows. Onboarding, der eine Workflow, an dem das Wertversprechen hängt, eine ungewöhnliche Datenvisualisierung. Klicken lassen, beobachten, revidieren.
• Wegwerfbarkeit als Eigenschaft. Der Prototyp ist nicht der V0 der App. Er wird gebaut, um eine Hypothese zu testen — und nach dem Test gelöscht. Wer den Prototyp zur App weiterentwickelt, baut auf einem Fundament, das nie für Produktion gedacht war.

Hybrid hat einen weiteren Vorteil: er macht die Discovery-Phase ehrlicher. Was sich auf Papier gut liest, kollidiert in der Klick-Strecke häufig mit der Realität — und genau diese Kollisionen sparst du dir in V1, wenn sie in der Discovery passieren. Mehr zur Discovery selbst im Sub-Guide Discovery vs. Sprint Zero.

Drei Anti-Pattern in der Praxis

Häufige Fehler, in beide Richtungen:

• 80-Seiten-Spec ohne Prototyp. Das Dokument wird abgenommen, der Build startet, in Woche 4 zeigt der erste klickbare Stand, dass die zentrale UX nicht funktioniert. Der Build wird umgebaut, die Spec ist Makulatur. Symptom: zu viel Vertrauen in das geschriebene Wort, zu wenig in tatsächliches Verhalten.
• Hochpolierter Prototyp für Standard-Use-Cases. Drei Wochen Figma-Arbeit für einen Login-Flow, der in jeder zweiten App identisch ist. Symptom: Validierung an der falschen Stelle, weil sich Mockups bauen besser anfühlt als Spec schreiben.
• Prototyp wird zur App. Bubble-Pilot validiert die Hypothese, das Team beschließt, „direkt darauf aufzubauen” statt einen sauberen Custom-Build zu starten. Drei Reißpunkte später ist die Architektur kaputt — ein dokumentierter Verlauf, den wir im Sub-Guide Custom-Dev vs. No-Code/Low-Code aufschlüsseln.

In allen drei Fällen wird das falsche Werkzeug für das richtige Problem eingesetzt. Wer Spec und Prototyp als Werkzeuge für unterschiedliche Risiken versteht, vermeidet alle drei.

Wer wann welches Artefakt braucht

Eine kurze Heuristik, die in den meisten Projekten trägt:

• Auftraggeber mit klarem Lastenheft, bekanntem Use-Case-Spektrum → Spec reicht.
• Erst-App-Auftraggeber, neuer Endkunden-Workflow, mehrere Stakeholder → Hybrid.
• B2C-App mit Marketing-Anspruch, hochwertige UX als Wertversprechen → Hybrid mit Prototyp-Schwerpunkt.
• Internes Tool, kleines Nutzerfeld, etablierter Workflow → Spec mit Walkthrough am Whiteboard.

Wenn du gerade entscheidest, was deine Konzept-Phase liefern soll: beschreib uns die Situation in drei Sätzen — was die App tun soll, ob es Vorbilder gibt, wie viele Stakeholder mitreden — über das Kontaktformular. Wir antworten in 24 Stunden mit einer ehrlichen Empfehlung, welches Artefakt sich bei dir rechnet. Mehr Kontext: Discovery vs. Sprint Zero für die Phase, in der diese Entscheidung fällt, MVP oder direkt komplett für den Scope-Schnitt danach.