App-Prototyping: Vom Wireframe zum Clickdummy in 5 Tagen

Die teuersten Fehler in der App-Entwicklung passieren nicht beim Programmieren - sie passieren davor. Ein Feature, das niemand braucht. Eine Navigation, die niemand versteht. Ein Workflow, der in der Theorie logisch war und in der Praxis scheitert.

Ein Prototyp deckt diese Fehler auf, bevor eine Zeile Code geschrieben wird. Der Kernprozess dauert 5 Tage, mit Nutzertests und Iteration realistisch 5-7 Tage. Verglichen mit 3 Monaten Fehlentwicklung ist das nichts.

---

Für Entscheider: Warum Prototyping Geld spart

Das eigentliche Problem

Ohne Prototyp entsteht ein Vakuum zwischen Briefing und fertigem Produkt. Auftraggeber beschreiben, was sie wollen. Entwickler bauen, was sie verstehen. Am Ende passt beides nicht zusammen - und der teure Umbau beginnt.

Ein Prototyp schließt dieses Vakuum. Sie sehen und klicken Ihre App, bevor sie gebaut wird. Missverständnisse fallen in der Prototyping-Phase auf - nicht nach 3 Monaten Entwicklung.

Was ein Prototyp kostet vs. was er spart

Phase	Ohne Prototyp	Mit Prototyp
Konzept	Textbriefing, PowerPoint	Klickbarer Prototyp, testbar mit echten Nutzern
Entwicklung	Features werden gebaut, dann verworfen	Nur validierte Features werden entwickelt
Änderungen	Teuer (Code umschreiben)	Günstig (Screens verschieben)
Timeline	+5 Tage Prototyping	-2 bis -6 Wochen Nacharbeit

Typische Größenordnung bei einem mittleren App-Projekt (reine Design-Arbeit, bei 120 €/h):

Umfang	Aufwand	Kosten
Wireframes (10-15 Screens)	2-3 Tage	1.900-2.900 €
Clickdummy (interaktiv, testbar)	4-5 Tage	3.800-4.800 €
High-Fidelity-Prototyp (pixelgenau)	7-10 Tage	6.700-9.600 €

Dazu kommen Stakeholder-Abstimmungen (1-2 Tage), Nutzertests und Iterationen nach dem Test (1-2 Tage). Realistisch für einen Clickdummy inkl. Test und Iteration: 6-8 Tage. Der tatsächliche Aufwand hängt von Screen-Anzahl, Abstimmungsschleifen, Zielgruppe und Testtiefe ab.

Das klingt nach einer Zusatzausgabe. Ist es aber nicht. Schon ein einziges fehlgeleitet entwickeltes Feature kann mehr kosten als der gesamte Prototyp.

---

Die drei Stufen des App-Prototyping

Stufe 1: Wireframes (Low Fidelity)

Grobe Skizzen der Screens - ohne Farben, ohne echte Bilder, ohne Designdetails. Nur Struktur und Informationshierarchie.

Wann Wireframes reichen:

• Erste Abstimmung mit dem Kunden: “Ist das die richtige Richtung?”
• Interne Klärung: Welche Screens brauchen wir überhaupt?
• Navigation festlegen: Wie kommt der Nutzer von A nach B?

Was Wireframes NICHT können: Nutzer emotional abholen. Ein grauer Kasten mit “Bild hier” sagt nichts über die Wirkung der fertigen App.

Stufe 2: Clickdummy (Mid Fidelity)

Interaktiver Prototyp - Screens sind verlinkt, Buttons reagieren, Übergänge sind sichtbar. Der Nutzer kann die App “durchklicken”, ohne dass im Hintergrund etwas passiert.

Wann ein Clickdummy nötig ist:

• Nutzertests mit echten Zielgruppen: “Finden die Nutzer den Checkout?”
• Stakeholder-Präsentation: “So wird die App aussehen und sich anfühlen”
• Investoren-Pitch: Ein klickbarer Prototyp überzeugt mehr als eine PowerPoint

Der Clickdummy ist der Sweet Spot. Aufwand überschaubar (4-5 Tage), Erkenntnisgewinn enorm. Die meisten Usability-Probleme fallen hier bereits auf.

Stufe 3: High-Fidelity-Prototyp

Pixelgenaues Design, echte Inhalte, Animationen, Micro-Interactions. Sieht aus und fühlt sich an wie die fertige App - ist aber kein Code.

Wann High Fidelity nötig ist:

• Design-System wird parallel entwickelt (Farben, Typo, Komponenten)
• Entwickler brauchen exakte Spezifikationen (Abstände, Größen, Zustände)
• App soll vor Launch an Testkunden gezeigt werden

