Deutsch

Wireframing und Prototyping, das Engineering übersteht

Beim ersten Mal hätte ich fast gekündigt.

Ich hatte drei Wochen an einem Settings-Flow gearbeitet. Wunderschöne Figma-Datei. Jeder Screen. Ein Hover-State beim Avatar-Upload, weil er mir wichtig war. Eng baute es. Der Empty State war ein trauriges graues Rechteck mit dem Wort "Empty" in 12px Arial. Der Error-Toast war der Standard-Rotbalken des Browsers. Loading war ein generischer Spinner, der sofort erschien, auch in der lokalen Entwicklung, wo der Request 40 ms dauerte. Die Validierungsnachricht? Ein nativer HTML-<input>-Tooltip mit dem Text "Bitte geben Sie das angeforderte Format ein."

Ich schrieb dem Engineer. Er sagte ruhig: "Du hast es nicht spezifiziert." Ich war wütend. Ich ging zurück zur Figma-Datei. Er hatte recht. Ich hatte es nicht getan.

Dieses Gespräch ist der gesamte Grund für diesen Guide. Engineering ist nicht der Feind. Spec-Lücken sind es. Und Spec-Lücken sind ein UX-Problem, kein Eng-Problem.

Warum das jetzt wichtig ist

Rechnen Sie den Aufwand eines einzigen Redo durch. Ein Feature. Ein Sprint. Der Empty State ist falsch, die Fehlerbehandlung fehlt, Eng muss die Komponente refaktorieren, weil die Varianten von Anfang an nicht vorhanden waren. Aus meinen letzten vier Jobs schätze ich die durchschnittlichen Kosten eines solchen Redos auf etwa 40 Designer-Stunden und 60 Eng-Stunden. Das sind 100 Personenstunden, gemischte Kosten von rund 12.000 bis 15.000 Euro, je nach Team. Ein Redo pro Quartal und Sie verbrennen 50.000 Euro pro Jahr an Nacharbeit, die ein besseres Handoff-Dokument verhindert hätte.

Das sind nur die Kosten in Euro. Der Vertrauensschaden ist schlimmer. Nach dem zweiten Redo hört Eng auf, Ihren Specs zu vertrauen, und beginnt zu bauen, was sie denken, dass Sie gemeint haben. Nach dem dritten glaubt Ihr PM Ihren Timelines nicht mehr, weil "Design immer eine weitere Runde braucht." Der Handoff ist kein Handoff. Es ist ein Vertrag. Behandeln Sie ihn so, und der größte Teil davon löst sich in Luft auf.

Low-fi vs. High-fi: wann jedes seinen Platz verdient

Der größte Einzelfehler, den ich bei Junior-Designern sehe, ist der zu frühe Sprung zu High-fi. Pixelgenaue Mocks, bevor der Flow festgelegt ist. Eng sieht sie, ist begeistert, beginnt zu bauen. Dann kommt die Research zurück und der Flow ändert sich. Jetzt hat Eng die Hälfte des Falschen in Produktionscode geliefert, und jemand muss dem PM erklären, warum der Sprint gerutscht ist.

Low-fi ist für Flow-Logik und Stakeholder-Freigabe. Papierskizzen, Balsamiq, grobe Figma-Frames mit Platzhalter-Rechtecken. Die zu beantwortende Frage lautet "Ist das überhaupt die richtige Idee?" Keinen Screen polieren, den Sie morgen vielleicht wegwerfen. Das Ergebnis ist ein klickbarer Prototyp, der beweist, dass der Weg von A nach B Sinn macht, plus ein Flow-Diagramm. Das war's.

High-fi ist für den Build. Pixelgenau, echter Text (kein Lorem Ipsum, niemals, weil Eng es kopiert und Sie "Lorem ipsum dolor" auf der Live-Login-Seite finden werden, fragen Sie mich wie ich das weiß), echte Datenschemas, alle States. Aber erst nachdem der Flow festgelegt ist. Wenn Sie Layout-Details auf einem Screen korrigieren, dessen Flow noch diskutiert wird, stoppen Sie. Zurück zu Low-fi. Erst den Flow sperren.

Der ehrliche Test: Wenn ein Stakeholder noch fragt "Warte, warum geht der User hierhin?", sind Sie nicht bereit für High-fi. Egal, wie schön die Rechtecke sind.

Die Spec-Lücken, nach denen Eng fragen wird (und die Sie nicht designed haben)

Das ist der Teil, den niemand an der Designschule lehrt. Jeder Screen hat ungefähr acht States. Sie haben wahrscheinlich zwei davon designed. Hier ist die Liste, die Eng Ihnen vorlegen wird, sobald sie sich zum Bauen hinsetzen:

