Wer eine App entwickeln lässt, versteht unter App-Design oft den Schritt, in dem die App „schön gemacht“ wird. Tatsächlich fallen in dieser Phase die Entscheidungen, die den weiteren Aufwand bestimmen: welche Aufgaben die App löst, in welcher Reihenfolge Nutzer durch die Screens gehen, was bei einem Fehler oder ohne Netz passiert. Eine Änderung am Wireframe ist schnell gemacht. Nach der Programmierung betrifft dieselbe Änderung Code, Tests und oft auch das Backend.
Dieser Beitrag beschreibt die sechs Phasen, ihre Ergebnisse, die Freigaben und den realistischen Aufwand für ein typisches Mittelstandsprojekt. Markenentwicklung und die Gestaltung der Store-Einträge sind nicht Teil davon; für Letzteres gibt es den Beitrag über App-Store-Review und ASO.
Wireframe, Mockup, Klickdummy: die Begriffe
Im App-Design werden vier Begriffe häufig synonym verwendet, obwohl sie unterschiedliche Ergebnisse mit unterschiedlichem Zweck bezeichnen. Das hat praktische Folgen: Wer Mockups abnimmt, obwohl eigentlich der Ablauf geprüft werden sollte, segnet Farben und Icons ab und bemerkt den überflüssigen Bestätigungsschritt erst, wenn er programmiert ist.
Ein Wireframe ist die Strukturskizze eines Screens in Graustufen. Er zeigt, welche Inhalte und Bedienelemente wo stehen, und verzichtet bewusst auf Farben, Schriften und Bilder. So bleibt die Diskussion bei Inhalt und Ablauf.
Ein Mockup ist die statische, visuell ausgearbeitete Fassung desselben Screens: finale Farben, Typografie, Icons, echte Texte. Es zeigt, wie die App aussehen wird, lässt sich aber nicht bedienen.
Ein Klickdummy (auch Clickdummy oder klickbarer Prototyp) verknüpft die Screens so, dass man sich auf dem Smartphone durch sie tippen kann wie durch eine echte App. Dahinter steckt keine Programmlogik und keine Datenbank. Jede Schaltfläche führt nur zum nächsten vorbereiteten Screen.
Prototyp ist der Oberbegriff für jede testbare Vorstufe, von verknüpften Wireframes (Low Fidelity) bis zum Klickdummy aus finalen Mockups (High Fidelity).
| Ergebnis | Beantwortet die Frage | Detailgrad | Freigabe durch |
|---|---|---|---|
| Wireframe | Was steht wo, welche Schritte gibt es? | niedrig, Graustufen | Fachbereich, Produktverantwortliche |
| Mockup | Wie sieht es aus? | hoch, statisch | Produktverantwortliche, Marketing (CI) |
| Klickdummy | Verstehen Nutzer den Ablauf? | mittel bis hoch, klickbar | Auftraggeber, nach dem Usability-Test |
| Design System | Wie wird es gebaut? | Komponenten und Design Tokens | Entwicklung |
Der App-Design-Prozess in sechs Phasen
Die sechs Phasen bauen aufeinander auf. Jede endet mit einem Ergebnis, das jemand freigibt, bevor die nächste beginnt. Das klingt nach Wasserfall, ist in der Praxis aber iterativ: Ein Usability-Test in Phase 5 schickt einzelne Abläufe regelmäßig zurück in Phase 2 oder 3. Entscheidend ist, dass diese Rücksprünge vor der Programmierung passieren.
Phase 1: Ziele, Nutzer und Kernaufgaben
Vor dem ersten Screen stehen drei Fragen. Wer nutzt die App, und in welcher Situation? Ein Lagerarbeiter mit Handschuhen, ein Außendienstler mit schlechtem Netz und ein Endkunde auf dem Sofa brauchen sehr unterschiedliche Oberflächen. Welche drei bis fünf Aufgaben muss die App zuverlässig lösen? Und woran misst du nach dem Start, ob sie das tut, etwa an der Zeit pro Vorgang oder der Zahl abgeschlossener Bestellungen?
Das Ergebnis ist eine kurze, priorisierte Liste der Kernaufgaben plus die Rahmenbedingungen: Plattformen, anzubindende Systeme, Anforderungen an Barrierefreiheit. Gibt es bereits ein Lastenheft, ist es der Input für diese Phase. Was davon in die erste Version gehört, ist eine Scope-Entscheidung, die der Beitrag zur MVP-Entwicklung ausführlich beschreibt.
Phase 2: Informationsarchitektur und User Flows
Die Informationsarchitektur legt fest, welche Bereiche die App hat und wie sie zusammenhängen: Was steht in der Hauptnavigation, was ist eine Ebene tiefer, was erreicht man nur über die Suche? Daraus entsteht eine Screen-Liste, die gleichzeitig die wichtigste Grundlage für jede Aufwandsschätzung ist.
Für jede Kernaufgabe wird anschließend ein User Flow gezeichnet, also der Weg vom Einstieg bis zum Ziel. Dazu gehören die unangenehmen Abzweigungen: Was passiert, wenn das Login scheitert, die Kamera-Berechtigung verweigert wird oder die Verbindung mitten im Formular abbricht? Diese Fälle tauchen in keinem Moodboard auf. Fehlt etwa die Regel für den Netzabbruch, geht ein halb ausgefülltes Formular verloren, und solche Lücken führen häufig zu Nachbesserungen, wenn sie erst in der Entwicklung auffallen.
Phase 3: Wireframes
Jetzt werden die Screens der Screen-Liste als Wireframes gezeichnet, zuerst grob und oft auf Papier, dann sauber im Design-Tool. Zwei Regeln sparen hier Zeit. Erstens: echte Inhalte statt Blindtext. Ein Produktname mit 60 Zeichen oder eine deutsche Fehlermeldung bricht ein Layout, das mit „Lorem ipsum“ perfekt aussah. Zweitens: jeder Screen in allen Zuständen, also leer, ladend, gefüllt, fehlerhaft und offline.
Die Freigabe der Wireframes ist die wichtigste im ganzen Prozess. Der Fachbereich prüft, ob alle Informationen da sind und die Reihenfolge der Schritte stimmt. Geprüft wird dabei der Ablauf, nicht der einzelne Screen. Warum das den Unterschied macht, zeigt der Abschnitt über typische Stolperstellen weiter unten.
Phase 4: UI-Design und Mockups
Im UI-Design bekommen die Wireframes ihre visuelle Gestalt: Farben und Schriften aus dem Corporate Design, Icons, Abstände, Bildsprache. Dabei gelten die Konventionen der Plattformen. Apple beschreibt sie in den Human Interface Guidelines, Google im Material Design.
Apple hat mit iOS 26 die Designsprache Liquid Glass eingeführt, Google mit einem Android-16-Update im September 2025 Material 3 Expressive. Für das Design heißt das: Navigationsleisten, Tab-Bars und Dialoge sehen unter iOS 26 und Android 16 anders aus als in älteren UI-Kits. Wer auf veralteten Vorlagen gestaltet, erzeugt Abweichungen, die spätestens in der Entwicklung auffallen.
Für Cross-Platform-Apps mit React Native oder Flutter stellt sich die Frage, ob iOS und Android identisch aussehen sollen. Unsere Empfehlung: Markenelemente wie Farben, Typografie, Bildsprache und Inhalte sind auf beiden Plattformen gleich. Systemmuster wie Zurück-Navigation, Datumsauswahl und Freigabedialoge folgen der jeweiligen Plattform, weil Nutzer sie aus jeder anderen App auf ihrem Gerät kennen. Welches Framework zu welchem Projekt passt, vergleicht der Beitrag Flutter vs. React Native.
Barrierefreiheit gehört in diese Phase. Apple nennt für iOS eine Standardgröße von 44 × 44 Punkt für Bedienelemente und 28 × 28 Punkt als Minimum. Google empfiehlt für Android Tippflächen von mindestens 48 × 48 dp. Für Web-Apps verlangt WCAG 2.2 im Erfolgskriterium 2.5.8 mindestens 24 × 24 CSS-Pixel. Für normalen Text verlangt WCAG 2.2 (Erfolgskriterium 1.4.3, Stufe AA) ein Kontrastverhältnis von mindestens 4,5:1, für großen Text 3:1. Apples Richtlinien empfehlen dieselben Werte.
Für Apps, über die Verbraucher Verträge abschließen, etwa Shopping-, Banking- oder Ticket-Apps, gilt seit dem 28. Juni 2025 zudem das Barrierefreiheitsstärkungsgesetz. Ausgenommen sind Kleinstunternehmen, die diese Dienstleistungen erbringen, also Unternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme. Reine B2B- und interne Apps fallen nicht in diese Kategorie. Barrierefrei gestalten lohnt sich dort trotzdem, weil dieselben Regeln auch Nutzern mit Handschuhen, im Sonnenlicht oder mit kleinem Display helfen.
Phase 5: Klickdummy und Usability-Test
Aus den Mockups entsteht der Klickdummy: Die Screens werden im Design-Tool verknüpft und auf echten Smartphones geöffnet. Für frühe Tests reicht oft schon ein Klickdummy aus Wireframes. Er beantwortet die Frage, die kein Review im Besprechungsraum beantworten kann: Verstehen Menschen, die die App nicht kennen, den Ablauf ohne Erklärung?
Der Test selbst ist überschaubar. Du gibst Testpersonen aus der Zielgruppe konkrete Aufgaben („Erfasse einen neuen Auftrag für Kunde Müller“), lässt sie laut denken und hilfst nicht. Jakob Nielsen hat 2000 begründet, warum fünf Nutzer pro Testrunde ausreichen: Nach seinem Modell decken sie rund 85 Prozent der Bedienprobleme auf.
Die Zahl gilt für eine homogene Nutzergruppe. Bei zwei deutlich verschiedenen Zielgruppen empfiehlt Nielsen drei bis vier Personen je Gruppe. Außerdem rät er ausdrücklich zu mehreren kleinen Runden statt einer großen, weil jede Korrektur neue Probleme erzeugen kann.
Das Ergebnis ist ein Testprotokoll mit priorisierten Befunden. Ein Eintrag sieht zum Beispiel so aus: Aufgabe „Auftrag speichern“, Beobachtung „Speichern-Button wird von der Tastatur verdeckt, drei von fünf Personen suchen ihn“, Schwere kritisch, Rückgabe an Phase 3. Kritische Befunde gehen zurück in Phase 2 bis 4, danach folgt idealerweise eine zweite, kürzere Runde.
Phase 6: Design System und Übergabe an die Entwicklung
Am Ende steht eine Komponentenbibliothek. Jeder Button, jedes Eingabefeld und jede Liste ist einmal definiert, mit allen Zuständen (normal, gedrückt, deaktiviert, Fehler). Farben, Abstände und Schriftgrößen liegen als benannte Werte vor, sogenannte Design Tokens.
Der Nutzen: Ändert sich eine Markenfarbe, wird sie an einer Stelle geändert und gelangt über die Token-Pipeline in alle Screens und Plattformen, sofern Design und Code dieselben Tokens verwenden.
Für das Format gibt es seit dem 28. Oktober 2025 einen offenen Standard: Die Design Tokens Community Group beim W3C hat die erste stabile Version 2025.10 ihrer Spezifikation veröffentlicht. Werkzeuge wie Style Dictionary erzeugen daraus Code für iOS, Android, Web und Flutter. Figma, Penpot und Sketch unterstützen das Format bereits oder setzen es um.
Die Übergabe zieht sich durch die gesamte Entwicklung. Entwickler sehen im Dev Mode von Figma Maße, Abstände und Assets direkt am Design.
Trotzdem tauchen in der Umsetzung Fragen auf, die das Design nicht beantwortet hat: Was passiert, wenn die Tastatur den Speichern-Button verdeckt? Wie verhält sich eine Liste, die im Mockup zwölf und im Echtbetrieb 500 Einträge hat? Plane deshalb ein, dass Designerin oder Designer auch während der Entwicklung erreichbar sind und die umgesetzten Screens vor dem Release gegen das Design prüfen.
Welche Detailstufe braucht dein Projekt?
Wie tief jede Phase ausfällt, richtet sich danach, wie teuer ein Fehler im Ablauf wäre und wer die App nutzt.
Eine interne App mit wenigen Screens und bekannten Nutzern, etwa ein Erfassungstool für das Lager, kommt oft mit Wireframes, einem Low-Fidelity-Klickdummy und einem kurzen Test mit drei Kolleginnen und Kollegen aus. Das UI-Design kann auf einer bestehenden Komponentenbibliothek wie Material Design (Material 3) aufsetzen, statt jede Komponente neu zu gestalten.
Eine App für Endkunden im App Store durchläuft dagegen alle sechs Phasen, mit High-Fidelity-Klickdummy und mindestens zwei Testrunden. Hier entscheidet die erste Nutzung darüber, ob die App installiert bleibt.
Soll ein Budget erst intern freigegeben werden, etwa durch Geschäftsführung oder Beirat, ist ein Klickdummy des wichtigsten Ablaufs oft die bessere Entscheidungsgrundlage als ein Konzeptpapier. Das Design System kann in diesem Fall warten. Bei der Überarbeitung einer bestehenden App beginnt der Prozess sinnvollerweise mit einem Usability-Test der aktuellen Version, damit klar ist, was die neue besser machen muss. Die grundsätzliche Frage zwischen Überarbeitung und Neubau behandelt der Beitrag App-Update oder Neubau.
Tools für Wireframes und Klickdummys
Bei der Tool-Wahl entscheiden zwei Fragen: Wo dürfen die Entwürfe liegen, und wer muss sie sehen?
Figma gilt im App-Design als De-facto-Standard. Wireframes, Mockups, Klickdummy und Übergabe laufen in einem Werkzeug. Auftraggeber sehen Prototypen per Freigabelink oder mit einem kostenlosen Figma-Konto, ohne kostenpflichtigen Seat. Die Listenpreise im Professional-Plan liegen bei jährlicher Abrechnung bei 16 US-Dollar pro Monat für einen Full Seat, 12 US-Dollar für einen Dev Seat und 3 US-Dollar für einen Collab Seat (Stand Oktober 2026). Den Dev Mode für die Übergabe gibt es nur mit Dev- oder Full Seat.
Seit dem 24. Juli 2025 ist zudem Figma Make allgemein verfügbar. Das Werkzeug erzeugt aus einer Textbeschreibung interaktive Prototypen. Für schnelle Varianten in der Wireframe-Phase ist das nützlich. Den Test mit echten Nutzern ersetzt es nicht, und der erzeugte Code ist keine geplante App-Architektur.
Penpot ist die Open-Source-Alternative unter der Mozilla Public License 2.0. Penpot lässt sich selbst hosten, arbeitet mit offenen Formaten wie SVG und CSS und unterstützt Design Tokens nativ. Das ist relevant, wenn Entwürfe die eigene Infrastruktur nicht verlassen dürfen, etwa bei Apps für Behörden oder sensible interne Prozesse.
Sketch lässt sich nur auf dem Mac bearbeiten, Ansehen und Kommentieren funktioniert im Browser. Adobe XD befindet sich seit 2023 im Wartungsmodus und ist für neue Projekte keine Option mehr. Für die ersten groben Skizzen bleibt Papier ein ernstzunehmendes Werkzeug: schneller als jedes Tool und ohne Einladung, über Pixel zu diskutieren.
Aufwand und Dauer: eine Modellrechnung
Wie lange der App-Design-Prozess dauert, hängt von der Zahl der Screens und der Geschwindigkeit der Freigaben ab. Die folgende Modellrechnung geht von einer Cross-Platform-App mit rund 20 Screens und drei Kernaufgaben aus. Ein Corporate Design existiert bereits, gearbeitet wird mit einer Designerin oder einem Designer und anteiliger Projektleitung. Die Werte sind Richtwerte zur Orientierung, keine Preisliste.
| Phase | Ergebnis | Aufwand (Personentage) |
|---|---|---|
| 1. Ziele und Kernaufgaben | priorisierte Aufgabenliste, Rahmenbedingungen | 2–4 |
| 2. Informationsarchitektur und User Flows | Screen-Liste, Flow-Diagramme | 2–4 |
| 3. Wireframes | rund 20 Screens inklusive Zustände | 4–7 |
| 4. UI-Design und Mockups | ausgearbeitete Screens iOS und Android | 6–12 |
| 5. Klickdummy und Usability-Test | Prototyp, eine Testrunde mit fünf Nutzern, Korrekturen | 4–7 |
| 6. Design System und Übergabe | Komponentenbibliothek, Design Tokens, Übergabe | 4–8 |
| Summe | – | 22–42 |
Die Rechnung enthält eine Testrunde. Eine zweite Runde, wie sie für Endkunden-Apps sinnvoll ist, kommt mit etwa zwei bis vier Personentagen hinzu. Nicht enthalten sind die Rekrutierung der Testpersonen und mögliche Aufwandsentschädigungen. Wie sich das Design im Gesamtbudget einer App einordnet, zeigt der Beitrag App entwickeln lassen: Kosten und Ablauf.
In Kalenderzeit entsprechen 22 bis 42 Personentage meist sechs bis zehn Wochen. Die größte Unsicherheit liegt dabei auf Auftraggeberseite, bei den Freigaben. Ein einfaches Rechenbeispiel: Der Prozess hat sechs Freigabepunkte. Wartet das Team an jedem davon eine Woche auf eine Entscheidung, verlängert sich das Projekt um sechs Wochen, ohne dass sich der Designaufwand ändert. Feste Freigabetermine mit allen Entscheidern, die bereits zum Projektstart im Kalender stehen, sind deshalb die wirksamste Maßnahme gegen Verzug.
Wo App-Design-Projekte typischerweise ins Stocken geraten
Ein häufiger Grund für Verzögerungen ist die Freigabe einzelner Screens. Wer zwanzig Mockups als Bilder per E-Mail abnimmt, sieht nicht, dass der Weg vom Warenkorb zur Bestellung sieben Schritte hat. Freigaben finden deshalb am Klickdummy und entlang der User Flows statt.
Ebenso häufig fehlen Inhalte. Wenn Produkttexte, Fehlermeldungen oder rechtliche Hinweise erst nach dem Design geliefert werden, passen sie selten in die vorgesehenen Flächen. Im besten Fall wird nachgearbeitet, im schlechtesten Fall entscheidet die Entwicklung, wie es aussieht.
Ein drittes Muster sind Designs ohne technische Rückkopplung. Eine aufwendige Animation oder eine individuell gestaltete Datumsauswahl sieht im Mockup gut aus, kann in der Umsetzung aber ein Vielfaches einer Standardkomponente kosten. Sitzt eine Entwicklerin oder ein Entwickler ab Phase 3 mit am Tisch, fallen solche Punkte vor der Umsetzung auf.
Häufige Fragen zum App-Design
Was ist ein Klickdummy? Ein Klickdummy, auch Clickdummy genannt, ist ein klickbarer Prototyp aus verknüpften Screens. Er dient dazu, Abläufe mit Nutzern zu testen und Entscheidungen abzusichern, bevor Code entsteht.
Wie lange dauert der App-Design-Prozess? Für eine App mit rund 20 Screens sind sechs bis zehn Wochen ein realistischer Rahmen, bei einem Aufwand von etwa 22 bis 42 Personentagen. Kleinere interne Apps gehen schneller, Apps mit mehreren Zielgruppen und vielen Zuständen dauern länger.
Kann man den Klickdummy später als App weiterverwenden? In der Regel nicht. Ein Klickdummy besteht aus verknüpften Entwürfen im Design-Tool. Was weiterverwendet wird, sind die Mockups, die Komponentenbibliothek und die Design Tokens, aus denen die Entwicklung die echte App baut.
Fazit: Ablauf testen, Freigaben terminieren
Der App-Design-Prozess klärt in sechs Phasen, was die App leisten muss, wie Nutzer sie bedienen und wie sie gebaut wird. Der Klickdummy mit Usability-Test ist der Schritt, an dem diese Entscheidungen zum ersten Mal mit echten Nutzern geprüft werden; in der Modellrechnung kosten Klickdummy, eine Testrunde und die Korrekturen zusammen vier bis sieben Personentage. Über die Kalenderzeit entscheiden vor allem die Freigaben, deshalb gehören feste Freigabetermine schon zum Projektstart in den Kalender.
Der erste konkrete Schritt braucht noch kein Design-Tool: eine priorisierte Liste der Kernaufgaben und eine Screen-Liste. Wenn du darauf aufbauend Wireframes und einen testbaren Klickdummy brauchst, bevor du über das Entwicklungsbudget entscheidest, findest du unseren Ansatz auf der Seite zu Prototyping und Wireframing. Für das komplette UI-Design inklusive Design System gibt es die Seite App UX/UI Design.