Wann High Fidelity Overkill ist: Bei MVPs. Wenn Sie noch herausfinden, ob die Idee funktioniert, brauchen Sie keinen pixelgenauen Prototyp. Ein Clickdummy reicht.

---

App-Prototyping-Tools: Was wann passt

Tool	Stärke	Kosten	Wann einsetzen
Figma	Branchenstandard, kollaborativ, Developer Handoff	Kostenlos (Starter), ab 15 €/Monat	Fast immer die richtige Wahl
Balsamiq	Absichtlich “skizzenhaft”, verhindert Design-Diskussionen	Ab 9 €/Monat	Stakeholder diskutieren zu früh über Farben
Whimsical	Schnelle Wireframes + Flowcharts	Kostenlos (Starter)	Schnelle Iterationen mit vielen Beteiligten
Sketch	Etabliert im Apple-Ökosystem	Ab 10 €/Monat	Wenn das Team bereits damit arbeitet
Papier + Stift	Schnellste Methode für erste Ideen	0 €	Immer als erster Schritt

Meine Empfehlung: Papier → Figma. Ein separates Wireframe-Tool lohnt sich nur in zwei Fällen: Stakeholder neigen zu frühen Design-Diskussionen (Balsamiq verhindert das durch den absichtlich skizzenhaften Look) oder Sie brauchen schnelle Iterations-Runden mit vielen Beteiligten (Whimsical).

Warum Figma Standard ist

Vier Gründe: Prototyping direkt im Design-Tool (kein Toolwechsel), auf echten Geräten testbar (QR-Code scannen, läuft im Browser), Echtzeit-Kollaboration (Kunde schaut live mit), Developer Handoff (Entwickler lesen Abstände und Assets direkt aus Figma).

Unterschätzter Vorteil: Figma-Prototypen auf dem echten Smartphone fühlen sich so realistisch an, dass Testpersonen oft vergessen, dass es kein echtes Produkt ist.

---

Nutzertests mit dem Prototyp

Warum testen - und wie viele Nutzer reichen

Ein Prototyp ohne Nutzertest ist nur ein hübsches Mockup. Sie haben etwas gebaut, aber keine Ahnung, ob es funktioniert.

Faustregel: 5-8 Testpersonen decken die meisten kritischen Usability-Probleme auf. Jakob Nielsens bekannte “5 Nutzer reichen”-Regel gilt vor allem für homogene Nutzergruppen und einfache Tasks. Bei komplexen Apps oder diversen Zielgruppen (z.B. Sachbearbeiter UND Geschäftsführer) planen Sie eher 10-12 Personen ein.

So läuft ein Nutzertest ab

Aufgabe stellen, beobachten, nicht helfen. Testpersonen aus der echten Zielgruppe, nicht aus dem eigenen Team.

Wichtig: Aufgaben statt Meinungen.

• Falsch: “Findest du die App intuitiv?”
• Richtig: “Bestelle das blaue T-Shirt in Größe M und schließe die Zahlung ab.”

Wenn 3 von 5 Personen am Checkout scheitern, ist der Checkout kaputt - egal was sie auf Nachfrage sagen.

Was Sie beobachten sollten:

Signal	Bedeutung	Aktion
Person sucht “Jetzt kaufen”-Button	Button geht im Content unter	Kontrast erhöhen, hervorheben
Person klickt “zurück” nach Produktdetails	Erwartet Warenkorb, nicht Liste	”In den Warenkorb” prominenter
Person fragt “Wurde es gespeichert?”	Feedback fehlt	Toast-Notification einbauen
Person überspringt Filterleiste	Feature nicht verstanden	Vereinfachen oder entfernen

---

App-Prototyp erstellen: Der 5-Tage-Fahrplan

Tag 1: Verstehen

• Zielgruppe definieren (wer nutzt die App, in welcher Situation?)
• Kern-Use-Cases identifizieren (was sind die 3-5 wichtigsten Aktionen?)
• Bestehende Lösungen analysieren (was macht die Konkurrenz gut/schlecht?)

Tag 2: Skizzieren

• Papier-Wireframes für alle Kern-Screens (10-15 Screens)
• User-Flow zeichnen: Wie gelangt der Nutzer von Start bis Ziel?
• Entscheidungen festhalten: Was zeigen wir auf dem Startscreen?

Tag 3-4: Clickdummy bauen

• Screens in Figma aufbauen (Mid Fidelity - erkennbar, aber kein Pixel-Polishing)
• Interaktionen verlinken (Button → nächster Screen)
• Zustände definieren (leere Liste, Fehlermeldung, Erfolg)
• Auf echtem Gerät testen (Figma-Prototyp per QR-Code auf Smartphone)

