Auf der Suche nach dem optimalen Prototyping-Tool

Ein Diskussionsbeitrag bei OpenBC bringt mich dazu, meine Erfahrungen mit verschiedenen Prototyping-Tools und -Ansätzen einmal zusammenzufassen. Schließlich ist Prototyping ein zentrales Tätigkeitsfelder von Interaktionsdesignern, Information Architects und anderen Personen im Software-Entwicklungsprozess.

Wozu Prototyping?

Warum macht man sich die Mühe überhaupt? Der Sinn von Prototyping liegt darin, Verhalten von digitalen Artefakten zu simulieren, ohne dass tatsächlich Entwicklungsaufwände anfallen. Dahinter steht die Erkenntnis, dass Änderungen umso teurer werden, je später im Entwicklungsprozess sie realisiert werden - und jeder, der einmal in der Software-Entwicklung gearbeitet hat, weiß, dass Änderungen unumgänglich sind und sich fast zwangsläufig ergeben. Die Änderungswünsche ergeben sich i.d.R. dann, wenn man ein Design (egal, auf welcher Entwicklungsstufe) mit dem Projektteam durchspricht. Daraus lassen sich die Anforderungen an einen optimalen Prototyp ableiten:

• schnell (mit geringem Aufwand) zu erstellen
• leicht zu ändern
• nah an der späteren Realität
• kommunizierbar (d.h. in einem Dateiformat, das von den Mitgliedern des Projektteams zumindest geöffnet, besser auch annotiert werden kann)

Spätestens mit interaktiveren Produkten à la Web2.0 wird auch eine neue Denke beim Prototypenbau notwendig – das Denken in statischen Seiten ist nicht mehr zielführend, weil Seiten oder auch nur Elemente von Seiten je nach Systemzustand (z.B.: Nutzer ist unbekannt / bekannt, aber nicht angemeldet / authentifiziert) oder nach Nutzeraktion (Nutzer hat eine Aktion erfolgreich abgeschlossen / beim Ausführen einer Aktion ist ein Problem aufgetreten) ganz unterschiedlich aussehen können. Sinnvoll ist hier, das möglichst modulare Design, das später ja auch technologisch so realisiert wird, schon im Prototyping einzuführen. Dann hat man als Interaktionsdesigner alle Freiheiten, Module auf Ereignisse in anderen Moduln reagieren zu lassen oder unbeeinflusst weiter ihre Arbeit zu versehen. Daraus leitet sich ab: ein modulares Herangehen muss vom Tool unterstützt werden.

Arten von Prototyping

Je nach Aufgabenstellung unterscheidet man horizontale und vertikale Prototypen (immer unter der Voraussetzung, dass man über eine begrenzte Menge Zeit verfügt). Horizontale Prototypen bilden z.B. eine Website oder eine Anwendung in ihrer ganzen Breite ab, zeigen aber, wenn man in die Tiefe geht, praktisch keine Funktionalität. Vertikale Prototypen zeigen oft nur ganz grobe Illustrationen weiter Bereiche einer Site oder Anwendung, gehen aber in einem bestimmten Bereich sehr weit und sehr konkret in die Tiefe.

Wenn es z.B. darum geht, einen Prototypen zu erstellen für einen Usability Test einer bestimmten Funktion, so wird man einen vertikalen Prototyp bauen, der diese Funktion vollständig darstellt, und alle Randgebiete werden eher kursorisch dargestellt. Will man dagegen z.B. das Navigationsverhalten über die ganze Site erforschen, baut man eher einen horizontalen Prototypen mit sehr reduzierter Funktionalität in der Tiefe.

Grundsätzlich kann man Prototyping elektronisch oder auch mit Papier durchführen. Papierprototypen haben eine Reihe von Vorteilen - sie sind schnell erstellt, lassen sich häufig im Interview mit Testteilnehmern direkt ändern, und aufgrund ihrer gewollten Unfertigkeit laden sie dazu ein, sich spielerisch mit ihnen auseinander zu setzen. In sehr frühen Projektphasen sind sie außerordentlich hilfreich, gerade wenn man z.B. noch dabei ist, die Requirements festzuzurren. Ein großer Nachteil von Papierprototypen liegt aber darin, dass man wiederkehrende Module auch so häufig basteln muss, wie sie auftreten; und eine Weitergabe oder auch nur Dokumentation ist eher schwierig.

