Paper Prototyping

Claudia Ruch

In der heutigen Zeit stellt sich immer wieder heraus, wie wichtig es ist, die User von Software mit in den Entwicklungsprozess einzubeziehen. Viel zu oft werden ganze Applikationen geschrieben, die jahrelange Entwicklungszeiten hinter sich haben und dann vom User nicht benutzt werden, obwohl die Funktionalität nachgefragt wird. Das Problem liegt also in der Bedienbarkeit der Software. Die Firmen müssen daraufhin diese erste Version von Grund auf überarbeiten und hoffen, dass sie mit der neuen Version mehr Glück haben. Der Kosten – und Zeitaufwand sowohl für die Fehlentwicklung als auch für die Nachbearbeitung sind sehr hoch. Außerdem ist vor allem in der Softwarebranche auch die Konkurrenz nicht am schlafen und ein zu langer Entwicklungsprozess kann die Firma weit zurückwerfen. Es gibt aber einige Konzepte, die versuchen dieses Problem zu vermeiden,indem schon früh Userbefragungen durchgeführt werden.

Dazu gehört auch das Paper Prototyping, das die Möglichkeit bietet Software auf ihre Usability bei Endusern zu testen, noch bevor bei Webseiten, Webapplikationen oder bei anderer Software auch nur eine Zeile codiert wird. Es ist also ein Testmittel bei dem noch nicht viel in das Projekt investiert werden muss. Ein erster Prototyp wird auf Papier gezeichnet, oder bereits vorhandene Entwürfe werden ausgedruckt, um ihn von Benutzern zu testen. Hierbei spielt ein Entwickler die Rolle des Computers. Die Testpersonen können mit dem Finger die Menus bedienen um eine bestimmte Aufgabe zu erfüllen und der Entwickler verändert daraufhin die Grafik. Dabei simuliert er nur das Verhalten des Computers und darf keine Tipps zur Bedienung geben. Andere Beobachter können Notizen über das Userverhalten machen. So kann schon in einer frühen Phase der Softwareentwicklung erkannt werden welche Teile des Programms selbsterklärend sind und wobei die Testperson Schwierigkeiten bei der Bedienung hat.

Prototypen sind sehr einfach zu entwerfen und können von jedem im Team gebaut werden, auch wenn keine Computerkenntnisse vorhanden sind. Oftmals setzen sich mehrere Leute aus verschiedenen Tätigkeitsbereichen, z. B. Designer und Entwickler, zusammen und entwickeln einen Paper Prototypen, der dann erst einmal Grundlage für Diskussionen im Team sein kann, bevor man fremde User mit einbezieht. Meistens werden diese Prototypen sehr früh im Projekt realisiert, wenn das Pflichtenheft an die Software aufgestellt ist, aber je nachdem was für eine Detailgenauigkeit Prototypen aufweisen, kann es auch noch im weiteren Verlauf des Projekts Sinn machen einen Prototypen zur Veranschaulichung eines Problems zu bauen.

Die Vorteile von Paper Prototyping liegen auf der Hand. Die User, die die Software später bedienen, können schon früh am Entwicklungsprozess teilnehmen, mitentscheiden, welche Features besonders wichtig sind und welche nicht gebraucht werden. So können von Anfang an, eventuell zu teure Features weggelassen, oder gewünschte zusätzliche Features berücksichtigt werden. Außerdem wird ein Usabilitytest durchgeführt und damit vermieden, dass eine komplette Software entwickelt wird, die der User später wegen der Bedienbarkeit nicht verwendet. Somit werden viel Zeit und Ressourcen eingespart. Trotzdem sollte aber nicht zu viel Arbeit in den Paper Prototyp investiert werden. Einfache Zeichnungen in schwarz-weiß reichen meist aus, um zu entdecken welche Schwierigkeiten der User hat.

Paper Prototypen können, im Gegensatz zu bereits programmierten Anwendungen, sehr schnell angepasst und umgeworfen werden. Verläuft ein Usertest nicht so wie geplant, können die Verantwortlichen sehr schnell reagieren und den Prototypen umstellen, um den nachfolgenden Usern veränderte Prototypen zu präsentieren, wenn z. B. ein Menupunkt oder Ausdruck für Verwirrung sorgt. Bei einem technisch realisierten Prototypen wäre das nicht so schnell möglich, da er etwas starrer in der Anpassung ist.