Tag 5: Testen und auswerten

• 3-5 Nutzertests durchführen (Testpersonen vorher rekrutiert - Rekrutierung braucht 2-3 Tage Vorlauf, parallel zu Tag 1-4)
• Zwischen den Tests 30 Minuten Pause für Notizen
• Auswertung: Was funktioniert, was nicht?
• Priorisieren: Was muss vor der Entwicklung geändert werden?

Tag 6-7 (optional): Iteration

• Kritische Probleme aus den Nutzertests im Prototyp umsetzen
• Bei Bedarf 2-3 Nachtests mit neuen Personen

Ergebnis nach 5-7 Tagen: Ein getesteter und iterierter Clickdummy, eine Liste validierter Features und eine klare Grundlage für die Entwicklung.

---

Prototyp vs. MVP: Wo liegt die Grenze?

	Prototyp	MVP
Zweck	Idee validieren, UX testen	Produkt am Markt testen
Funktioniert	Nein (Klick-Simulation)	Ja (echte Funktionen, echte Daten)
Nutzer	Testpersonen (5-10)	Echte Kunden
Aufwand	5-10 Tage	3-6 Monate
Kosten	2.000-10.000 €	30.000-80.000 € (einfache bis mittlere App)

Der Prototyp kommt vor dem MVP. Er beantwortet die Frage “Ist die Idee und die UX richtig?” - bevor Sie 3 Monate in die Entwicklung investieren. Der MVP beantwortet dann “Zahlen Kunden dafür?”

Wer den Prototyp überspringt, baut oft ein MVP, das technisch funktioniert, aber an den Nutzern vorbei geht. Der Umbau kostet dann mehr als der Prototyp gekostet hätte.

---

Die 6 häufigsten Prototyping-Fehler

1. Zu früh ins Detail gehen

Pixel-perfekte Designs in der ersten Woche führen zu endlosen Designdiskussionen. Erst Struktur, dann Schönheit. Wireframes klären die Richtung, High Fidelity kommt danach.

2. Mit dem eigenen Team testen

Kollegen kennen die App-Idee, das Vokabular, den Kontext. Sie finden alles intuitiv - echte Nutzer nicht. Testen Sie mit Personen, die Ihre App noch nie gesehen haben.

3. Zu viele Features prototypen

40-Screen-Prototyp mit 15 Features gebaut. Kunde sieht das Ergebnis und will die Hälfte anders. 2 Wochen Design-Arbeit umsonst. Fokus auf die 3-5 Kern-Use-Cases. Den Rest können Sie später validieren.

4. Lorem Ipsum statt echter Inhalte

Prototyp mit Platzhalter-Texten getestet. Testperson versteht das Konzept nicht, weil überall “Lorem ipsum dolor sit amet” steht. Nutzen Sie echte (oder realistische) Inhalte - sonst testen Sie die Lesefähigkeit Ihrer Nutzer, nicht die UX.

5. Nur am Desktop getestet

Prototyp sieht am 27-Zoll-Monitor perfekt aus. Auf dem Smartphone: Button zu klein, Text zu lang, Scrollen ohne Ende. Testen Sie immer auf dem Gerät, auf dem die App primär genutzt wird.

6. Keinen Prototyp machen

“Wir wissen ja, was wir wollen.” Das sagt jedes Team vor der Entwicklung. Und jedes Team entdeckt während der Entwicklung Features, die niemand braucht, und Lücken, die niemand bedacht hat. 5-7 Tage Prototyping können Wochen Nacharbeit verhindern.

---

Checkliste: Bereit für die App-Entwicklung?

• Kern-Use-Cases definiert? (Die 3-5 wichtigsten Aktionen, nicht 20)
• Clickdummy gebaut und auf echtem Gerät getestet?
• Nutzertests mit mindestens 5 Personen aus der Zielgruppe durchgeführt?
• Ergebnisse eingearbeitet? (Nicht nur dokumentiert, sondern im Prototyp umgesetzt)
• Auf echten Geräten getestet? (Desktop-Prototyp ≠ Mobile-Erfahrung)
• Edge Cases bedacht? (Leere Liste, Fehlermeldung, kein Internet)
• Technische Machbarkeit geprüft? (Prototyp mit Entwickler besprochen)
• Stakeholder-Freigabe auf Basis des Prototyps, nicht auf Basis eines Textbriefings?
• Scope klar? Was ist im MVP, was kommt später?

Bei zwei oder mehr fehlenden Punkten lohnt sich ein Prototyping-Sprint. Ich entwickle mit Ihnen in 5 Tagen einen getesteten Clickdummy - bevor die erste Zeile Code geschrieben wird. Kostenloses Erstgespräch anfragen.