Prototyping: Was es ist, worauf es beruht und wo die Schulen sich unterscheiden

Kurzfassung

Prototyping heißt, eine Idee früh und billig greifbar zu machen, um aus der Reaktion darauf zu lernen, bevor viel Geld in die Umsetzung fließt. Das lohnt sich nur unter Bedingungen: wenn niemand vorab wissen kann, was funktioniert, wenn Bauen billiger ist als Irren und wenn eine Organisation ein Nein gelten lässt.

Gut belegt ist, dass schon einfache Prototypen aus Papier die meisten Bedienprobleme aufdecken. Dass Prototyping Vorhaben insgesamt erfolgreicher macht, stützt sich dagegen vor allem auf Einzelfälle.

Was ein Prototyp leisten soll, hängt von der Schule ab. In der Softwaretechnik klärt er Anforderungen, im Design ist er ein Denkwerkzeug, im Lean Startup ein Experiment über Nachfrage. Das Etikett „Rapid“ meint je nach Fach ein Fertigungsverfahren, den Wegwerf-Prototyp oder schlicht Tempo.

Was ein Prototyp sein kann

Ein Prototyp ist nicht durch sein Material bestimmt, sondern durch die Frage, die er beantworten soll. Das kann eine Papierskizze sein, ein klickbarer Entwurf, ein Stück lauffähiger Code oder ein Holzklotz.

Drei Unterscheidungen helfen, Prototypen einzuordnen:

• Was geprüft wird. Stephanie Houde und Charles Hill, damals Designforscher bei Apple, schlugen 1997 drei Fragen vor: welche Rolle ein Produkt im Leben seiner Nutzer spielt, wie es sich anfühlt und bedient (look and feel) und ob es sich technisch umsetzen lässt. Ein Holzmodell in Gerätegröße prüft vor allem die Rolle, kaum die Technik.
• Wie detailgetreu er ist. Prototypen mit geringer Detailtreue (low fidelity, etwa Papier) sind schnell geändert und laden zu grundsätzlicher Kritik ein. Solche mit hoher Detailtreue (high fidelity) sehen fertig aus und zeigen Feinheiten der Bedienung, verleiten aber dazu, nur noch über Farben und Knöpfe zu sprechen.
• Was danach mit ihm geschieht. Ein Wegwerf-Prototyp dient nur dem Lernen und wird danach verworfen. Ein evolutionärer Prototyp wird zum Kern des späteren Systems ausgebaut.

Je näher ein Prototyp an einer Ecke liegt, desto gezielter beantwortet er deren Frage. In der Mitte steht der integrierte Prototyp, der alle drei Fragen zugleich stellt und entsprechend aufwendig ist. Hervorgehoben ist der Holzklotz des PalmPilot.

Bill Buxton, Designforscher bei Microsoft Research, zieht eine weitere Linie: Skizzen dienen dazu, Möglichkeiten aufzufächern und Fragen zu stellen, Prototypen dazu, eine ausgewählte Möglichkeit zu prüfen. Beides gehört zum Prototyping im weiteren Sinn, verlangt aber eine andere Haltung.

Und was heißt „rapid“? Das Wort wird in drei Bedeutungen verwendet, die sich leicht verwechseln lassen:

• In der Fertigung ein Herstellungsverfahren, bei dem Bauteile direkt aus Konstruktionsdaten entstehen, heute meist 3D-Druck genannt. Als Ausgangspunkt gilt die Stereolithografie, die der amerikanische Ingenieur Chuck Hull 1986 patentieren ließ.
• In der Softwaretechnik häufig ein Synonym für den Wegwerf-Prototyp, im Gegensatz zum evolutionären. Davon zu unterscheiden ist Rapid Application Development (RAD), eine Entwicklungsmethode, die James Martin Anfang der 1990er-Jahre bekannt machte und in der Prototypen zum Produkt weiterwachsen.
• In Design und Lean Startup schlicht die Betonung von Tempo und geringen Kosten. Hier ist Rapid Prototyping kein eigenes Konzept, sondern eine Haltung innerhalb des Prototyping.

Dieser Artikel verwendet Prototyping im weiten Sinn, evolutionäre Prototypen eingeschlossen.

Wozu Prototypen dienen und was die Belege hergeben

Prototypen werden für fünf Zwecke eingesetzt. Die Belege dafür sind unterschiedlich stark, und es lohnt sich, sie auseinanderzuhalten.

Klären, was gebraucht wird. Viele Anforderungen lassen sich vorab nicht vollständig aufschreiben, weil die Beteiligten sie selbst erst erkennen, wenn sie etwas vor sich sehen. Die Informatikerin Christiane Floyd nannte diesen Zweck 1984 exploratives Prototyping. Das Argument ist gut begründet, aber vor allem durch Erfahrungsberichte belegt, nicht durch Vergleichsstudien.