Elektronische Prototypen dagegen wirken häufig schon fertiger. Das kann sich auch als Nachteil erweisen, wenn es Testteilnehmer davon abhält, Änderungswünsche vorzubringen, weil sie glauben, eine Lösung sei schon weit fortgeschritten. Eine direkte Interaktion der Teilnehmer mit den Elementen der Prototypen ist auch nicht möglich. Dafür können Module (mehr oder weniger) realisiert werden, und die Weitergabe der Designs ans Projektteam und die Dokumentation funktionieren problemlos.

Auch HTML eignet sich sehr gut zum Erstellen von interaktiven Prototypen - wenn man entsprechend versiert ist und / oder über die richtigen Tools zur Bearbeitung verfügt. Ein schönes Beispiel dafür ist Adobe GoLive (ehemals GoLive Cyberstudio – those were the days …). GoLive ermöglicht das Arbeiten mit Objekten und wiederkehrenden Elementen, die außerhalb der Seite definiert werden können. Damit ist es auch schon relativ entwicklungs- und zielsystemnah. Ein Nachteil dieser Nähe kann darin liegen, dass der Prototyp dann als Ausgangspunkt für die Entwicklung des eigentlichen Systems herangezogen wird. Davon sollte unter allen Umständen abgesehen werden, sonst entsteht das, was Alan Cooper "Narbengewebe" nennt: Code, der nicht aus einem Guss ist, der wieder und wieder angepasst wurde und nicht mehr elegant und schon gar nicht mehr wartbar ist.

Auch, wenn man Tools wie Adobe GoLive (oder Dreamweaver) nicht zur Verfügung hat, kann man natürlich mit HTML Prototypen bauen – das ist dann aber entsprechend aufwändiger. Dann benötigt man entweder eine Umgebung, die mit Moduln umgehen kann (und ist dann eigentlich schon mitten in der Entwicklung), oder man baut hässliche Frickel-Lösungen mit Frames in Frames zusammen, um einzelne Seiten wie Module erscheinen zu lassen. Beides ist suboptimal für den Zweck, ein schnelles Prototyping zu ermöglichen.

Ich werde im folgenden nur auf die elektronischen Prototyping-Tools eingehen.

Prototyping mit elektronischen Tools

Microsoft PowerPoint

Das wahrscheinlich meist genutzte Prototyping-Tool ist Microsoft PowerPoint. Auf praktisch allen Büro-PCs installiert, bringt es den unschlagbaren Vorteil mit sich, dass alle einmal erstellte Prototypen einsehen können - aber auch Änderungen möglich sind. Das führt zu einem anderen Punkt: der Ownerschaft. Ein Prototyp muss einer Person gehören, und nur diese Person nimmt Änderungen am Prototyp vor. Auch, wenn das nach viel Last auf einer einzelnen Person klingt, kann nur so sichergestellt werden, dass der Prototyp in sich konsistent bleibt und den Diskussionsstand wiederspiegelt. (Ggf. kann hiervon eine Ausnahme gemacht werden, wenn sehr strikte Designrichtlinien gelten, diese allen beteiligten Personen bekannt sind und deren Einhaltung auch top-down eingefordert werden kann.)

PowerPoint ermöglicht ein schnelles Zusammenstecken von Elementen und ein sehr grobes erstes Elemente-Zurechtschieben. Elemente können auch miteinander verlinkt werden, so dass man Interaktivität zu einem gewissen Grad simulieren kann. Spätestens, wenn man aber mit einem ausgearbeiteten PowerPoint-Prototypen bei der Entwicklung war und einen ersten Blick auf ein mögliches Ergebnis bekommt, wird aber klar, warum PowerPoint zum Prototypenbau ungeeignet ist: die Maße stimmen hinten und vorne nicht. Auf einen 1024x768-Screen bekommt man deutlich mehr Inhalt, als auf einer PowerPoint-Folie darstellbar (und dann noch les- und bearbeitbar) ist. Außerdem verleitet PowerPoint durch seine Skalierungsfunktionen dazu, Elemente, die partout nicht passen, eben passend zu machen - nur dass dieser Screen dann eben nicht mehr realisierbar ist.

