Von der Skizze zum System: Mein Design-Prozess von A bis Z

Wenn ich beschreibe, wie ich arbeite, benutze ich selten das Wort Prozess. Es klingt nach Wasserfall, nach Checkliste, nach etwas, das von A nach B geht und dabei nichts dem Zufall überlässt. So funktioniert Designarbeit nicht.

Was ich habe, ist eher ein Set von Prinzipien, das sich je nach Projektgröße, Kunde und Komplexität unterschiedlich ausdrückt. Hier ist, was das in der Praxis bedeutet – von der ersten Anfrage bis zum fertigen Handoff.

Phase 1: Verstehen, bevor man gestaltet

Jedes Projekt beginnt mit Fragen. Nicht mit Figma.

Was ist das eigentliche Problem? Nicht das Problem, wie der Kunde es formuliert – das Problem, das dahinterliegt. „Wir brauchen ein neues Dashboard" ist selten die eigentliche Anforderung. Was sollen Nutzer mit dem Dashboard erreichen? Was tun sie heute stattdessen? Was hält sie davon ab?

Ich führe in dieser Phase strukturierte Gespräche: mit dem Auftraggeber, wenn möglich mit Endnutzern, manchmal mit dem Entwicklungsteam. Das Ziel ist kein Protokoll. Es ist ein geteiltes Verständnis davon, welches Problem gelöst werden soll – und für wen.

Was ich außerdem mache: Wettbewerber anschauen. Nicht um zu kopieren, sondern um zu verstehen, welche Patterns in diesem Kontext etabliert sind. Was erwarten Nutzer? Was funktioniert? Was wird vermieden?

Phase 2: Struktur vor Ästhetik

Der nächste Schritt ist kein Design. Es sind Wireframes. Grob, schnell, absichtlich hässlich.

Warum hässlich? Weil hübsche Wireframes zu frühe Diskussionen über Farben und Schriften auslösen – und von den eigentlich wichtigen Fragen ablenken: Ist diese Struktur richtig? Ist diese Navigation logisch? Macht dieser Flow Sinn?

Ich arbeite in dieser Phase oft mit Papier. Oder mit sehr niedrig aufgelösten Figma-Frames. Das Signal ist bewusst: Das hier ist nicht final. Wir testen Strukturen, keine Designs.

Was in dieser Phase entsteht: die grundlegende Informationsarchitektur, der primäre User Flow, ein Verständnis davon, wie viele Screens es gibt und wie sie zusammenhängen.

Phase 3: Der erste Prototyp

Sobald die Struktur halbwegs steht, baue ich einen klickbaren Prototyp. Nicht schön, aber navigierbar.

Dieser Prototyp hat einen einzigen Zweck: getestet zu werden. Ich zeige ihn echten Menschen, erkläre den Kontext, gebe ihnen eine Aufgabe – und schaue zu. Keine Tipps, keine Erklärungen.

Was ich dabei lerne, verändert fast immer etwas. Manchmal kleine Details. Manchmal fundamentale Annahmen. Beides ist gut – weil beides jetzt passiert, und nicht nach drei Monaten Entwicklungsarbeit.

Phase 4: High-Fidelity und Design System

Wenn die Struktur validiert ist, fange ich an, zu gestalten. Erst jetzt.

Ich beginne nicht mit dem schönsten Screen. Ich beginne mit den Komponenten. Welche UI-Elemente tauchen überall auf? Button, Input, Card, Navigation, Badge. Diese baue ich als vollwertige Figma-Komponenten: mit allen States, allen Varianten, mit Tokens für Farben, Spacing, Typografie.

Warum dieser Aufwand am Anfang? Weil er am Ende Zeit spart. Wenn ich später einen Screen baue, ziehe ich Komponenten zusammen – ich designe keine neuen. Wenn sich etwas ändert, ändert sich die Komponente – nicht zwanzig einzelne Stellen.

Der eigentliche Screen-Design-Prozess ist dann vergleichsweise schnell. Das Fundament ist gelegt. Was übrig bleibt, ist Komposition.

Phase 5: Review und Iteration

Kein Design überlebt den ersten Kundenkontakt unverändert. Das ist normal. Das Ziel ist nicht, auf Anhieb perfekt zu sein – das Ziel ist, Feedback zu bekommen, das das Ergebnis besser macht.

Ich strukturiere Reviews so: Ich zeige, erkläre den Entscheidungskontext, frage nach konkreten Reaktionen. Nicht „Gefällt es dir?" – das ist die falsche Frage. Sondern „Was fehlt dir hier?" und „Was wirst du in sechs Monaten vermissen?"

Was aus dem Review kommt, bearbeite ich systematisch: Was ist Feedba über Struktur? Was ist Feedback über Ästhetik? Was ist ein Wunsch, der außerhalb des Scopes liegt? Diese Unterscheidung ist wichtig, damit eine Review-Runde nicht zu einem Reopen des gesamten Projekts wird.

Phase 6: Handoff

Der letzte Schritt ist der, der am häufigsten unterschätzt wird.

Ein guter Handoff ist kein Figma-Link. Es ist ein Dokument, das Entwickler befähigt, das Design korrekt umzusetzen, ohne Rückfragen stellen zu müssen. Das bedeutet: Komponenten mit allen States, Annotationen für Verhalten und Logik, klare Benennung, Token-Referenzen, Edge Cases dokumentiert.

Ich schicke keinen Handoff raus, ohne vorher mit dem Entwicklungsteam durchzugehen, was ich gebaut habe. Nicht als Präsentation – als Gespräch. Was ist unklar? Was ist technisch schwierig? Was muss angepasst werden, bevor die Implementierung beginnt?

Dieser letzte Schritt entscheidet, ob das Produkt aussieht wie designed – oder wie eine Interpretation davon.

---

Ihr sucht ein Studio, das euren Designprozess von der ersten Frage bis zum finalen Handoff begleitet? Genau das machen wir – meldet euch.