Papier Prototyp – paper prototyping
15.10.2007Da wir eine innovative Anwendung entwickeln, zu der es momentan wenige ähnliche Produkte am Markt gibt, fällt es dem Team oft schwer, sich konkrete Handlungsabläufe vorzustellen und sich in den Nutzer des System hineinzuversetzten. Um ein schärferes Bild von den Aufgaben der Nutzer und deren Abläufen zu erhalten, haben wir einen Prototypen unserer Benutzerschnittstelle auf Papier entworfen und anhand diesem mögliche Nutzungszenarien durchgespielt.
Was ist ein Prototyp?
Als Prototypen bezeichnet man eine erste Frühversion eines Produkts. Es gibt unterschiedlichste Formen von Prototypen: gezeichnete Storyboards, Wireframes, Modelle aus Pappe und Papier, Klickdummies im PDF oder Powerpoint Format.
Z.b. wurde der PalmPilot in Form eines Stück Holz das erste Mal von seinem Erfinder Jeff Hawkin durch die Gegend getragen. So wurde protypartig die neuartige Mobilität eines Kleinstrechners getestet.
Unser Prototyp bestand im Wesentlichen aus ausgeschnittenen Papierstückchen, mit funktionalen oder inhaltlichen Elementen., wie z.B. anklickbarer Link, Nutzerbild oder Navigationsleiste. Diese haben wir auf einem Papierblock entsprechend eines Systemstatus angeordnet und anschließend abfotografiert. So wurden alle Stati als Bild festgehalten.
Unser Vorgehen im Detail:
Zuerst wurden alle Prozesse und Aufgaben definiert, die der Nutzer im System tätigen kann.
Hier ist beispielhaft einer der Prozesse beschrieben:
Link „Jetzt registrieren“ anklicken -> Username, E-Mail, PW definieren -> Formular absenden -> User anlegen, einloggen, Willkommensnachricht und E-Mail mit Zugangsdaten zustellen (System) -> Ansicht „Persönliche editieren“ als Unterpunkt von „Persönliche Daten“ unter „Mein Profil“ anzeigen -> Statusmessage anzeigen (System)
Neben den Prozessen wurden auch unterschiedliche Navigationsebenen sowie die Priorisierung einzelner Elemente definiert. Der Registrierungsprozess wird nachfolgend als Beispiel komplett durchspezifiziert inklusive Anordnung der einzelnen Formular Elemente und Berücksichtigung aktiver Menupunkte.
Ein Ausschnitt der Prozessdefinition Registrieren
Wir haben die verschiedenen Zustände der Software jeweils auf einem Din A4 Block angeordnet und den jeweiligen Status mit einer Digicam abfotografiert. Das Bild erhält den Namen des dargestellten Systemzustandes (z.b. User_Registrieren.jpg). Um später die einzelnen Stati besser ausfindig machen zu können, empfiehlt es sich dem Papier Mockup auch einen geschriebenen Title aufzuerlegen.
Nach einem Tag Arbeit hatten wir über 30 Fotos geschossen, hier ist eins zu sehen:
Warum diese Vorgehen?
Das beschriebene Vorgehen ermöglicht vorallem Diskussion am „lebenden“ Objekt. Jeder Teilnehmer hat eine plastische Vorstellung der zu diskutierenden Problemfälle, man kann sich gut in eine mögliche Nutzung hinein versetzen und zu Lösungen gelangen.
Typische Fragen, die in unserer Diskussion auftauchten:
- Welche Erwartungen hat der Nutzer, wenn er auf diesen Link klickt?
- Entsprechen die dargestellten Elemente dem Erfahrungshorizont des Nutzers?
- Müssen diese Icons mit einer Legende erklärt werden?
- Passen die Elemente überhaupt auf eine 1024/768 Auflösung?
Eine iterative Verbesserung des Prototyps ist so schnell und einfach möglich, da es sich ja um bewegliche Papierschnipsel handelt.
Weiterverarbeitung
Der Prototyp dient als Vorlage für den Designer. Man sollte, wenn die Fotos zu wild aussehen, ein paar ordentlich formatierte Powerpoint Screens aus den Vorlagen erstellen. Wir haben das mit ein paar Screens exemplarisch gemacht.
Definierung der Prozesse für den Programmierer
Der Programmierer wird exakt gebrieft, da sowohl das I18n wording als auch mögliche Validierungen von Fomularelemten von uns vorher spezifiziert wurden.
So gibt es keine Unklarheiten darüber, was eigentlich zu programmieren ist.
Dieser Prototyp ist außerdem eine gute Vorlage für einen frühen Usertest, der anhand von klickbaren Powerpoint Folien durchgeführt werden könnte.
Leider befinden wir uns ja in einem rapid developement Prozess, so dass frühe Usertests ausfallen.
Im Fachjargon nennt man diese Art von Prototyp übrigens Low Fidelity Prototype.
Vorteile
- Flexibel
- Effizient
- Schnell
- Kommunikation mit Teammitgliedern
- Problemlösungsorientiert
Nachteile
- Keine Interaktion
- Kein Gefühl der Benutzung
- Sieht nicht aus wie die spätere Anwendung
- Kann keine Nutzertests eines realen Systems ersetzen