Prototyping, bevor sich die Entwicklung festlegt.
Sie brauchen keine weitere Designpräsentation. Sie brauchen Sicherheit darüber, was gebaut werden soll. Ich mache aus einer offenen Produktentscheidung einen realistischen Prototyp, den Ihr Team prüfen, hinterfragen — und auf den es sich festlegen kann.
01 — Der Prototyp
Er verhält sich wie das Produkt. Er ist nicht das Produkt.
Ein Prototyp ist hier etwas, mit dem sich jemand, der Ihr Produkt noch nie gesehen hat, hinsetzen und arbeiten kann: echte Aufgaben, realistische Daten, die Zustände, die im Alltag tatsächlich vorkommen — leer, fehlerhaft, wartend, erledigt. Er ist auf die eine Entscheidung zugeschnitten, die wir prüfen; alles außerhalb davon bleibt bewusst grob.
Genau das macht ihn zum Beleg. Wenn jemand zögert, falsch abbiegt oder ohne Hilfe ans Ziel kommt, ist das eine Reaktion auf das Produkt — nicht auf seine Beschreibung.
- Kein Foliensatz. Einen Foliensatz kann niemand falsch bedienen — also verrät er nichts.
- Kein Wireframe. Kästen verhalten sich nicht, und das Verhalten ist das Unsichere.
- Kein pixelgenaues Design. Politur beantwortet eine Frage, die noch niemand gestellt hat.
- Kein MVP. Nichts davon geht live; der Prototyp ist da, um nach der Entscheidung wegzufallen.
02 — Die vier Wochen
Vier Wochen, eine Entscheidung — und was jede Woche hervorbringt.
Der Überblick steht auf der Startseite. Hier steht, was darunter liegt: was passiert, was ich von Ihnen brauche und was am Ende jeder Woche bei Ihnen bleibt.
- Woche 1Die Entscheidung benennen — und was sie kostet.
- Was passiert
- Zwei bis drei Arbeitssitzungen mit den Menschen, die die Entscheidung verantworten. Wir halten in einem Satz fest, worum es geht, was das Festlegen kostet, auf welcher Annahme die Entscheidung ruht und was zutreffen müsste, damit sie trägt. Lässt sich diese Seite nicht schreiben, ist das bereits die Erkenntnis.
- Was Sie einbringen
- Die Person, die entscheidet, ein bis zwei Stunden derer, die den Nutzern am nächsten sind, und alles, was schon existiert — Konzept, Anforderungen, Daten, der Foliensatz.
- Was bei Ihnen bleibt
- Das einseitige Entscheidungsblatt. Es gehört Ihnen, ob wir weitermachen oder nicht.
- Woche 2Das bauen, worauf Menschen reagieren können.
- Was passiert
- Ich baue den Prototyp entlang des Entscheidungsblatts: den Ablauf, von dem die Entscheidung abhängt, mit realistischen Daten und den Zuständen, die in der Praxis auftreten. Wir legen die Aufgaben fest, die Menschen bekommen werden, und was ein gutes oder ein schlechtes Ergebnis wäre — bevor irgendjemand den Prototyp sieht.
- Was Sie einbringen
- Beispieldaten samt der unbequemen Fälle, eine Stunde mit einer Fachexpertin oder einem Fachexperten und ein Ja zur Aufgabenliste.
- Was bei Ihnen bleibt
- Ein funktionierender Prototyp, der sich im Browser öffnen lässt, und die Aufgabenliste, an der er geprüft wird.
- Woche 3Vor die Menschen bringen, die damit arbeiten würden.
- Was passiert
- Sitzungen mit den Menschen, die das Produkt nutzen würden — in der Regel fünf bis acht pro Runde, eine Runde pro Entscheidung. Jede Person arbeitet die Aufgaben durch; ich beobachte und halte fest, was sie tut, wo sie zögert und was sie ungefragt sagt. Ihr Team darf gern zusehen.
- Was Sie einbringen
- Die Teilnehmenden. Ihre Anwender, Ihre Nutzer, Ihre internen Fachleute — die Menschen, deren Reaktion zählt.
- Was bei Ihnen bleibt
- Die Erkenntnisse aus der Studie: was passiert ist, je Aufgabe und je Person — und was das für die Annahme bedeutet.
- Woche 4Entscheiden, schriftlich.
- Was passiert
- Ich schreibe die Empfehlung: bauen, die Richtung ändern oder es lassen — mit den Belegen dazu — und die Produktlogik, Anforderungen und Designentscheidungen, die daraus folgen. Wir gehen sie gemeinsam durch.
- Was Sie einbringen
- Den Entscheidungstermin, mit den Menschen, die sich festlegen können.
- Was bei Ihnen bleibt
- Die schriftliche Empfehlung, der Prototyp, die Erkenntnisse, das Entscheidungsblatt. Alles, was die Entwicklung zum Start braucht — oder der Grund, nicht zu starten.
Was ich nicht tue: die Entscheidung treffen. Die Belege und die Empfehlung sind meine Arbeit; festlegen müssen Sie sich selbst.
03 — Die Prüfung
Verhalten statt Vorlieben.
Wer Menschen fragt, ob ihnen etwas gefällt, erntet Höflichkeit. Wer ihnen eine Aufgabe gibt, sieht Verhalten. Die Sitzungen sind um Aufgaben gebaut, für die das Produkt tatsächlich gebraucht wird: das hier abschließen, jenes finden, entscheiden, ob dieser Fall freigegeben wird. Was zählt, ist, was Menschen tun — und ob sie vorhersehen können, was das Produkt als Nächstes tut.
Die Sitzungen finden standardmäßig remote statt, vor Ort, wenn die Arbeit oder die Nutzer es verlangen. Die Teilnehmenden kommen von Ihnen: Die Menschen, deren Reaktion zählt, kennen Sie bereits — und eine Runde von fünf bis acht sagt für eine Entscheidung, was man wissen muss. Ist kein Zugang zu Nutzern möglich, ist das der falsche Auftrag — und das zeigt sich besser in Woche eins als danach.
Hat eine Entscheidung zwei glaubwürdige Antworten, werden beide gebaut und an denselben Aufgaben geprüft. Für eine Companion App von Mercedes-Benz habe ich das im größeren Maßstab getan — 32 Menschen, zwei Interaktionsmodelle, identische Aufgaben — als Masterarbeit in Zusammenarbeit mit Mercedes-Benz. Dasselbe Prinzip, kleinere Runde.
04 — Wo es wirkt
Komplexe Produkte, teure Festlegungen.
Das Vorgehen lohnt sich dort, wo Irrtümer teuer und schwer rückgängig zu machen sind: Enterprise- und B2B-Produkte mit Abläufen, die niemand vollständig überblickt; KI-Funktionen, deren Wert davon abhängt, ob Menschen ihnen vertrauen; Interfaces, in denen jeder Bildschirm eine Entscheidung ist, für die jemand geradesteht.
- Enterprise-Abläufe — ein Designsystem und eine Community of Practice am CERN, entstanden aus der Suche nach den Entscheidungen, die jedes Team doppelt traf.
- Verhalten über Geräte hinweg — eine Studie für Mercedes-Benz zu der Frage, ob Vertrautheit von der Plattform oder vom Produkt kommen sollte.
- KI, die sich überprüfen lässt — ein Prüfablauf bei PwC rund um eine Frage: Warum hat die KI diese Vorhersage getroffen?
Das waren Anstellungen und eine Masterarbeit, keine Vier-Wochen-Aufträge. Aus ihnen stammt das Vorgehen.
Für KI-Workflows im Besonderen: KI-Produkte gestalten, die sich überprüfen lassen
05 — Fragen
Reichen vier Wochen wirklich?
Für eine Entscheidung: ja — und die Grenze ist der Sinn der Sache. Das Entscheidungsblatt in Woche eins verengt die Arbeit auf die Annahme, von der alles andere abhängt. Ruht eine Entscheidung tatsächlich auf drei Annahmen, sind das drei Runden, nicht eine längere.
Was, wenn wir keine Nutzer erreichen können?
Dann sollten wir vorher sprechen, nicht nachher. Interne Fachleute, Pilotanwender oder Partner sind für eine erste Runde oft ein guter Ersatz. Lässt sich niemand erreichen, der mit dem Produkt arbeiten würde, wären die Belege schwach — und das sage ich lieber vorher.
Was bekommen wir, wenn die Antwort „nicht bauen“ lautet?
Dieselben Unterlagen wie bei „bauen“: das Entscheidungsblatt, den Prototyp, die Erkenntnisse, die schriftliche Empfehlung. Ein Quartal Entwicklung, das nicht stattfindet, ist das günstigste Ergebnis, das diese Arbeit haben kann.
Behalten wir den Prototyp? Kann die Entwicklung darauf aufbauen?
Sie behalten alles. Der Prototyp ist gebaut, um geprüft zu werden, nicht um live zu gehen — die Entwicklung baut auf der Empfehlung, der Produktlogik und den Anforderungen auf und nutzt den Prototyp als Referenz dafür, wie sich das Produkt verhalten soll.
Welche Entscheidung wartet gerade auf Belege?
Erzählen Sie mir, worauf Sie sich festlegen sollen. Ein erstes Gespräch reicht, um zu sehen, ob es eine Entscheidung ist — und ob vier Wochen sie absichern würden.