Eine gemeinsame Sprache schaffen. Ein greifbarer Entwurf macht sichtbar, was in einem Konzepttext jeder anders versteht. Fachleute, Entwicklung und Leitung reden dann über dasselbe Ding statt über ihre jeweilige Vorstellung davon.

Bedienprobleme früh finden. Hier ist die Forschung am dichtesten. Mehrere Studien seit den 1990er-Jahren fanden mit Papierprototypen ungefähr dieselben Bedienprobleme wie mit fertig wirkenden Software-Prototypen, etwa Virzi, Sokolov und Karis (1996) sowie Walker, Takayama und Landay (2002). Weniger verlässlich sind Prototypen für Bearbeitungszeiten und für das ästhetische Urteil über das spätere Produkt. Der dänische Usability-Forscher Jakob Nielsen zeigte zudem, dass schon fünf Testpersonen den größten Teil der Bedienprobleme aufdecken. Er empfahl allerdings, mehrere kleine Testrunden mit Überarbeitungen dazwischen durchzuführen, und die Regel gilt nur für Nutzer mit ähnlichen Aufgaben.

Bessere Lösungen durch Vergleich. In einem Experiment von Steven Dow und Kollegen an der Stanford University (2010) entwarfen Teilnehmende Werbebanner. Wer mehrere Entwürfe gleichzeitig baute und Rückmeldung zu allen bekam, erzielte bessere Ergebnisse als wer einen einzigen Entwurf nacheinander verbesserte. Die Entwürfe waren vielfältiger, und die Teilnehmenden gewannen mehr Vertrauen in die eigene Gestaltungsfähigkeit (Selbstwirksamkeit).

Nachfrage prüfen, bevor gebaut wird. Ein Erklärvideo oder eine Landingpage zeigt, ob sich Menschen für etwas interessieren, das es noch nicht gibt. Belegt ist das vor allem durch eindrückliche Einzelfälle, und man hört vor allem von denen, die gut ausgingen.

Ein häufiges Argument fehlt in dieser Liste bewusst: dass ein Fehler in den Anforderungen, der erst im Betrieb entdeckt wird, ein Vielfaches dessen kostet, was er zu Beginn gekostet hätte, oft mit Faktor 100 beziffert. Die Richtung ist plausibel. Die genauen Zahlen gehen aber auf wenige ältere Projektdaten zurück, und der französische Softwareentwickler Laurent Bossavit hat gezeigt, wie dünn ihre Grundlage ist.

Worauf der Ansatz beruht

Prototyping lohnt sich nicht immer. Es setzt mehrere Annahmen voraus, und wo eine davon nicht zutrifft, verliert der Ansatz seinen Nutzen.

1. Die Unsicherheit ist echt. Prototyping hilft, wenn sich durch Nachdenken und Expertise allein nicht klären lässt, was funktioniert. Im Cynefin-Modell sind das komplexe Lagen, in denen Ursache und Wirkung erst im Nachhinein erkennbar werden. Ist ein Problem nur kompliziert, also mit genug Fachwissen lösbar, bringt ein Prototyp wenig, was eine gute Analyse nicht auch liefern würde.
2. Bauen ist billiger als Irren. Der Ansatz rechnet sich nur, wenn ein Prototyp deutlich weniger kostet als eine falsche Entscheidung. Bei Software und Dienstleistungen ist das meist so, bei einer Chemieanlage oder einem zulassungspflichtigen Medizinprodukt nur für Teilfragen.
3. Die Reaktion auf den Prototyp sagt etwas über das spätere Produkt. Menschen verhalten sich in einer Testsituation anders als im Alltag, und was sie über ein Produkt sagen, weicht oft von dem ab, was sie später tun. Je mehr ein Test auf Meinungen statt auf Verhalten beruht, desto schwächer ist diese Annahme. Darum legen Vertreter des Pretotyping großen Wert darauf, Verhalten zu beobachten, etwa ob jemand sich einträgt, bezahlt oder wiederkommt.
4. Es werden die Richtigen gefragt. Ein Test mit Kolleginnen aus dem Projekt oder mit besonders technikaffinen Freiwilligen zeigt etwas anderes als ein Test mit den Menschen, die das Produkt später nutzen sollen.
5. Die Organisation kann ein Nein hören. Ein Prototyp nützt nur, wenn sein Ergebnis eine Entscheidung verändern darf. Wer schon viel investiert hat oder sich öffentlich festgelegt hat, neigt dazu, ein enttäuschendes Ergebnis umzudeuten (siehe Sunk-Cost-Effekt und kognitive Dissonanz). Wo Fehlschläge dem Ansehen schaden, wird zudem eher abgesichert als erprobt (psychologische Sicherheit).

