Hauptgedanke

Der Nutzer, den man im Konzeptionsworkshop beschreibt, und der, der tatsächlich vor Ort arbeitet, sind selten derselbe: Der zweite hat Einschränkungen, Gewohnheiten, Abkürzungen, Umgehungslösungen, eine mentale Last und Widerstände, die der erste nicht hat — weil der erste von denen erdacht wurde, die das Produkt entwerfen.

Den Screen schneller herzustellen, bringt diese beiden Figuren einander nicht näher. Eine schlechte Antwort auf ein echtes Problem bleibt eine schlechte Antwort, auch wenn sie in wenigen Minuten generiert wurde; die Geschwindigkeit ändert nur den Zeitpunkt, an dem man merkt, dass sie schlecht war — und die Zahl der falschen Varianten, die bis dahin entstanden sind.

Was zwei Teams voneinander unterscheidet, ist also nicht das Entwicklungstempo, sondern die Qualität dessen, was sie wissen: wie die Leute wirklich arbeiten, was sie tolerieren, was sie ablehnen, was sie sich nicht zu sagen trauen, und was sich je nach Rolle, Branche, digitaler Reife oder Unternehmensgröße ändert.

Ergänzt durch „PM, Entwickler und KI: Die Rollen verschwimmen, die Verantwortung bleibt“ (2026-08-01). Dieselbe Feststellung gilt für den Prototyp und legt fest, wann er nützt: Ein in wenigen Stunden gebauter Prototyp ist nur etwas wert, wenn er ein echtes Kundensignal prüft. Andernfalls beschleunigt er bloß eine falsche Richtung — und das Tempo, in dem er entstanden ist, dient dann als Argument, den weiteren Weg darauf aufzubauen.

Warum das wichtig ist

Das verhindert, das schnelle Generieren von Oberflächen als Verringerung des Produktrisikos zu lesen. Es senkt die Kosten eines Versuchs, was nützlich ist; den Abstand zwischen dem angenommenen und dem tatsächlichen Nutzer verringert es nicht — und genau das ist das fragliche Risiko.

Das benennt auch, was man im Gegenzug finanzieren muss, wenn die Entwicklung schneller wird: Wer die Vorschläge vervielfacht, ohne die Gelegenheiten zu vervielfachen, die Arbeit vor Ort zu beobachten, produziert mehr ungeprüfte Antworten.

Nuancen und Grenzen

Schnell zu produzieren kann dem Verstehen dienen, wenn das Mockup als Beobachtungsinstrument eingesetzt wird — früh gezeigt, direkt am Arbeitsplatz, um Reaktionen auszulösen. Der Gewinn kommt dann aus dem Kontakt, nicht aus dem Generieren.

Und manche Missverständnisse zeigen sich erst bei längerer Nutzung: Kein Iterationsrhythmus bringt sie innerhalb einer Woche ans Licht.

Offene Fragen

• Wie oft muss man die Arbeit vor Ort beobachten, damit die schnellere Entwicklung den Abstand zum tatsächlichen Nutzer nicht vergrößert?