Anforderungen schärfen am klickbaren Prototyp.

Das Dokument hatte vierzig Seiten. Zehn Leute hatten es gelesen, kommentiert und freigegeben, und an dem Tag, an dem alle Häkchen dran waren, war ich erleichtert. Drei Monate später saß dieselbe Runde vor den ersten fertigen Screens, und jemand sagte: „Jetzt, wo ich das sehe – so hatten wir das nicht gemeint.“ Er hatte recht. Wir hatten alle dasselbe Wort benutzt und drei verschiedene Dinge darunter verstanden. Gemerkt haben wir das erst, als es etwas zu sehen gab.

Seitdem lasse ich Anforderungen nicht mehr auf Papier fertig werden. Sie sind da, bevor ich anfange – aus dem Kick-off, aus den Unterlagen, aus den Gesprächen. Aber sie bleiben vorläufig, bis es etwas zu sehen gibt. Am Ende der ersten Woche steht deshalb ein klickbarer Prototyp: noch nicht richtig, aber vollständig genug, um ihn von vorne bis hinten durchzuklicken. Und dann fängt die Arbeit an, für die er da ist: die Anforderungen schärfen. Nicht statt ihnen, sondern an ihnen.

Das eine ersetzt also nicht das andere. Ein Anforderungsdokument entsteht bei mir trotzdem – nur eben nach dem Prototyp und nicht vor ihm blind, und es steht dann auf etwas, das schon jemand in der Hand hatte.

Ausgearbeitet habe ich diesen Ablauf für ein Team, das große Systeme baut – Software mit vielen Beteiligten, langen Laufzeiten und Menschen, die damit arbeiten müssen, nicht wollen. Beide Wege liegen bei mir Tag für Tag nebeneinander. Was davon auch für kleine Projekte gilt, steht am Ende.

Der Prototyp ist eine Frage, keine Antwort

Das Wichtigste an diesem Prototyp ist, was er nicht ist: ein Vorschlag, wie das Ding aussehen soll. Er ist eine Frage in klickbarer Form. Ist das der Ablauf, den ihr meint? Fehlt hier ein Schritt? Heißt dieser Knopf bei euch wirklich so? Wenn ich mit einem Prototyp in einen Workshop gehe, verteidige ich ihn nicht – ich benutze ihn als Werkzeug, um die Missverständnisse nach oben zu holen, die in einem Textdokument monatelang unentdeckt bleiben.

Das ist kein Design-Trick, sondern ein Kommunikations-Trick. Der Satz „die Nutzerin sieht eine Übersicht ihrer offenen Anfragen“ liest sich für zehn Menschen zehnmal verschieden und für alle plausibel. Ein Bildschirm mit einer Tabelle darauf liest sich für alle gleich – und genau deshalb widerspricht jemand.

Fünf Tage, konkret

Die erste Woche ist eng getaktet, und sie ist der Teil, an dem KI wirklich etwas ändert. Nicht bei der Qualität – beim Tempo bis zum ersten sichtbaren Stand.

