Manchmal, so hat man den Eindruck, werden Prototypen gebaut, weil es so sein muss, weil man meint, dass man Prototypen baut, wenn man es »richtig« machen will.
Es scheint, dass manche Menschen gehört haben, dass man eine Idee mit einem Prototypen prüfen muss, bevor man sie weiter entwickeln kann. Dann wird ein Prototyp erstellt – bei einer App geht das relativ einfach, ein paar Postit genügen – und flugs kann man weitermachen. Aber so ein Prototyp ist wertlos, hilft einem keinen Millimeter weiter, wenn es keine zu prüfende Annahme gibt. Ein Prototyp ohne Arbeitshypothese ist ohne Aussage.
Es geht um die Bestätigung einer Hypothese. Das ist der Kern des Abduktiven Schließens (ihr erinnert euch? Design-Thinking ist abduktives Schließen). Wir stellen eine Hypothese, die ein Ergebnis selbstverständlich macht; wir führen eine Testsituation herbei und bekommen die These bestätigt oder eben nicht.
Wir bauen Prototypen, damit wir uns sicher sind. Niemals bauen wir sie, nur um einen Prozess zu befolgen. Keinesfalls ist es dienlich einen Prototyp zu bauen, diesen dann einigen Kunden zu zeigen und zu sehen, wie die damit umgehen und dann festzustellen, so gut wie der Prototyp ist, so gut können die damit umgehen. Fertig. Ohne passende Aufgabe, ohne Ziel kann man nicht beurteilen, wie gut das Ziel erreicht, die Aufgabe erledigt werden konnte.
Nein, jeder Prototyp hat ein Ziel, will etwas beweisen. Mit dem ersten Prototyp wollen wir uns selbst beweisen, dass wir eine richtige Annahme getroffen haben, dass unsere Überlegungen stimmen. Wir wollen sehen, dass eine Formel, ein Ablauf, eine Überlegung zutrifft.
Ein einfaches Beispiel findet sich im Grafikdesign. Der erste Prototyp zeigt die ausgewählte Schrift in der festgelegten Schriftgröße und Zeilenlänge auf einem Papier ausgedruckt und beweist, dass diese Schrift gut lesbar ist. Man hat es richtig erraten oder Kraft seiner Erfahrung richtig festgelegt. Nun »baut« man den nächsten Prototyp: kann man damit einen Brief schreiben, der gut lesbar ist, der gefällt, der den gewünschten Eindruck erzeugt, ist das Adressfeld im Fenster des Kuverts sichtbar, etc.? Wie funktioniert die Schrift mit längeren Texten, habe ich genügend Möglichkeiten für die möglicherweise notwendigen Gliederungen, wie schreibe ich Überschriften und bilde Hierarchien, was passiert mit Tabellen?
Erst wenn ich, der Designer, überzeugt bin richtig entschieden zu haben, hole ich andere (die Nutzer) dazu und lasse nun diese prüfen, ob sie den Text auch gut lesen können, ob sie die Gliederung des Textes verstehen, etc.
Bei einem Briefbogen mag das jedem klar sein, bei einer App übersieht man das gelegentlich.
Doch insbesondere bei der App will ich erkennen können, dass ich alles bedacht habe, das zu bedenken ist.
Ich will zuerst sicher sein, dass die App das macht, was ich mir ausgedacht habe. Erfüllt sie die ihr zugedachte Funktion? Welche Funktion wünsche ich mir denn überhaupt dafür? Liefert mein Algorithmus die gewünschten Ergebnisse? Der Prototyp zeigt zuerst nur mir – mir selbst – die Funktionsfähigkeit meines Konstrukts.
Erst wenn diese Funktionsfähigkeit gelungen ist, erst wenn damit brauchbare Ergebnisse generiert werden können, muss ich Fremde, die zukünftigen Nutzer, damit konfrontieren. Vorher können die nämlich keine Auskunft geben, sondern (wenn sie freundlich sind) bloß bestätigen, dass ich etwas erarbeitet habe.
Jetzt gilt es die Dinge so anzuordnen, dass ich annehmen kann, dass auch mit diesem Thema wenig vertraute Personen damit zurecht kommen. Sind meine Überlegungen auch für andere sinnfällig, die nicht mein Hintergrundwissen dazu haben? Ich will wissen, ob die Nutzer erkennen, wo sie klicken müssen und was sie mit der App tun können.
Dazu beobachte ich und interpretieren deren Verhalten.
Wie und was wir aus den Tests mit Prototypen lernen können, will ich extra behandeln. Hier geht es darum klar zu stellen, dass ein Prototyp eine Hypothese überprüft, wir also zuvor bestimmen müssen, was wir herausfinden wollen.
Prototypen unterschiedlicher Qualität und Detailiertheit erstellen wir immer dann, wenn wir Annahmen überprüfen wollen. Zum Erkenntnisgewinn. Meist ist das dann der Fall, wenn UX-Designer, UI-Designer, Marketeer, Verkäufer, Entwickler, etc. uneins sind, wie sich Nutzer (User) wohl verhalten werden. Ein Streit ist schnell beigelegt, der Gebrauch entscheidet. Doch auch das erfordert die drei Kerneigenschaften des Design-Thinkings.
Also published on Medium.
