Hauptgedanke

Mit einem Mockup kann man schon iterieren: Man betrachtet eine Oberfläche, folgt einem Ablauf, merkt, dass ein Button falsch sitzt oder eine Information fehlt. Was es zeigt, ist eine Absicht, und die Einwände, die es hervorruft, richten sich gegen die Absicht.

Ein Produkt, das funktioniert, liefert etwas anderes. Man betrachtet es nicht, man benutzt es: Man wartet, bis eine Liste geladen ist, wiederholt dreimal denselben Handgriff, stellt fest, dass ein Filter nichts bringt, weil die echten Daten nicht die erwartete Form haben. Diese Reibungen sind keine Darstellungsfehler, sondern Eigenschaften des Produkts, und kein Mockup kann sie erzeugen, denn es enthält weder die echten Daten noch die echten Wartezeiten noch die Wiederholung im Gebrauch.

Der Umschwung kommt schrittweise und bleibt fast unbemerkt: Zuerst sieht die Sache aus wie ein Mockup, dann fängt sie an zu funktionieren, dann führt man sie vor, dann kommen Änderungswünsche, dann fragt man, ab wann man sie benutzen kann.

Warum das wichtig ist

Das ändert, was man zuerst baut. Solange eine benutzbare Version sehr viel teurer war als eine Darstellung, war das Mockup der einzig vernünftige Einstieg in eine Iteration. Wenn ein Product Manager in vier Tagen Oberflächen, interne APIs und Datenänderungen zusammensetzt, ist die Darstellung nicht mehr der günstige Schritt.

Es verschiebt auch den Zeitpunkt der Rückmeldung von Nutzern: Sie bezieht sich nicht mehr auf das, was man vorhat, sondern auf das, was existiert – also auf Einwände, die kein Gegenlesen einer Spezifikation hervorgebracht hätte.

Nuancen und Grenzen

Der Vorteil liegt im Realismus, nicht darin, dass es Code ist. Ein Produkt, das mit Testdaten gefüttert wird, zeigt nicht mehr echte Reibungen als ein Mockup: Es zeigt weniger, weil es den Eindruck erweckt, schon erprobt zu sein.

Und das Mockup behält einen Nutzen, den das Produkt nicht übernimmt: mehrere Richtungen zu erkunden, ohne für eine davon zu bezahlen. Ein laufendes Produkt macht es schwer, eine Richtung aufzugeben, gerade weil sie existiert.

Offene Fragen

• Ab welcher Tragweite übersteigen die Kosten, eine benutzbare Version aufzugeben, den Gewinn, sie gebaut statt gezeichnet zu haben?