• Tag 1 – sortieren, was schon da ist. Kick-off, bestehende Unterlagen sichten, zwei bis drei kurze Gespräche mit Menschen aus der Zielgruppe. Anforderungen liegen an dieser Stelle meist längst vor – in Listen, Tickets, Lastenheften, Köpfen. Ergebnis: fünf bis sieben Kernfunktionen und eine erste Nutzerreise. Bewusst noch grob, denn die feinen Fragen beantwortet in zwei Wochen der Prototyp besser als heute ein Absatz.
• Tag 2 – Rohmaterial erzeugen. Aus den Kernfunktionen lasse ich Varianten generieren, mit v0.dev, Figma AI oder Claude: zwei bis drei Layouts pro Hauptbildschirm. Das ist Rohmaterial, kein Ergebnis – ich behalte, was trägt, und werfe den Rest weg. Am schnellsten ist KI genau hier: bei der leeren Seite.
• Tag 3 – verfeinern. Jetzt von Hand: Abstände aufs 8er-Raster, Hierarchie, Typografie, Icons. Und die Zustände, die in generierten Entwürfen immer fehlen – Laden, Fehler, „hier ist noch nichts“, Erfolgsmeldung. Ein Prototyp ohne diese vier lügt über die halbe Anwendung.
• Tag 4 – durchklickbar machen. Der Hauptweg von Anfang bis Ziel, alle kritischen Bildschirme verbunden, Übergänge, Overlays, Formulare. Dann selbst durchklicken und die toten Links finden. Dazu eine Bildschirmaufnahme von einer Minute, weil nicht alle im Termin sitzen werden.
• Tag 5 – zeigen. Problem, Nutzerbedürfnis, Lösung, Live-Demo, nächste Schritte. Und der Link zum Prototyp mit Kommentarrechten, damit das Feedback am Gegenstand landet und nicht in fünf E-Mail-Fäden.

Warum das Feedback danach anders klingt

In den zwei Wochen darauf passiert das, weswegen ich das Ganze mache. Das Feedback sortiert sich von allein in vier Sorten, und drei davon sind Gold:

• Funktion: „Das fehlt komplett.“ – „Das brauchen wir gar nicht.“
• Navigation: „Warum liegt das hinter drei Klicks?“
• Begriffe: „So nennen wir das intern nicht.“ – der häufigste Fund, und der billigste.
• Optik: zu hell, zu dunkel, falsches Blau. Die eine Sorte, die ich vertagen kann.

Nach zwei bis drei Runden ist der Prototyp abgestimmt, und dann kommt der Teil, der im klassischen Ablauf viel zu spät steht: Nutzertests in Woche zwei bis drei statt in Woche fünfzehn. Fünf bis acht Menschen aus der Zielgruppe, vier bis sechs echte Aufgaben, sie denken laut mit, ich beobachte und helfe nicht.

Getestet wird dabei nicht das Design, sondern ob wir die richtige Sache bauen. Danach schreibe ich die Anforderungen fest: User Stories mit Akzeptanzkriterien, Designsystem, technische Rahmenbedingungen. Das Dokument entsteht also trotzdem – nur ist es jetzt geschärft statt vermutet, und jeder Satz darin verweist auf einen Bildschirm, den schon jemand benutzt hat.

Was das an Zeit bringt – und woher sie kommt

Ich habe beide Abläufe Tag für Tag nebeneinandergelegt und durchgerechnet: klassisch 20 bis 24 Wochen, mit Prototyp-Start 12 bis 16. Das ist gerechnet, nicht gemessen – niemand baut dasselbe Produkt zweimal, nur um zu vergleichen. Benennen kann ich aber, an welchen zwei Stellen der Unterschied entsteht. Beide haben nichts damit zu tun, dass irgendwer schneller tippt.

• Die Abstimmung wird kürzer. Klassisch: drei Wochen, bis das Anforderungsdokument fertig verhandelt ist, dann vier bis sechs Wochen Wireframes, bei denen jede Runde mit „ich kann mir das so nicht vorstellen“ anfängt. Mit Prototyp: die Anforderungen bleiben eine Woche lang grob, und die Verhandlung passiert an etwas Sichtbarem.
• Die teuren Änderungen fallen früher an. Eine Änderung im Prototyp kostet Minuten. Dieselbe Änderung im Code kostet Tage – und ist dann nicht mehr eine Entscheidung, sondern ein Change Request mit Angebot.

Der zweite Punkt ist mir der wichtigere, und er lässt sich auch ohne Zahlen sagen: Im klassischen Ablauf sehen echte Nutzer:innen das System zum ersten Mal nach etwa fünfzehn Wochen. Alles, was sie dann nicht verstehen, ist schon gebaut.

Ein bestehendes Designsystem ist kein Widerspruch