Die Tafel zeigt nur die ersten beiden Annahmen. Auch im Feld oben links bringt ein Prototyp nichts, wenn er Meinungen statt Verhalten misst, die falschen Menschen fragt oder sein Ergebnis keine Entscheidung verändern darf.

Man kann den Ansatz auch mit Robin Hogarths Unterscheidung von kind und wicked Lernumgebungen lesen. Produktentwicklung ist meist eine wicked Umgebung: Ob eine Entscheidung richtig war, zeigt sich spät und verrauscht. Ein Prototyp verkürzt diese Rückmeldeschleife künstlich und macht die Umgebung für eine Teilfrage etwas freundlicher.

Vier Schulen: Herkunft und Streitfragen

Unter dem Wort Prototyp verstehen verschiedene Fachrichtungen Verschiedenes. Sie teilen das Grundprinzip, unterscheiden sich aber darin, welche Frage ein Prototyp beantworten soll und wann ein Ergebnis als Erfolg gilt.

In der Softwareentwicklung wurde Prototyping in den 1980er-Jahren zum Gegenentwurf zum Wasserfallmodell, bei dem alle Anforderungen vorab festgeschrieben werden. Die Informatikerin Christiane Floyd, 1978 die erste Professorin für Informatik in Deutschland und später an der Universität Hamburg, ordnete das Feld 1984 in einem viel zitierten Aufsatz. Sie unterschied drei Zwecke: explorativ (herausfinden, was gebraucht wird), experimentell (prüfen, ob eine geplante Lösung taugt) und evolutionär (das System schrittweise aus dem Prototyp heraus weiterentwickeln).

Design und Mensch-Computer-Interaktion bauten den Prototyp seit den 1990er-Jahren zum Denkwerkzeug aus. Lean Startup und Pretotyping machten ihn um 2010 zum Test für Nachfrage, und der Design Sprint fasste 2016 vieles davon in ein festes Wochenformat. Gemeinsam ist allen der Gedanke, dass man manche Fragen nicht durch Nachdenken und Abstimmen beantworten kann, sondern nur durch Ausprobieren.

Die Grenzen sind fließend: Die Softwaretechnik kennt seit Floyd auch das Erkunden, und Design Sprints prüfen neben der Bedienung oft auch, ob überhaupt Interesse besteht. Die Tabelle nennt die Einzelheiten.

Drei Begriffe aus Lean Startup und Pretotyping: Eine Fake Door (Scheintür) ist ein Knopf oder Angebot für etwas, das es noch nicht gibt; gezählt wird, wer darauf klickt. Beim Wizard of Oz glauben Testpersonen, ein System arbeite automatisch, während ein Mensch im Hintergrund die Antworten liefert. Savoias Prüfregel, die XYZ-Hypothese, verlangt vorab eine Zahl: Mindestens X Prozent von Y werden Z tun.

Zwischen diesen Schulen gibt es fünf Streitfragen, die bis heute offen sind.

Wegwerfen oder weiterentwickeln? Fred Brooks, Leiter der Softwareentwicklung für IBMs Großrechner System/360, riet 1975, das erste System grundsätzlich als Wegwerfversion einzuplanen. Zwanzig Jahre später nahm er den Rat zurück: Er habe das Wasserfallmodell vorausgesetzt, schrittweises Bauen und Verfeinern sei besser. Evolutionäre Prototypen sparen doppelte Arbeit, bergen aber die Gefahr, dass Provisorien ungeprüft zur Dauerlösung werden.

Wie detailgetreu? Die Studien zu Papier und Software sprechen eher für einfache Prototypen, solange es um Bedienprobleme geht (siehe oben). Mit Werkzeugen, die lauffähige Oberflächen in kurzer Zeit erzeugen, verschiebt sich die Kostenrechnung. Das alte Gegenargument bleibt: Was fertig aussieht, lädt zu Detailkritik ein und erschwert grundsätzliche Einwände.

Erkunden oder prüfen? Die Designschule versteht Prototypen vor allem als Denkwerkzeug, mit dem man Möglichkeiten erst entdeckt. Lean Startup versteht sie als Experiment, das eine Annahme widerlegen soll. Kritiker der ersten Sicht bemängeln, dass Erkunden ohne Entscheidungsregel endlos werden kann. Kritiker der zweiten, dass frühes Prüfen den Raum der Möglichkeiten zu schnell verengt.