Auch im Team kann ein Prototyp zur Verständigung dienen. Es können erste Ideen besser dargestellt und den Teammitgliedern veranschaulicht werden. Dies kann Grundlage zu einer Diskussion über verschiedene Versionen von Prototypen sein. Somit wird die neue Marschroute vorgegeben und es treten weniger Missverständnisse zwischen Designern und Programmierern im Projektverlauf auf. Designer können verschiedene Designexperimente auf Papier machen. Entwickler können eventuell anhand des Prototyps besser diskutieren, was für eine Programmiersprache Sinn macht. Außerdem kann eventuell mit dem Marketing oder Kunden abgesprochen werden, ob das Projekt wirklich so umgesetzt werden soll und ob die Software den Ansprüchen genügt.

Ein weiterer Vorteil von Paper Prototypen im Gegensatz zu technisch realisierten Prototypen ist die Fehleranfälligkeit. Bei technischen Prototypen kann es schnell zu Problemen kommen. Oftmals haben erste Programme viele kleine Bugs die zusammen mit anderen unerwarteten technischen Schwierigkeiten, z. B. einem Serverabsturz, dazu führen, dass Tests völlig abgebrochen werden müssen. Das kann bei Paper Prototypen nicht vorkommen.

Neben dieser großen Anzahl von Vorteilen, können aber auch Zweifel am Paper Prototyping aufkommen. Viele Entwickler zeigen Außenstehenden nicht gerne, einfache eventuell noch unfertige Zeichnungen von Prototypen. Nach außen hin könnte das schlampig und unprofessionell wirken. Doch erklärt man den Usern, warum man nur einen Paper Prototypen entwickelt hat, könnte das sogar noch anspornen, weil der User noch einen größeren Einfluss auf das Endergebnis hat.

Außerdem stellt Prototyping einen zusätzlichen Mehraufwand dar. Es müssen einige Screenshots oder Papierzeichnungen angefertigt werden, passende User für die Befragung gesucht, benachrichtigt, eingeladen, befragt und analysiert werden. Vor allem in Projekten in denen die Zeit knapp ist, wird deshalb vielleicht auf einen ersten Testprototyp verzichtet. Ob es sich lohnt, genau an diesem Punkt an Zeit zu sparen, wird dann wahrscheinlich in einer späteren Phase des Projekts erkannt.

Es können auch Zweifel aufkommen, ob bei einer Userbefragung mit einem Paper Prototypen überhaupt vernünftige Ergebnisse herauskommen. Die große Menge an Papiervorlagen kann auf den User verwirrend wirken. Außerdem kann man keine Rückmeldungen über die Qualität von Grafiken, Lesbarkeit von Texten und anderen grafischen Aspekten bekommen. Zudem muss derjenige, der den Computer imitiert ständig die Grafiken ändern, er sollte sich also sehr gut im Ablauf auskennen und alle Entwürfe bereit haben, sonst kann es zu zusätzlicher Verwirrung beim User kommen.

Man sieht also, dass Paper Prototypen eine wichtige Grundlage für Userbefragungen zu einem frühen Zeitpunkt im Projekt darstellen. Je früher man den User mit einbezieht umso flexibler ist das ganze System. Der Prototyp lässt sich im Gegensatz zu einer ersten Softwareversion schnell umstellen. Somit kann man mit einer gründlichen Planung und Befragung am Anfang des Projektes sehr viel Geld und Zeit im späteren Projektverlauf einsparen, da eine völlige Fehlentwicklung damit schon einmal ausgeschlossen ist. Paper Prototypen sind einfach, relativ schnell umzusetzen und dienen dazu Ideen darzustellen, bevor man viel Geld investieren muss. Das macht Paper Prototyping meines Erachtens zu einem unverzichtbaren Mittel zu Beginn eines Projektes.


Links

Paper Prototyping - The fast and easy way to design and refine user interfaces http://www.paperprototyping.com/what.html
Carolyn Snyder; Paper prototyping; November 2001 http://www.snyderconsulting.net/us-paper.pdf
Scott Berkun; The Art of UI Prototyping; November 2000 http://www.uiweb.com/issues/issue12.htm
User Interface Prototyping – Concepts, Tools, and Experience http://www.ubilab.org/publications/print_versions/pdf/icse96.pdf
Matthew Klee; Five Paper Prototyping Tips; Januar 2000 http://www.uie.com/articles/prototyping_tips/
Jakob Nielsen; Paper Prototyping: Getting User Data Before You Code; April 2003 http://www.useit.com/alertbox/20030414.html
Using Paper Prototypes to Manage Risk http://www.uie.com/articles/prototyping_risk/"
Carolyn Snyder; Paper prototyping; November 2001 http://www.snyderconsulting.net/us-paper.pdf