Der häufigste Einwand: Wir haben schon ein Designsystem, also fällt der Prototyp weg. Das eine hat mit dem anderen nichts zu tun. Gibt es ein gepflegtes System, ist der Prototyp sogar schneller fertig – die Bausteine liegen ja bereit, ich muss sie nur zusammenstecken. Was sich ändert, ist nur die Rolle der KI in den ersten Tagen.

Denn generierte Entwürfe halten sich nicht an ein System. Sie nehmen 12, 15 oder 18 Pixel, wo 8, 16 oder 24 stehen müssten, und bauen eigene Knöpfe statt der Komponenten aus der Bibliothek. Etwa 70 bis 80 Prozent passen, der Rest ist Nacharbeit – an einer Stelle, an der Konsistenz der ganze Punkt war. Deshalb arbeite ich dann gemischt: KI für zwei, drei Richtungen am Anfang, gebaut wird danach mit den echten Komponenten. Kostet ein, zwei Tage mehr und ist immer noch schneller als der Weg ohne Prototyp. Warum mir das System selbst wichtig ist, steht in Warum ein Designsystem mehr ist als nur ein Styleguide.

Wo der Ansatz an seine Grenzen kommt

Wenn ich das nur verkaufen wollte, würde dieses Kapitel fehlen. Es gibt zwei Situationen, in denen ich aufpassen muss.

Wenn der Prototyp für fertig gehalten wird. Etwas, das aussieht wie ein Produkt, wird für eines gehalten – „das ist doch fast fertig“ ist der Satz, gegen den ich anrede. Deshalb sage ich in jedem Termin denselben Satz dazu: Die Inhalte sind Platzhalter, mit Absicht, und alles hier darf noch geändert werden. Ein hoher Detailgrad ist der Grund, warum der Ansatz funktioniert, und gleichzeitig sein größtes Risiko.

Wenn jemand erwartet, dass die KI die Arbeit macht. Sie macht sie nicht. Sie ist schnell bei Layout-Ideen, Struktur-Vorschlägen, Platzhaltertexten und Wiederholungen. Sie ist schlecht bei allem, worauf es später ankommt: Zustände vollständig durchdenken, Mikro-Interaktionen, Kontraste, Beschriftungen für Screenreader, das Raster einhalten. Die fünf Tage sind fünf Tage meiner Arbeit, in denen mir die KI die leere Seite abnimmt. Mehr dazu in KI als Sparringspartnerin – wofür genau.

Der Prototyp ersetzt die Anforderungen nicht. Er stellt sie zur Probe – in einer Form, auf die Menschen antworten, solange Antworten noch nichts kosten.

Und der Grundriss? Der bleibt zuerst.

An anderer Stelle in diesem Blog steht, dass ich mit dem Grundriss anfange und die Reihenfolge nicht verhandelbar ist: erst die Fragen, dann das Fundament, dann das Sichtbare. Daran ändert sich hier nichts. Der Prototyp ist der Grundriss – nur eben ein klickbarer.

Der erste Schritt bleibt derselbe: klären, was das Ding leisten muss, bevor gebaut wird. Was sich ändert, ist die Form, in der ich diese Frage stelle. Und darüber entscheidet nicht mein Geschmack, sondern die Zahl der Menschen, die am Ende zustimmen müssen.

• Eine Website, fünf Seiten, eine Entscheiderin. Da ist das Textdokument die schnellste und billigste Form. Wir sitzen zusammen, sortieren die Seiten, und niemand muss sich etwas vorstellen, was er nicht kennt.
• Ein System, vierzig Screens, zehn Beteiligte aus drei Abteilungen. Da ist das Textdokument die Stelle, an der Projekte scheitern – nicht weil es schlecht geschrieben ist, sondern weil zehn Menschen es nicht gleich lesen können. Dort ist der Prototyp der Grundriss.

Beides ist dieselbe Frage: Was muss das können, und für wen? Nur die Form, in der ich sie stelle, richtet sich danach, wie viele Menschen sie beantworten müssen.

---