Was ist ein MVP? Bei Ries ist das Minimum Viable Product die Version eines Produkts, mit der ein Team mit möglichst wenig Aufwand möglichst viel über seine Kunden lernt. Das kann ein Video sein wie bei Dropbox. Im Alltag wird der Begriff dagegen meist für die erste verkaufsfähige Minimalversion verwendet. Zwischen Pretotyp und MVP im Sinne von Ries gibt es eine große Überschneidung.

Wie viel Täuschung ist vertretbar? Scheintüren und Wizard-of-Oz-Tests zeigen etwas, das es nicht gibt. In der Forschung ist dafür eine Aufklärung nach dem Test üblich. In der Praxis wird das oft weggelassen, und gegenüber Kunden oder Bürgern kann es Vertrauen kosten.

Grenzen und Kritik

Neben den unerfüllten Annahmen gibt es typische Schwächen, die in allen Schulen auftreten.

• Die Erwartungsfalle. Ein Prototyp, der fertig aussieht, lässt Auftraggeber glauben, das Produkt sei fast fertig. Dass hinter der Oberfläche Datenhaltung, Sicherheit und Betrieb fehlen, ist von außen nicht zu sehen.
• Die falsche Frage beantwortet. Ein Bedientest zeigt, ob Menschen mit einem Entwurf zurechtkommen, nicht ob sie ihn wollen. Eine Eintragung in eine Warteliste zeigt Interesse, aber noch keine Zahlungsbereitschaft. Schlüsse werden oft weiter gezogen, als der Test hergibt.
• Nur geprüft, was man sich ausgedacht hat. Ein Prototyp testet eine Idee gegen die Wirklichkeit, er erfindet keine bessere. Wer nur einen Entwurf baut, erfährt, ob dieser funktioniert, aber nicht, ob ein anderer besser wäre.
• Der Einzelfall statt des Systems. Ein Prototyp zeigt, wie Einzelne mit etwas umgehen. Wie sich ein Produkt auf Abläufe, Zuständigkeiten und Gewohnheiten in einer Organisation auswirkt, zeigt er kaum (siehe Betrachtungsebenen der Organisation).
• Bestätigung statt Erkenntnis. Prototypen können zum Ritual werden, das eine bereits getroffene Entscheidung nachträglich absichert. Dann wird so lange getestet oder umgedeutet, bis das Ergebnis passt.

Prototyping ist damit weder Allheilmittel noch Modewort. Es ist ein Werkzeug für eine bestimmte Lage: hohe Unsicherheit, günstiges Bauen, beobachtbares Verhalten und eine Organisation, die ein Ergebnis gelten lässt. Welche Schule man wählt, hängt davon ab, welche Frage gerade offen ist.

Quellen

• Floyd, C. (1984): A Systematic Look at Prototyping. In: Budde, R. et al. (Hrsg.): Approaches to Prototyping. Springer.
• Brooks, F. P. (1995): The Mythical Man-Month. Anniversary Edition. Addison-Wesley (Inhaltsverzeichnis mit dem Kapitel zur Revision).
• Houde, S. & Hill, C. (1997): What Do Prototypes Prototype? In: Helander, M. et al. (Hrsg.): Handbook of Human-Computer Interaction. 2. Aufl., Elsevier.
• Buxton, B. (2007): Sketching User Experiences. Morgan Kaufmann.
• Virzi, R. A., Sokolov, J. L. & Karis, D. (1996): Usability Problem Identification Using Both Low- and High-Fidelity Prototypes. CHI ’96.
• Walker, M., Takayama, L. & Landay, J. (2002): High-Fidelity or Low-Fidelity, Paper or Computer? Choosing Attributes When Testing Web Prototypes. HFES Annual Meeting.
• Sauro, J. (2017): Does the Fidelity of a Prototype Affect Results? Überblick über elf Studien.
• Nielsen, J. (2000): Why You Only Need to Test with 5 Users.
• Dow, S. P. et al. (2010): Parallel Prototyping Leads to Better Design Results, More Divergence, and Increased Self-Efficacy. ACM TOCHI 17(4).
• Ries, E. (2011): The Lean Startup. Crown. Zum Dropbox-Video: Ries’ Gastbeitrag bei TechCrunch.
• Savoia, A. (2011): Pretotype It. Selbstverlag; (2019): The Right It. HarperOne.
• Knapp, J., Zeratsky, J. & Kowitz, B. (2016): Sprint. Simon & Schuster.
• Bossavit, L. (2015): The Leprechauns of Software Engineering. Leanpub.
• Computer History Museum: The PalmPilot (Holzmodell von Jeff Hawkins).
• Wikipedia: Software prototyping (Rapid Prototyping als Synonym für Wegwerf-Prototyping).
• Hull, C. W. (1986): US-Patent 4,575,330, Apparatus for Production of Three-Dimensional Objects by Stereolithography.
• Martin, J. (1991): Rapid Application Development. Macmillan.