Der Prototyp ist fertig, der Sprint ist es nicht
Du kennst den Moment. Der Prototyp läuft, die Klickstrecke sitzt. Zwei Wochen später sitzt das Team im Sprint und stellt Fragen, die vorher niemand gestellt hat. Was passiert, wenn die Liste leer ist? Wie sieht die Tabelle aus, während die Daten laden? Was zeigt die Maske einem Nutzer, der auf diesen Bereich gar keinen Zugriff hat?
Der Prototyp war nie falsch. Er war nur unvollständig, und zwar an genau den Stellen, die in einer Klickstrecke nicht vorkommen. Ein Prototyp zeigt den Weg, den man vorführen will. Eine Fachanwendung besteht zum größten Teil aus Wegen, die man nicht vorführt.
Was in der Spezifikation fehlt, wird im Sprint diskutiert und zweimal gebaut. Das ist der eigentliche Preis: die Schleife aus Rückfrage, Zwischenlösung, Abnahme und Korrektur. Wer diesen Effekt über mehrere Releases mitschleppt, landet bei dem, was wir an anderer Stelle als UX-Schulden in Bestandssoftware beschrieben haben.
Warum der Happy Path die teuerste Abkürzung ist
Der Happy Path ist schnell gezeichnet und teuer in der Übergabe. Er beschreibt den Fall, in dem alles vorhanden ist: Daten da, Rechte da, Netz da, Text kurz genug.
Fehlt der Rest, raten Entwickler Ladezustände, Fehler und leere Listen. Und sie raten nicht schlecht. Sie raten nur jedes Mal anders, weil niemand die Entscheidung getroffen hat. So bekommt dasselbe Problem an drei Stellen drei verschiedene Fehlermeldungen, die Tabelle lädt anders als die Detailansicht daneben, und im leeren Zustand steht am Ende „keine Daten“, weil das die kürzeste Zeichenkette war, die jemand tippen konnte.
Der Denkfehler steckt in der Reihenfolge. Das Rework fällt im Sprint an, obwohl die Lücke im Design entstanden ist. Solange der Zustand eine Frage im Design ist, ist er eine Entscheidung, die jemand trifft und aufschreibt. Steht er erst im Sprint zur Debatte, ist er ein Ticket, eine Diskussion, eine Implementierung, eine Korrektur und im schlechten Fall eine zweite Abnahme.
Dazu kommt der Termin. Eine Übergabe ohne Dokumentation blockiert Entwicklung und Termin. Sichtbar wird die Verzögerung im Sprintbericht. Ihren Ursprung hat sie in der Übergabe, Wochen vorher.
Die fünf Pflichtzustände: leer, ladend, fehlerhaft, zu lang, keine Berechtigung
Der Katalog ist kurz genug, um ihn im Kopf zu haben. Jeder Zustand dokumentiert: leer, ladend, fehlerhaft, zu lang, keine Berechtigung. Nimm diese fünf und geh damit durch jede Ansicht, die Daten anzeigt oder Eingaben entgegennimmt.
Leer
Leer ist nicht ein Zustand, sondern drei. Noch nie befüllt, durch Filter leer, vom Nutzer geleert. Gib den dreien unterschiedliche Texte und unterschiedliche Aktionen. Die Nielsen Norman Group behandelt Empty States in komplexen Anwendungen als eigene Gestaltungsaufgabe und formuliert dafür drei Leitlinien. Die Frage, die beantwortet sein muss: Was soll der Nutzer als Nächstes tun, und ist die Aktion von hier aus erreichbar?
Ladend
Ladend heißt: Wie lange, wie sichtbar, und was passiert bei einem sehr langsamen Backend? Ein Spinner über der ganzen Seite ist eine andere Entscheidung als eine Zeile, die sich nachlädt, während der Rest bedienbar bleibt. Die Frage: Bleibt die Oberfläche währenddessen benutzbar, und was ist der Schwellwert, ab dem überhaupt etwas angezeigt wird?
Fehlerhaft
Fehlerhaft trennt sich in mindestens zwei Fälle: Der Nutzer hat etwas falsch gemacht, oder das System hat etwas nicht geschafft. Die Frage: Steht im Text, was passiert ist, und steht darin, wie der Nutzer weiterkommt? Ein Fehlertext ohne Ausweg ist eine Sackgasse mit Beschriftung.
Zu lang
Der Zustand, der in Prototypen fast immer fehlt, weil dort Beispieldaten stehen. Ein Firmenname mit 80 Zeichen, eine Liste mit 12.000 Zeilen, eine Massenbearbeitung über 400 markierte Datensätze. Die Frage: Wird abgeschnitten, umgebrochen oder gescrollt, und ab welchem Wert?
Keine Berechtigung
Rollen und Rechte lassen sich beim Aufschreiben klären, bevor sie in der Abnahme auftauchen. Die Frage: Sieht der Nutzer den Bereich ausgegraut, sieht er ihn gar nicht, oder sieht er ihn und bekommt beim Klick eine Meldung? Alle drei Antworten sind vertretbar, keine Antwort ist es nicht.
Etablierte Designsysteme führen leer, ladend und fehlerhaft als zusammengehöriges Muster, unter anderem Carbon von IBM, SAP Fiori und das Agriculture Design System. Das ist ein gutes Argument dafür, diese Zustände nicht pro Screen zu erfinden, sondern einmal im System zu entscheiden. Wie so eine Systemebene in Bestandssoftware entsteht, ist ein eigenes Thema. Kurz gesagt: Systeme statt Screens.
Edge Cases finden, bevor der Sprint sie findet
Der Katalog hilft nur, wenn jemand ihn systematisch anwendet. Es gibt dafür drei Zugänge, unterschiedlich aufwendig.
Der aufwendigste zuerst. Du gehst die Ansicht Feld für Feld durch und fragst bei jedem Datenfeld, woher der Wert kommt und was passiert, wenn er fehlt. Danach dieselbe Runde für jede Aktion: Was passiert, wenn sie fehlschlägt, und was sieht der Nutzer, solange sie läuft? Das dauert, und am Ende steht die Liste, aus der die Zustandsdokumentation entsteht.
Der zweite Zugang kostet ein Gespräch. Frag im Support nach, welche Meldung die Leute nicht verstehen, bevor du den nächsten Fehlertext formulierst.
Der dritte ist ein Satz: Lass die Entwicklung die Spezifikation auf Vollständigkeit lesen, bevor sie darauf schätzt.
Was dabei herauskommt, gehört an eine Stelle, an der es während des Bauens offen liegt. Weitere Beiträge dazu sammeln wir im Blog.
Was sich 2026 geändert hat: Coding Agents lesen deine Datei in Figma
Bisher war eine Lücke in der Dokumentation eine Rückfrage. Inzwischen ist sie häufig keine mehr.
Zur Config 2026 am 24.06.2026 hat Figma laut einem Bericht von webdeveloper.com mehrere Neuerungen gezeigt: Figma Motion mit Anbindung an den Dev Mode, einen Design Agent mit Skills und Connectors sowie Code Layers im Early Access ab Juli 2026. Derselbe Bericht beschreibt Figma Motion als kompatibel mit MCP, animierte Frames gehen also über den MCP-Server von Figma an Coding Agents.
Die Konsequenz für die Dokumentation ist unabhängig vom einzelnen Feature. Wenn ein Agent die Datei direkt liest und daraus Code erzeugt, wird eine fehlende Angabe nicht mehr nachgefragt, sondern ausgefüllt. Ein Agent kann den Ladezustand, den niemand entschieden hat, plausibel genug ausfüllen, dass es im Review durchgeht. Die Rückfrage war lästig, aber sie war eine Kontrollinstanz.
Ready for Dev ist ein Zustand, kein Häkchen
Figma dokumentiert den Dev Mode und die Ansicht ready for dev als offiziellen Weg für die Übergabe. Das ist nützlich, und es ersetzt keine Entscheidung. Ein Frame kann als bereit markiert sein und trotzdem drei der fünf Zustände nicht enthalten.
Als Prüfliste vor der Übergabe reicht ein Satz pro Ansicht: Für jede Ansicht liegen leer, ladend, fehlerhaft, zu lang und keine Berechtigung als Entscheidung vor, mit Text, mit Verhalten, mit Zuständigkeit. Wo eine Entscheidung offen ist, steht sie als offene Frage drin, mit Namen und Datum. Eine markierte Lücke ist unangenehm, aber sie kostet nichts. Eine unmarkierte fällt erst im Sprint auf.
Was das im Projekt bedeutet
Wir sind zolu und machen Interface Design für komplexe B2B-Software und Produkte mit KI, remote aus NRW. Die Zustandsdokumentation gehört bei uns zum Ergebnis, das übergeben wird.
Bei ABUS läuft die Zusammenarbeit dauerhaft über die Übergabe im Dev Mode, direkt mit dem Entwickler. Zu dem Designsystem, das dort entstanden ist, gehören die fünf Zustände aus diesem Artikel genauso wie Buttons und Tabellen.
Für die Zeiterfassung von Troi+ sind aus einem Workshop verbindliche Prinzipien für die Bedienung geworden, dazu eine begründete Anforderungsliste für die Funktionen mit KI. Das Review einzelner Screens läuft weiter.
Software, die im Arbeitsalltag genutzt statt umgangen wird, hängt an genau diesen unspektakulären Entscheidungen.
Häufige Fragen
Ein Fehlerfall ist ein Ergebnis: Etwas ist schiefgegangen und muss angezeigt werden. Ein Edge Case ist eine Bedingung am Rand des erwarteten Bereichs, etwa eine leere Liste, ein sehr langer Name oder eine Rolle ohne Zugriff. Der Fehlerfall ist einer von mehreren Edge Cases.
Beide, und zwar im selben Dokument. Design entscheidet, was der Nutzer sieht und liest, Entwicklung entscheidet, unter welchen technischen Bedingungen der Zustand überhaupt eintritt. Liegen diese beiden Hälften in zwei getrennten Werkzeugen, entsteht die Lücke genau an der Nahtstelle. Unser Vorschlag für die Aufteilung: Design stellt den Katalog auf, Entwicklung liest ihn vor der Übergabe auf Vollständigkeit gegen.
Detailliert genug, dass niemand raten muss, und kurz genug, dass sie neben dem Ticket offen bleiben kann. Drei Angaben pro Zustand reichen dafür: der auslösende Fall, der sichtbare Text, die nächste mögliche Aktion. Was darüber hinausgeht, ist Entscheidungshistorie und gehört an einen anderen Ort als die Übergabe.
Der Dev Mode ist der offizielle Weg für die Übergabe und zeigt Maße, Werte und Komponenten. Was er nicht leistet, ist die Entscheidung darüber, welche Zustände es überhaupt gibt und was in ihnen steht. Wenn diese fünf Zustände als Frames vorliegen und beschriftet sind, ist der Dev Mode ein sehr guter Träger. Wenn nur der Happy Path darin liegt, ist der Status ein Häkchen ohne Deckung.
Nicht alles auf einmal nachziehen. Nimm die drei Ansichten mit der höchsten Nutzungsfrequenz und arbeite dort den Katalog ab, danach die Ansichten, zu denen der Support die meisten Anfragen bekommt.
Über die Autorin
Nadia Wiegand gestaltet unter der Marke zolu (Studio Wiegand, Sprockhövel) Interfaces für komplexe B2B-Software und Produkte mit KI. Sie arbeitet seit über zehn Jahren in diesem Feld.