Die acht States, die jeder Screen braucht

  1. Standard / befüllt. Der Happy Path. Diesen haben Sie designed.
  2. Leer. Null Einträge, null Ergebnisse, erstmaliger User. Was sieht der User, wenn nichts zu sehen ist? "Noch keine Einträge" ist kein Design. Zeigen Sie die Illustration, den CTA-Text, die sekundäre Aktion.
  3. Laden. Skeleton, Spinner, Optimistic UI. Und die Timing-Regel: wie lange, bevor der Spinner erscheint? (200 ms ist der Standardschwellenwert; darunter nichts zeigen.)
  4. Fehler. API-Fehler, Validierung, Zugriff verweigert, Netzwerk offline. Jeder ist anders. Der 500-Fehler sieht nicht wie der 403 aus, der wiederum nicht wie "Ihr Passwort ist zu kurz."
  5. Partiell / eingeschränkt. Die Hälfte der Daten geladen, einige Bilder defekt, Drittanbieter-Widget nicht verfügbar. Echte Systeme treffen das ständig.
  6. Berechtigungs-Variante. Admin, Member, Viewer, Gast. Was wird ausgeblendet, deaktiviert oder mit Tooltip angezeigt?
  7. Edge-Daten. Lange Namen, die umbrechen, 0/null/negative Zahlen, 47 Einträge in einer Liste, die für 5 designed wurde, eine Steuer-ID mit 32 Zeichen.
  8. Mobil / Breakpoints. Wenn das Design Desktop-first ist, was passiert bei 768 px und 375 px? "Responsive" ist keine Spec.

Ich habe diese Liste neben meinem Monitor angeheftet. Vor jedem Handoff gehe ich jeden Screen gegen die acht States durch. Wenn ein State "wie Standard" ist, schreibe ich das auf. Wenn er "außerhalb des Scopes dieses Sprints" liegt, schreibe ich das ebenfalls auf. Der Punkt ist nicht, immer alle acht zu designen. Der Punkt ist, alle acht bewusst zu entscheiden und die Entscheidung in die Datei zu schreiben.

Die Acht-States-Lücke ist der häufigste Einzelfehler, den ich sehe. Beheben Sie diesen einen Punkt und Sie haben vielleicht 60 % der "Du hast es nicht spezifiziert"-Momente eliminiert.

Figma-Auto-Layout-Disziplin

Auto-Layout ist keine Option. Wenn Ihre Datei nicht darauf aufgebaut ist, kann Eng nicht sehen, was eine Komponente und was ein Frame ist, kann kein Padding von Margin unterscheiden, kann nicht vorhersagen, was passiert, wenn der Text länger wird. Sie raten. Sie raten falsch. Dann ist es Ihre Schuld.

Vier Regeln, die mir Stunden gespart haben:

  1. Komponenten, keine getrennten Frames. Jedes wiederverwendbare Element ist eine Komponente mit einem Namen, den Eng lesen kann. Ein Button heißt Button/Primary/Default, nicht Rectangle 47. Wenn Eng den Komponentennamen im Inspektor nicht sehen kann, raten sie.
  2. Echte Spacing-Tokens, keine geschätzten Abstände. 4, 8, 12, 16, 24, 32. Das war's. Wenn Sie padding: 13px eintippen, machen Sie es falsch. Wählen Sie einen Wert und machen Sie weiter.
  3. Constraints gesetzt, sodass Größenänderungen tatsächlich funktionieren. Jede Komponente bei der größten und kleinsten möglichen Größe testen. Wenn eine Card bricht, wenn der Titel 80 Zeichen hat, wird Eng diesen Bug in der Produktion treffen.
  4. Varianten für States. Standard, Hover, Aktiv, Deaktiviert, Laden, Fehler. Alle in einer Komponente, umschaltbar über eine Property. Eng verbindet die Variante mit der State-Machine, und die Datei wird selbst-dokumentierend.

Ein nützlicher Geruchstest: Datei öffnen, ein Element anklicken, das rechte Panel anschauen. Wenn Sie nicht auf einen Blick erkennen können, was es für eine Komponente ist, in welcher Variante sie sich befindet und welches Spacing-Token sie verwendet, kann Eng es auch nicht. Vor dem Handoff beheben.

Design-Tokens: der Vertrag mit Eng

Tokens sind das Einzelne mit dem höchsten Hebel, das ein UX-Designer liefern kann. Farben, Typskala, Abstände, Radien, Schatten, Animationsdauern: alle benannt, alle einmal definiert, alle in jeder Komponente per Name referenziert.

