The Use of Rapid Prototyping for Interface Design
Daniel Bertram
Einleitung
Das Erstellen eines Prototypen vor der Erstellung des eigentlichen Produktes ist eine in verschiedensten Bereichen weit verbreitete Vorgehensweise. So fertigen Architekten in der Regel Modelle der Gebaeude an, die sie ihren Kunden vor der Umsetzung zeigen koennen. Auch im Maschinenbau ist Rapid Prototyping, also der schneller Prototypenbau zur Herstellung von Musterbauteilen, weit verbreitet. Immer komplexer werdende Software hat dazu gefuehrt das auch in der Informatik vermehr Rapid Prototyping eingesetzt wird. Dies gilt besonderst fuer die Entwicklung graphischer Benutzerschnittstellen, welche hohe Anforderungen an die am Entwicklungsprozess beteiligten Designer stellt, da ihre Funktionstuechtigkeit schwer ueberpruefbar ist. Daher wird im Folgenden auf die Anwendung von Rapid Prototyping im Design graphischer Benutzerschnittstellen eingegangen. Dazu werden zuerst einige Gruende welche fuer den Einsatz von Rapid Prototyping sprechen erlaeutert, anschließend werden die verschiedenen Arten von Prototypen kurz vorgestellt, dann werden einige Probleme genannt welche im Umgang mit Rapid Prototyping auftreten koennen und abschließend werden im Fazit die wesentlichen Vorteile dargestellt, welche sich durch den Einsatz von Rapid Prototyping ergeben.
Gruende fuer Rapid Prototyping
Die Entwicklung komplexer Anwendungen ist teuer und Zeitaufwendig, graphische Benutzerschnittstellen koennen erst implementiert und getestet werden wenn die Funktionalitaet der Anwendung bereits vorhanden ist. Das Design der graphischen Benutzerschnittstelle ist allerdings von zentraler Bedeutung fuer den Erfolg des fertigen Produktes. Benutzer welchen die graphische Benutzerschnittstelle nicht gefaellt oder welche sich nicht zurechtfinden werden die Anwendung nicht benutzen, unabhaengig davon wie gut die eigentlichen Funktionalitaeten implementiert sind. Die Entwicklung graphische Benutzerschnittstellen ist eher analytischer als synthetischer Natur, sie werden zuerst erstellt, dann analysiert und schließlich iterativ verbessert. Bei graphischen Benutzerschnittstellen gibt es weder Methoden noch konkrete Kriterien und Richtlinien die automatisch zum perfekten Produkt fuehren, sondern nur einige psychologisch fundierte Kriterien welche allerdings nur als grobe Richtlinie dienen koennen. Der 'menschliche Faktor' spielt bei graphischen Benutzerschnittstellen eine wesentliche Rolle, daher ist es sehr unwahrscheinlich auf Anhieb eine perfekte graphische Benutzerschnittstelle zur erstellen. Formale Korrektheits- oder Vollstaendigkeitsbeweise wie sie im Software Engineering teilweise moeglich sind gibt es bei dem Design graphischer Benutzerschnittstellen nicht. Zudem haben Benutzer meist Probleme damit sich nur an Hand von Spezifikationen vorzustellen wie graphische Benutzerschnittstellen in der Realitaet funktionieren sollen. Sie haben Probleme ihre Anforderungen klar zu artikulieren und koennen dies meist erst an einem lauffaehigen System deutlich machen. Grundlegende aenderungen am fertigen System sind allerdings kaum moeglich da sie sehr teuer und zeitaufwendig sind. Dies gilt besonderst wenn das System von einem breiten Spektrum verschiedener Benutzer verwendet werden soll, welche alle unterschiedlich viel Erfahrung mit Computern haben und unterschiedliche, sich teilweise ausschließende Anforderungen an das System haben.
Aus diesem Grund wird Rapid Prototyping eingesetzt, die graphische Benutzerschnittstelle wird simuliert, so dass das Design getestet werden kann. Das verbessert die Kommunikation im Projektteam, welches bei großen Projekten typischerweise aus Experten verschiedener Fachbereiche wie z.B. Informatik, Psychologie, Grafikdesign usw. besteht, vor allem zwischen den Anwendungsprogrammierern und den Designern der graphischen Benutzerschnittstelle. Die Organisation und das Layout der graphischen Benutzerschnittstelle koennen frueh getestet werden, so erhaelt man relativ schnell Feedback, welches zur Verbesserung der graphischen Benutzerschnittstelle genutzt werden kann. Prototypen koennen des weiteren mit potentiellen Kunden getestet werden, was sehr wichtig ist da diese die graphische Benutzerschnittstelle besser beurteilen koennen als das Entwicklerteam. Sie verfuegen im Gegensatz zu den Entwicklern ueber anderes Hintergrundwissen, sie wissen meist wesentlich mehr ueber die Arbeitsablaeufe fuer welche die Software benutzt werden soll, ueber den Aufbau der zu testenden Software wissen sie allerdings wesentlich weniger als deren Entwickler. Durch diese Tests mit den Endnutzern koennen bereits in einem fruehen Entwicklungsstadium eventuell vorhandene Designfehler gefunden und relativ kostenguenstig behoben werden. Es muss lediglich der Prototyp veraendert werden, findet die Evaluation erst am fertig entwickelten Produkt statt, sind aenderungen wesentlich teurer und zeitaufwendiger. Des weiteren gilt das Prototypen schnell und billig erzeugt werden muessen, außerdem sollten sie leicht modifizier- und erweiterbar seien. Zudem koennen Prototypen selbst zur Spezifikation der graphischen Benutzerschnittstelle verwendet werden. Ein lauffaehiger Prototyp ist besser verstaendlich als es eine sprachliche Spezifikation seien kann. Er ermoeglicht intuitives, schnelles Erfassen der Konzepte einer graphischen Benutzerschnittstelle. Zur Erklaerung der Darstellungen und deren Funktionalitaet muss nicht der Umweg ueber eine komplizierte Spezifikationssprache gegangen werden, welche vom Benutzer erst erlernt werden muss. Prototypen koennen herkoemmliche Spezifikationen, die dazu gedacht sind, Programmierern Information ueber die Benutzerschnittstelle zu vermitteln, zumindest teilweise ersetzen. Fuer die Entwickler hat Rapid Prototyping den Vorteil, dass sie mit Hilfe der Prototypen besser abschaetzen koennen, wie Aufwaendig die Implementation der geforderten Funktionalitaeten seien wird.
Verschiedene Arten von Prototypen
Man kann Prototypen normalerweise in Low-Fidelity Prototypen und High-Fidelity Prototypen, Horizontalen Prototypen und Vertikalen Prototypen, revolutionaeren Prototypen und evolutionaeren Prototypen sowie explorative Prototypen und experimentelle Prototypen einteilen. Diese Einteilung ist allerdings nicht exklusiv, sondern stellt nur eine Sichtweise auf die Prototypen dar. Ein Prototyp kann normalerweise immer in mehrere Kategorien eingeordnet werden.
Bei Low-Fidelity Prototypen wie z.B. Paper Prototypes, Storyboards & Sketches und Konzeptvideos ist der Detailgrad der graphischen Benutzerschnittstelle niedrig, das Anwendungssystem ist nur als Gedankliches Modell vorhanden und wird falls noetig vom Menschen simuliert. Sie koennen sehr schnell und billig hergestellt werden, und eignen sich gut dazu die grundlegenden Konzepte der graphischen Benutzerschnittstelle zu testen. Daher werden sie bereits in fruehen Phasen der Entwicklung eingesetzt. Da sie ohne Technologie auskommen koennen auch keine Technologischen Barrieren vorhanden sein. Allerdings koennen sie auch, aufgrund ihres ungewohnten und meist bewusst haesslichen Erscheinungsbilds, die Testpersonen verunsichern. Zudem koennen meisten nur ein Bruchteil der Anwendungsfunktionalitaeten abgedeckt werden.
High-Fidelity Prototypen werden am Computer erstellt, z.B. mit HTML, Javascript, Flash, Director oder GUI Buildern. Der Detailgrad der graphischen Benutzerschnittstelle ist hoch, ebenso die technischen Funktionalitaeten des Anwendungssystems. Sie liefern einen realistischen Eindruck des Programms und ermoeglichen so ein sehr ausfuehrliches Feedback der Tester. Zudem sind sie interaktiv, daher kann auch der Zeitliche Ablauf getestet werden. Allerdings sind sie in der Herstellung relativ teuer, trotzdem muss die Funktionalitaet meist eingeschraenkt werden. Zudem kann durch den fertigen Eindruck des Prototypen die Kreativitaet der Tester eingeschraenkt werden, welche sich nicht mehr trauen grundlegende Eigenschaften in Frage zu stellen und sich auf Detailkritik beschraenken.
Ein Sonderfall der High-Fidelity Prototypen sind die 'Cheap High-Fidelity' Prototypen. Es wird auf die Realisierung der technischen Funktionalitaeten des Anwendungssystems verzichtet, statt dessen kommt die Wizard-of-Oz Technik zum Einsatz. Hierbei werden die Reaktion des Systems von einem Menschen simuliert, der Mensch spielt sozusagen Computer. Typische Anwendungsgebiete sind z.B. Spracherkennung oder Sprachsynthese, Anmerkungen, Argumentation und visuelle Wahrnehmung. Dadurch ist die Herstellung wesentlich billiger, ohne dass der Eindruck auf den Tester darunter leidet.
Horizontales Prototyping dient dazu den Funktionsumfang einer graphischen Benutzerschnittstelle zu zeigen. Es ermoeglicht dem Tester sich in dem System zu bewegen, die technischen Funktionalitaeten sind allerdings nicht implementiert. Mit Hilfe von Horizontalen Prototyping koennen das Grundlegende Konzept der graphischen Benutzerschnittstelle getestet werden, sowie die Navigation im System, die Anordnung der einzelnen Funktionen und die Zugaenglichkeit. Außerdem koennen die Vorlieben der Tester ermittelt werden. Horizontales Prototyping wird in fruehen Phasen des Designs durchgefuehrt und ist sowohl in Low-Fidelity Prototypen als auch in High-Fidelity Prototypen anwendbar.
Vertikales Prototyping dient dazu eine ausgewaehlte Funktion des Produktes zu zeigen. Es ermoeglicht dem Tester ausschließlich diese Funktion zu testen, die technische Funktionalitaet dieser Funktion ist implementiert. Mit Hilfe von Vertikalen Prototyping koennen das optimale Design einer bestimmten Funktion getestet werden, die Benutzbarkeit dieser Funktion kann verbessert werden, außerdem kann die Leistung der Tester fuer diese spezielle Funktion ermittelt werden. Vertikales Prototyping wird sowohl in fruehen Phasen des Designs durchgefuehrt um verschiedene Designs fuer eine spezielle Funktion zu vergleichen, als auch in spaeten Phasen des Designs um die Benutzbarkeit einer speziellen Funktion zu optimieren. Vertikales Prototyping wird hauptsaechlich in High-Fidelity Prototypen angewendet, kann aber auch in Low-Fidelity Prototypen angewendet werden.
Ein Sonderfall sind Scenarios als Durchschnitt von Horizontalen und Vertikalen Prototyping. Hierbei werden sowohl der Funktionsumfang als auch die technische Funktionalitaet minimalisiert. Szenarios sind extrem billig und schnell herzustellen und ermoeglichen es schnell und haeufig Feedback zu bekommen. Sie koennen die graphische Benutzerschnittstelle allerdings nur simulieren solange der Tester einen genau vorgegebenen Pfad folgt.
Revolutionaere Prototypen werden unabhaengig vom Zielsystem entwickelt, evaluiert und danach verworfen. Das Zielsystem wird dann basierend auf den Erkenntnissen der Evaluation der Prototypen entwickelt. Revolutionaere Prototypen werden bevorzugt in fruehen Phasen des Designs eingesetzt. Sie haben den Vorteil dass sie schnell und billig produziert werden koennen, da sie nach der Evaluation verworfen werden ist es meist irrelevant wie Fehlerrobust und effizient der Programmcode ist. Der entscheidende Nachteil bei Revolutionaeren Prototypen ist das sie sozusagen fuer den Papierkorb produziert werden, da der Prototyp selbst nicht zu einem Bestandteil des fertigen Produktes wird. Daher werden zum einem immer Ressourcen 'verschwendet', außerdem kann es sich auch negativ auf die Motivation der mit der Prototyp Entwicklung beschaeftigten Mitarbeiter auswirken, das ihre Arbeit nur zu Testzwecken verwendet wird.
Evolutionaere Prototypen werden iterativ immer weiter verbessert und schließlich zum fertigen Zielsystem weiterentwickelt. Ressourcen koennen daher immer weiterverwendet werden, der Prototyp entwickelt sich Schritt fuer Schritt zum fertigen Produkt. Ein Problem hierbei ist es sicherlich passende Werkzeuge zu finden mit denen schnell und billig Prototypen erstellt werden koennen, wobei der erzeugte Programmcode trotzdem robust und effizient sein muss. Dafuer kommen nur komplexe Programme wie z.B. GUI Builder in Frage, wodurch die Entwicklung deutlich langsamer und teuerer ist als bei Revolutionaeren Prototypen. Ein weiteres Problem von Evolutionaere Prototypen ist das die Entwickler, anstatt den Prototyp zu Testzwecken zu entwickeln, in Versuchung geraten das System zu implementieren. Da der Code weiterverwendet wird geht er meistens ueber das eigentlich noetige Minimum hinaus, wodurch er eigentlich kein Prototyp zu bestimmten Testzwecken mehr ist sondern nur noch eine unvollstaendige Version des Endsystems. Evolutionaere Prototypen werden daher, wenn ueberhaupt, bevorzugt in spaeten Phasen des Designs eingesetzt.
Exploratives Prototyping wird in der Anforderungsanalyse angewandt, mit dem Ziel die Anforderungen von potentiellen Kunden an die graphische Benutzerschnittstelle zu klaeren. Daher werden sie bereits in fruehen Phasen der Entwicklung eingesetzt, die Anforderungen an den Prototyp selbst sind dabei meisten unklar und lassen viele Designmoeglichkeiten offen.
Beim experimentellen Prototyping sollen technische Fragen geklaert werden. Es dient dazu den Entwicklern zu helfen, die Machbarkeit eines Systems einzuschaetzen und Vorschlaege fuer die einzelnen Fragestellungen zu entwerfen. Dabei werden sehr spezifische Fragestellungen betrachtet und moegliche Loesungen simuliert.
Probleme
Rapid Prototyping ist ein komplexer Vorgang der auch mit einigem Aufwand, sowohl personell als auch finanziell, verbunden ist. Es muss sichergestellt werden dass im Projektteam keine Antipathien gegenueber Rapid Prototyping bestehen. Vor allem Systementwickler neigen dazu Prototypen nicht ernst zu nehmen bzw. sogar als ueberfluessig zu erachten, da sie ganz genau wissen wie ihr System funktioniert und daher annehmen das es fuer die Kunden ebenso einfach zu bedienen ist wie fuer sie selbst. Manager sehen Prototyping oft als Verschwendung von Ressourcen die besser zur Entwicklung des eigentlichen Produktes genutzt werden sollten. Dies ist vor allem bei revolutionaeren Prototypen, die nicht Bestandteil des Endproduktes werden, der Fall. Der Erfolg von Rapid Prototyping haengt zudem stark von der Auswahl geeigneter Testpersonen ab. Diese muessen aus der Zielgruppe des fertigen Produktes stammen, also potentielle Kunden sein. Vor allem bei 'exklusiveren' Zielgruppen, wie z.B. einer Zeit Management Software fuer Manager, stellt das finden passender Testpersonen ein nicht unwesentliches Problem da. Auch der Wille und die Faehigkeit zur Konstruktiven Kritik sind wichtige Eigenschaften welche die Testpersonen benoetigen. Die Durchfuehrung und Auswertung der Benutzerstudien ist ebenfalls nicht trivial, ohne eine professionell gestaltete und aufbereitete Evaluation sinkt der Nutzen von Rapid Prototyping erheblich. Zudem besteht auch immer die schwierige Frage wann der Prototyp gut genug ist, daher ab welchen Zeitpunkt die Vorteile durch die weitere Verbesserung des Prototypen geringer sind als der zeitliche und finanzielle Aufwand, welcher zu ihrer Umsetzung betrieben werden muss. Zu diesem Zeitpunkt muss die Entwicklung des Prototypen gestoppt werden, es kann mit der Arbeit an dem richtigen Produkt begonnen werden.
Fazit
Mit Rapid Prototyping laesst sich der Entwicklungsprozess von graphischen Benutzerschnittstellen verkuerzen, da man deutlich schneller Feedback bekommt, da potentielle Kunden sehr stark in den Entwicklungsprozess eingebunden werden koennen. Die Kommunikation innerhalb des Teams und zwischen Entwicklern und Testpersonen, welche sich bei der Entwicklung graphischer Benutzerschnittstellen immer sehr schwierig gestaltet, kann durch die Visualisierung mit Hilfe von Rapid Prototyping wesentlich verbessert werden. Durch die starke Einbeziehung der potentiellen Kunden kann eine hoehere Produktqualitaet erreicht werden als das ohne Rapid Prototyping moeglich waere. Da Designfehler fruehzeitig gefunden und behoben werden koennen, koennen die Entwicklungskosten gesenkt werden.
Quellen
Hartson H. R., Hix D.: Human-computer interface development: concepts and systems for its management, ACM Computing Surveys, Bd. 21, Nr. 1, Maerz 1989, S. 45 - 50
Hassan Gomaa, Douglas B.H. Scott : Prototyping as a tool in the specification of user requirements, Proceedings of the 5th international conference on Software engineering ICSE '81, San Diego, California, United States, S. 333 - 342, IEEE Press, Maerz 1981
Jakob Nielsen: Guerrilla HCI: Using Discount Usability Engineering to Penetrate the Intimidation Barrier, 1994 (http://www.useit.com/papers/guerrilla_hci.html)
Charles E. Frank,David Naugler,Michael Traina: Teaching user interface prototyping, Journal of Computing Sciences in Colleges, Volume 20, Issue 6 (June 2005), S. 66 - 73
Martina Manhartsberger: Prototyping - Theorie und Praxis, Ergonomie & Informatik, Ausg. 33, August 1998 (http://www.usability-forum.com/prototyping-1-2-0-0-.html)
Heinrich Hussmann: Vorlesung zur Mensch Maschine Interaktion I. Kapitel 6: Designing Interactive Systems, Vorlesung, Ludwig-Maximilians-Universitaet Muenchen, 2006. (http://www.medien.ifi.lmu.de/lehre/ws0607/mmi1/mmi6b.pdf)
