Das Wort „Handoff" beschreibt das Problem treffend. Etwas ist fertig und wird dann geworfen. Was auf der anderen Seite landet, ist ein Standbild eines Systems, das in Zuständen funktionieren muss, die das Bild nie gezeigt hat.
Mockups sind per Definition vollständig. Produkte sind es nicht. Jede Lücke dazwischen füllt ein Entwickler, der um 18 Uhr eine Designentscheidung trifft, ohne den Kontext, sie gut zu treffen.
Was in jedem Mockup fehlt
Das sind die Zustände, die wir heute verlangen, bevor etwas als fertig gilt. Die meisten Streitigkeiten zwischen Designern und Entwicklern sind in Wahrheit einer dieser undefinierten Zustände.
- Leer. Was ein neues Konto sieht. Meist der meistbesuchte Screen im Produkt und der am wenigsten gestaltete.
- Ladend. Skeleton, Spinner oder nichts — entschieden, nicht per Default.
- Fehler. Pro Feld und pro Seite, mit ausformuliertem Satz.
- Zu viel. Der längste Name, die 400-Zeichen-Beschreibung, die Liste mit vierzig Einträgen.
- Zu wenig. Ein Eintrag. Null Einträge. Ein Name mit zwei Buchstaben.
- Berechtigungen. Was der Nutzer mit Leserechten dort sieht, wo vorher der Button war.
Ein Entwurf ist fertig, wenn sein hässlichster Zustand gezeichnet ist — nicht sein schönster.
Was die Übergabe bei uns ersetzt hat
Ein Team, ein Repository und ab der ersten Woche ein Live-Staging-Link. Designer prüfen im Browser statt in der Datei — denn im Browser rendert die Schrift anders, ist der Schatten schwerer und existiert der Hover-Zustand.
Wir haben außerdem aufgehört, die Designdatei als Quelle der Wahrheit zu behandeln. Sobald eine Komponente gebaut ist, ist die gebaute maßgeblich und die Datei folgt ihr. Eine Datei, die der Produktion widerspricht, ist keine Dokumentation, sondern Fehlinformation.
Wenn Sie mit zwei Dienstleistern arbeiten müssen, spendieren Sie ihnen einen gemeinsamen wöchentlichen Call und schreiben Sie die Zustands-Checkliste oben in den Vertrag. Das kostet eine Stunde pro Woche und erspart den Streit darüber, wer den leeren Zustand hätte gestalten sollen.