Ein weiterer eklatanter Nachteil von PowerPoint ist die fehlenden Modularisierbarkeit. PowerPoint kennt nur Copy & Paste - und wenn man einmal ein Element auf 40 Folien verteilt hat und es dann überall ändern und wieder ändern muss, merkt man, dass hier etwas Wichtiges vergessen wurde bzw. PowerPoint eben nicht das Tool der Wahl ist. Fazit: außer für ganz grobe Ideen-Visualierungen ungeeignet.


Denim

Denim ist ein innovatives Tool für frühe Stadien des Definitionsprozesses. Auf unterschiedlichen Detaillierungsebenen kann man Seiten und ihre Verlinkungen definieren, auch eine gewisse Interaktivität simulieren. Die Steuerung erfolgt über Gesten, gern auch unter Verwendung eines Grafiktabletts. Runde Kontextmenüs stellen eine schnelle Bedienung sicher. Das komplett in Java geschriebene Tool liegt für Mac OS X, andere *nixe und Windows vor. Leider hat es einen ganz gravierenden Nachteil: Es läuft nicht wirklich stabil. Darüber hinaus frisst es ab einer gewissen Datei- bzw. Website-Größe in ungeahnter Form Systemressourcen, und die eingebaute HTML-Export-Funktion funktioniert eben nur teilweise und produziert Code, der seltsamer Weise nur im Internet Explorer läuft. Ein Export nach PDF (oder auch nur ein ordentlicher Ausdruck) ist praktisch unmöglich. Daher: verspricht, ein sehr innovatives hervorragendes Tool zu werden, aber ist leider noch nicht fertig.


Apple Interface Builder

Wer die Developer Tools von Mac OS X zur Verfügung hat (d.h. jeder, der Original-Mac OS X-CDs besitzt), kann mit dem Interface Builder ganz hervorragende Simulationen von User Interfaces für Mac OS X erzeugen. Was heißt "Simulationen": das sind tatsächliche UIs, nur noch ohne Logik und Datenstrukturen. Vorbildlich eingearbeitet sind die Führungslinien, die sich automatisch zeigen, wenn man Elemente auf Fläche platzieren möchte, so dass die Platzierung mit der jeweils aktuellen Version der Apple Human Interface Guidelines übereinstimmt. Die Nachteile dieser Lösung liegen darin, dass sie nur fürs Applikations-Design gedacht ist (und nur das wirklich gut unterstützt), nur auf dem Mac läuft und lediglich in ein proprietäres .nib-Format sichern kann.


Microsoft Visio

Microsoft Visio ist eigentlich ein Tool zum Erstellen von Diagrammen aller Art. Für diese Aufgabe ist es hervorragend geeignet, und ich setze es auch für Flussdiagramme aller Art sehr gern ein. Gern wird Visio auch eingesetzt, um Screen-Designs zu konzipieren. Gegenüber PowerPoint hat es den Vorteil, dass die Darstellung viel realitätsnäher ausfällt und man ein Gefühl dafür entwickeln kann, wieviel Inhalt wirklich auf eine Seite passt. Ein modulares Arbeiten ist seit Visio 2003 möglich, indem man Dateien in Dateien platziert (siehe diesen sehr hilfreichen Artikel bei BoxesAndArrows). Auch die Stencils kann man nutzen für wiederkehrende Elemente. Leider verwendet Visio ein proprietäres Dateiformat und kann zwar in alle möglichen Zeichen- und Bildformate exportieren, aber richtig elegant wird es nicht. (Sinngemäß gilt dies auch für OmniGraffle von der Omni Group. Leider kann OmniGraffle aber keine anderen OmniGraffle-Dateien platzieren. OmniGraffle ist nur für den Mac verfügbar; Visio gibt es dafür nur für Windows.)


Adobe Photoshop