Der Vertrag ist einfach. Wenn sich ein Token ändert (die Marke aktualisiert von #0066FF auf #0052CC), ändert Eng eine Variable, nicht 40 Komponenten. Dasselbe gilt für Typskala, Radius, jeden Schatten.

Die Infrastruktur ist inzwischen wirklich gut. Figma Variables als Source of Truth. Tokens Studio (oder der native Variables-Export) zum Pushen nach JSON. JSON wird in die Tailwind-Konfiguration, CSS-Variablen oder einen Style-Dictionary-Build importiert. Eng tippt nie manuell einen Hex-Wert. Sie suchen nie eine Farbe aus dem Gedächtnis.

Wenn Sie noch keine Tokens haben, ist das die Investition mit dem höchsten ROI, die Sie dieses Quartal machen können. Die erste Migration dauert eine Woche. Jeder Handoff danach wird günstiger.

Das Handoff-Dokument: Loom plus Annotationen

Das Handoff-Dokument ist ein Vertrag. Mündliche Handoffs sind keiner. "Ich rede einfach mit Eng" ist die teuerste Abkürzung im Design. Flurgespräche sind gut zum Klären. Sie sind schlecht zum Spezifizieren, weil niemand in sechs Wochen, wenn QA die Lücke findet, das Gespräch gleich erinnert. Wer mehr politisches Kapital hat, gewinnt. So sollte eine Design-Org nicht funktionieren.

Hier sieht ein Handoff-Dokument aus, in drei Teilen.

Teil 1: Ein 5-minütiges Loom, das den Flow durchführt. Figma öffnen, Bildschirm teilen, Aufnahme starten. Den Flow im Tempo eines Entwicklers durchgehen, der ihn noch nie gesehen hat. Hinweisen auf: den Einstiegspunkt, jeden Screen, das nicht-offensichtliche Verhalten ("der Toast erscheint mit einer Slide-Animation, nicht Fade, 200 ms Ease-out") und jede State-Wechsel-Logik ("das leert sich, wenn der User null Rechnungen hat, aber wenn er Rechnungen hatte und alle gelöscht hat, zeigen wir die 'alle gelöscht'-Variante, nicht den erstmaligen Empty State"). Ich halte das bei einer 3-Minuten-Struktur: 30 Sekunden Kontext, 2 Minuten Flow-Walkthrough, 30 Sekunden Besonderheiten, 30 Sekunden Fragen an Eng.

Teil 2: Annotierte Figma-Frames. Nummerierte Callouts auf jedem Screen. Keine roten Sticky-Notes. Echte nummerierte Annotationen, die wie ein Vertrag gelesen werden. "1: Avatar. Klicken öffnet Upload-Modal. Modal schließt bei Esc, bei Klick auf Overlay und bei erfolgreichem Upload." Jede Interaktion. Jedes Animations-Timing. Jeden Edge Case, den der Acht-States-Durchgang aufgedeckt hat.

Teil 3: Akzeptanzkriterien in Engs Sprache. Das ist der Teil, den Designer überspringen und nicht sollten. Akzeptanzkriterien sehen so aus:

Wenn der User auf "Speichern" klickt und eine ungültige E-Mail-Adresse eingegeben hat, erscheint innerhalb von 200 ms ein Inline-Fehler unterhalb des Felds mit dem Text "Bitte geben Sie eine gültige E-Mail-Adresse ein", das Feld erhält einen roten Rahmen (Token: border-error), und der Fokus verbleibt auf dem Feld.

Das sind drei überprüfbare Verhaltensangaben (Timing, Text, Fokus-State), die QA verifizieren und Eng bauen kann. Für jede nicht-triviale Interaktion fünf bis zehn davon pro Screen schreiben. Ja, das ist langsam. Es ist absichtlich langsam. Im langsamen Teil sterben die Spec-Lücken.

Eine letzte Regel: auf einen einzigen Source-of-Truth-Figma-Frame verlinken. Nicht 12 Dateien. Nicht "siehe Exploration v3 und v5, aber nicht v4." Ein Frame. Eine URL. Wenn Sie auf mehrere Dateien zeigen müssen, wird Eng die falsche wählen, und das werden Sie verdient haben.

Das "Ich rede einfach mit Eng"-Scheitern

Ich kenne Designer, die stolz auf enge Eng-Beziehungen sind und schriftliche Handoffs als Overhead betrachten. Ich verstehe das. Ich war selbst einmal einer von ihnen. Die Beziehung ist real und es lohnt sich, in sie zu investieren. Aber die Beziehung ist kein Ersatz für das Dokument.

Drei Probleme beim mündlichen Handoff:

  1. Kein Nachweis. Sechs Wochen später, wenn QA die Lücke findet, werden Sie und Eng sich beide halb an ein Gespräch erinnern, aber unterschiedlich. Wer mehr politisches Kapital hat, gewinnt. So sollte eine Design-Org nicht funktionieren.
  2. Kein gemeinsames Verständnis. Eng verlässt das Gespräch mit ihrer Interpretation. Sie verlassen es mit Ihrer. Die Überschneidung liegt vielleicht bei 70 %. In der 30%-Lücke leben die Bugs.
  3. Keine Möglichkeit zur Nachprüfung nach dem Launch. Wenn Sie sich hinsetzen, um den Build zu prüfen, gibt es nichts, mit dem man ihn vergleichen könnte. Sie prüfen Stimmungen.

Die Regel, nach der ich jetzt lebe: Wenn es nicht aufgeschrieben ist, ist es nicht passiert. Das Loom ist aufgeschrieben (es ist eine Aufnahme). Annotationen sind aufgeschrieben. Akzeptanzkriterien sind aufgeschrieben. Flur-"Kannst du auch X machen?"-Gespräche werden innerhalb einer Stunde schriftlich nachgefasst, oder X wird nicht gebaut.

Post-Ship-Review

Der Handoff ist nicht abgeschlossen, wenn Eng gemergt hat. Er ist abgeschlossen, wenn Sie den Live-Build gemeinsam gegen die Figma-Datei geprüft und die Lücken protokolliert haben.

Wie ich es durchführe: 30-minütiges Meeting in einer Sandbox- oder Staging-Umgebung. Designer und Eng teilen den Bildschirm. Jeden Screen und jeden State durchgehen. Für jeden gibt es drei mögliche Ergebnisse:

  • Übereinstimmung. Weiter.
  • Lücke, in diesem Sprint beheben. Protokollieren, Bug einreichen, Eng verpflichtet sich zur Korrektur. Normalerweise 1-2 davon pro Feature.
  • Lücke, akzeptieren und Figma aktualisieren. Manchmal ist Engs Version tatsächlich besser, oder die Lücke ist zu klein, um einen Sprint wert zu sein. Figma aktualisieren, um die Realität widerzuspiegeln. Die Datei nicht lügend über den Produktionsstand lassen.

Die schlimmste Sünde ist der stille Fix. Nicht passiv-aggressiv die nächste Version aktualisieren, ohne Eng zu informieren. Nicht so tun, als existiere die Lücke nicht. Protokollieren, gemeinsam entscheiden, weitermachen. Nach einigen Zyklen davon beginnt Eng zu vertrauen, dass QA kooperativ ist, nicht adversarisch. Sie werden ihre eigenen Bedenken früher im Build äußern.

Ein realistisches Ziel: maximal 3 protokollierte Lücken pro geliefertem Feature, abnehmend im Laufe der Zeit, wenn die Acht-States-Disziplin stärker wird.

Erfolg messen

Drei Signale zeigen, dass die Handoff-Disziplin funktioniert.

  1. Null "Du hast es nicht spezifiziert"-Momente pro Sprint. Das ist der nachlaufende Indikator. Wenn Sie diese erleben, wurde der Acht-States-Durchgang nicht gemacht.
  2. Eng zitiert Figma-Frame-Namen in PRs. "Implementiert Settings/Profile/Avatar-Upload v2." Wenn Eng Commit-Nachrichten und PR-Beschreibungen schreibt, die Ihre Frames namentlich referenzieren, ist Ihre Datei zur Source of Truth geworden. Das ist das Ziel.
  3. Post-Ship-Review protokolliert maximal 3 Lücken pro Feature. Und die Lücken tendieren zu kleinen visuellen Korrekturen, nicht zu fehlenden States oder falschem Verhalten.

Wenn alle drei zutreffen, haben Sie das Handoff-Problem gelöst. Ihre Rolle verschiebt sich von der Verteidigung des Designs zu dessen Erweiterung. Was schließlich die Arbeit ist, die UX tun sollte.

Die Figma-Datei ist keine Kunst. Sie ist ein Vertrag. Alles aufschreiben. Die acht States durchgehen. Das Loom aufnehmen. Die Frames annotieren. Akzeptanzkriterien in Engs Sprache schreiben. Den Post-Ship-Review durchführen. Das fünf Mal in Folge tun, und Ihre Redo-Rate sinkt gegen null, und Sie hören auf, den Handoff-Freitag zu fürchten.

Camellia

Mehr erfahren