Die Königin der Bildbearbeitungsprogramme wird auch gern zu Prototyping-Zwecken eingesetzt. Durch die Möglichkeit, Elemente in Ebenen (und Ebenen in Koffern …) zusammenzufassen, kann hier auch eine gewisse Modularität simuliert werden. Allerdings verleiten die fantastischen Möglichkeiten von Photoshop doch dazu, den Prototyp grafisch weiter auszugestalten, als eigentlich notwendig ist. Am Ende steht dann ein schon recht fertiges Design, das dann aber nicht mehr schnell änderbar ist und u.U. Testteilnehmer beeindruckt bis einschüchtert, so dass sie ihre Kommentare nicht mehr abgeben, weil alles "so fertig" aussieht. Photoshop kann in eine große Anzahl von Formaten exportieren. Als nachteilig zeigt sich hier, dass die grafisch aufwändig gestalteten Interfaces häufig große Dateien verursachen, was den Austausch der Daten erschwert. Will man dann, um die Dateigröße zu verringern, auf gifs oder jpegs ausweichen, benötigt man wieder ein Tool wie PowerPoint, um eine Reihenfolge sicherzustellen und einen Zusammenhang zu stiften, oder man muss eine Namenskonvention für die Dateinamen einführen und einhalten. M.E. ist Photoshop daher zum Prototypen-Bau nur bedingt geeignet.


Adobe Illustrator

Wie in dem BoxesAndArrows-Artikel beschrieben, ist Adobe Illustrator neben Visio das einzige Grafik-Programm, das in der Lage ist, ein modulares Prototyping zu unterstützen. Elemente baut man in Dateien, die man dann (als PDFs) in anderen Dateien platziert. Ändert man dann etwas an den Elementen, spiegeln sich diese Änderungen im Handumdrehen in den Hauptdateien wieder. Fertige Stände können nach PDF exportiert werden; der Adobe Reader dürfte inzwischen auch auf praktisch allen Systemen als installiert vorausgesetzt werden. Hat man dann noch den Acrobat zur Verfügung, kann man zum einen die Seiten zusammenbauen zu zusammenhängenden Präsentationen, zum anderen – wenn man genug Zeit hat – auch Verlinkungen einbauen, so dass eine gewisse Interaktivität simuliert werden kann. Ein Nachteil bei Illustrator liegt nach wie vor (auch in der CS2-Version) darin, dass es von Haus aus nicht mit mehrseitigen Dokumenten umgehen kann (Freehand hatte dieses Feature schon ... ich weiß es nicht mehr). Hier schafft das PlugIn MultiPage von HotDoor Abhilfe. So wird es dann möglich, komplette Sets von Views in einer Datei zusammenzuhalten, die Module auszulagern und einzeln zu pflegen und dann mit Acrobat die Exporte zu optimieren. Wenn man dann noch InDesign zur Verfügung hat, kann man die fertigen Views (oder auch die Module) auch in InDesign platzieren und die Design-Kommentare direkt dort vornehmen – so wird die Wertschöpfungskette von Prototyping bis Design-Dokumentation versorgt. Nachteilig an Illustrator ist sicherlich die Einarbeitungszeit, die man benötigt, wenn man sich ein vektorbasiertes Zeichenprogramm dieser Komplexität aneignen möchte.


Axure RP

Axure RP Pro 4 verspricht, ein sehr interessantes Tool zu sein – inkl. Integration in Word und HTML-Export. Da ich noch nicht damit gearbeitet habe, kann ich noch keine Aussage zu seiner Eignung treffen. Ich werde es mir dieser Tage einmal ansehen und dann entsprechend berichten.


Fazit

Meine persönlich produktivste Prototyping-Umgebung stellt zurzeit Adobe Illustrator dar, ggf. in Kombination mit Acrobat: Schnell, nah genug, aber nicht zu nah am Endergebnis, modular (d.h. unterstützt schnelle Änderungen), exportiert in ein allgemein verständliches Format (PDF), das – entsprechende Tools wie z.B. Acrobat Elements vorausgesetzt - auch annotiert werden kann. Dadurch, dass Illustrator-Lizenzen nicht mit jedem Büro-PC ausgegeben werden, ist auch sichergestellt, dass die Ownerschaft des Prototypen bei einer überschaubaren Anzahl von Menschen bleibt, bei denen die Fäden zusammenlaufen.