Prototyping-Frust – oder warum mich meine Werkzeuge manchmal in den Wahnsinn treiben

Freelancer sind oft mit eigenem Rechner unterwegs und haben gegenüber festangestellten UX-Designern einen vermeintlichen Vorteil: sie können so viele verschiedene Prototyping-Tools nutzen, wie sie möchten und sind nicht auf die Toolsuite eines Arbeitgebers angewiesen.

Aus eigener Erfahrung und zahlreichen Gesprächen mit Kollegen in der letzten Zeit kann ich Euch aber jetzt schon sagen: dies schützt nicht vor dem allgemeinen Toolfrust, manchmal macht es ihn sogar schlimmer.

toolflut

Prototyping-Tools? Von Klassikern wie Axure und vielversprechenden Newcomern wie justinmind: mein Rechner kennt sie alle!

Der Frust: viel Tool, wenig Output

Mein Prototyping-Frust entsteht, wenn ich nicht nur an die Grenzen der Prototyping-Tools gerate sondern auch dazu genötigt werde, Bugs der Tools durch Workarounds zu umgehen, anstatt meine Arbeit auf die Umsetzung der gewünschten Interaktionen konzentrieren zu können.

In der Praxis kann das bedeuten, dass ich die Arbeit an einem Prototyp auf dem einem Tool anfange, dann aufgrund eines fehlenden Features auf ein anderes Tool umsteige und dort dann sehr schnell wieder feststecke. Schließlich frage ich mich, ob ich nun noch ein drittes Tool ausprobieren, meine Ansprüche an den Prototypen herunterschrauben, oder einfach einen detaillierten Wireflow aufmalen sollte.

Manchmal verbringe ich dann viel Zeit damit, zu recherchieren, ob nicht mittlerweile jemand das perfekte Tool entwickelt haben könnte. Hin und wieder finde und probiere ich dabei das eine oder andere neue Programm und gestehe mir letztendlich ein, dass ich mich in Wirklichkeit nur vor der Entscheidung drücke, wie ich weiterverfahren soll.

Diese Entscheidung hängt natürlich auch davon ab, zu welchem Zweck ich den Prototyp gerade entwickele und wie viel Zeit mir noch bleibt. Für einen Usability-Test zum Beispiel benötige ich in der Regel etwas Klickbares, Interaktives. Wenn ich dabei in der Modellierung einer hochkomplexen Interaktion feststecke, hilft es zu hinterfragen, ob diese wirklich so kompliziert sein muss, oder ob die Komplexität nicht sogar kontraproduktiv für den Einsatz des Prototyps ist.

„Your Prototypes are so Pretty they Miss the Point Entirely“

So nennt Steven Fyke seinen Artikel, der sich kurz mit „keep it simple, stupid“ zusammenfassen lässt. Er führt darin einen weiteren Grund dafür an, Prototypen für Nutzertests einfacher zu halten, nämlich, dass man ansonsten der Testperson die Möglichkeit nimmt, selbst kreative Problemlösungen vorschlagen zu können.

Wird der Prototyp hingegen für die detaillierte Spezifikation eines Backlogitems benötigt, macht es durchaus Sinn, sich nicht weiter in Selbstmitleid zu suhlen, sondern stattdessen auf Wireflows umzusteigen. Das ist aber leider nicht immer möglich. Will man zum Beispiel mit dem Prototyp auch Animationen darstellen, kann man sich mit Screencastings helfen.

Justinmind vs. Axure – ein Beispiel

Vor kurzem wollte ich mit einem Prototyp eine ziemlich komplexe Filterfunktion, mit sich gegenseitig bedingenden Filter-Pulldowns inklusive Facetten und Tags spezifizieren. Mein Ziel war, den Entwicklern die Funktion und Interaktion der Filter ganz genau zu veranschaulichen. Für eine nicht-visuelle, rein textbasierte Beschreibung hätte ich hierzu einen Roman verfassen müssen, ein Wireflow hingegen wäre mit vielen verschiedenen Zuständen und Pfeilen sehr unübersichtlich geworden.

screenshot_justinmind

Justinmind: viel Drag&Drop für flux gemachte, hübsche und schlanke Prototypen

Ich fing also an, den Prototyp in meinem Lieblingstool Justinmind zu bauen. Mit Justinmind lassen sich sehr schnell hübsche und schlanke Prototypen erstellen. Man kann sehr viel mit Drag-and-Drop erledigen und auch in komplexen Projekten behält man immer den Überblick.

Es dauerte allerdings nicht lange, bis ich in die erste Sackgasse lief: fehlende Event-Trigger bei Justinmind. Die einzigen in Justinmind abgefangenen Events, die nicht vom Nutzer ausgelöst werden, sind onPageLoad und onPageUnload. Da ich gerade mit Pulldowns arbeitete, hätte ich aber dringend Trigger wie onChange und ähnliche benötigt.

Ich beschloss, es mit Axure zu versuchen. Events sind die große Stärke von Axure. Doch bevor ich überhaupt dazu kam, die Events abzufragen fiel mir wieder ein, warum ich kaum noch mit diesem Tool arbeite. Der Aufbau von Seiten und die Spezifikation des Verhaltens von Elementen zueinander erfordern gemessen an der Konkurrenz großen Aufwand.

screenshot_axure

Aktionstrigger & Events sind eine große Stärke von Axure. Mit Hilfe von Mastern kann man sogar eigene Events auslösen

Die Idee: Screencasting

Nach kurzem Haareraufen, Fluchen und dem Versprechen, einen Artikel über diesen untragbaren Zustand zu schreiben, hatte ich eine Idee. Mein Prototyp, den ich in Justinmind gebaut hatte, war weitestgehend funktionsfähig. Sein Nachteil bestand lediglich darin, dass er nicht auf echte Eingaben reagieren konnte. Ihn interaktiv zu machen, war an dem besagten Prototyping-Frust gescheitert. Immerhin, einen festen Ablauf konnte ich damit genau so darstellen, wie ich es brauchte.

Ich wusste ja, wann ich wo klicken musste, damit das passiert, was ich zeigen wollte.

So begann ich, die einzelnen Interaktionen mit einem einfachen Screencasting-Tool abzufilmen. Die daraus entstandenen Videos konnten nun einfach an die Backlogitems angehängt werden. Auf diese Art war jetzt wirklich sichergestellt, dass die Entwickler genau zu sehen bekamen, wie wir uns die Funktionen vorstellten – anders als es übrigens bei einem Prototyp der Fall gewesen wäre.

Die Erkenntnis: jedes Tool hat seinen Anwendungsfall

Es gibt für uns UX-Designer eben leider nicht das eine perfekte Tool, die eierlegende Wollmichsau. Das liegt vor allem an den diversen und von Projekt zu Projekt unterschiedlichen Anforderungen, die wir an die Tools haben.

Um diesem Umstand zu begegnen, arbeite ich mit einem kleinen Set an Tools und habe mir zur Auflage gemacht, in Zukunft nicht einfach drauflos zu bauen, sondern mir vorher ganz genau zu überlegen, welche Funktionen und Features ich für die Aufgabe benötige und dementsprechend ein oder mehrere Tools auszuwählen von denen ich ausgehe, dass sie mir am dienlichsten sein werden

Eine hübsche und hilfreiche Übersicht über Prototyping-Tools und ihre Eignung für verschiedene Zwecke, hat Emily Schwartzman für euch zusammen gestellt. Diese Liste wird regelmäßig gepflegt und aktualisiert.

uebersicht_prototyping_tools

Quelle: cooper.com (zum Vergrößern anklicken)

Ihr werdet jetzt möglicherweise sagen: „In meiner Firma gibt es aber nur Tool XY und mein Chef will kein weiteres Tool anschaffen.“ Oder auch: „Ich habe mich jetzt so gut in Tool YZ eingearbeitet, ich möchte nicht noch ein weiteres Tool lernen müssen.“ Ich schlage Euch trotzdem vor, einfach einmal über den Tellerrand zu schauen und andere Tools auszuprobieren. Viele haben eine sehr flache Lernkurve und einfache Prototypen sind oft schnell zusammengeklickt. Mit dem Argument „Arbeitszeit einsparen“ lassen sich dann sicher auch die meistens Chefs überzeugen.

Mein Fazit

Anstatt uns zum Sklaven einzelner Tools zu machen, sollten wir doch vielmehr das Ergebnis im Blick behalten. Daher meine Tipps:

  1. Schraubt Eure eigenen Ansprüche an den Prototypen herunter und fangt mit einer einfachen Version an. Komplexer machen könnt Ihr es später immer noch.
  2. Vergesst nicht, Eure kreative Seite anzukurbeln. Auch wenn es sich beim Prototyping meistens um eine recht technische Aufgabe handelt, wenn man einen Schritt zurücktritt, kommen einem oft tolle neue Ideen.

K.I.S.S. Mimi

 

Links zum Thema

 

Über Miriam Scheibe

Miriam „Mimi“ Scheibe ist selbstständige User Experience Designerin und berät und unterstützt ihre Kunden in kompletten Produktentwicklungsprozessen von der Discovery-Phase bis hin zur Umsetzung in den Bereichen Strategic Design, User Experience und User Research. In ihrem früheren Leben war sie Entwicklerin und hat mittlerweile schon sechzehn Jahre digitale Erfahrung auf dem Buckel.

7 Kommentare

  1. Felix

    Vielen Dank für den Artikel und den Link zu der Seite von Emily. Es ist wirklich schwierig, bei der Vielzahl an Tools einen Überblick zu behalten. Welches Tool-Set setzt du denn für Projekte ein?

    Viele Grüße

  2. Gregor

    Vielen Dank für den Artikel. Am weitesten hat mich allerdings bisher Papier, Filzstifte, Kleber und Schere gebracht 😉

  3. Volker

    Meiner Erfahrung nach liegt es in der Regel nicht am Tool, sondern daran das man zu früh damit beginnt zu Prototypen. Bevor man sich an den Computer setzt sollte man einen genauen Plan haben was es umzusetzen gilt.
    Und da stimme ich Gregor zu: das beste und schnellste Tool sind immer noch Stift & Papier.

  4. Miriam Scheibe (Gastautorin) Artikelautor

    Hey Klasse. Vielen Dank für Euer Feedback.
    @Felix: mein Lieblingstool, wenn es denn ans Prototyping geht, ist tatsächlich Justinmind.
    Davor kommen natürlich auch bei mir jede Menge Stifte und stapelweise Papier zum Einsatz. Leider ist in vielen Projekten der Zeitdruck sehr hoch und noch wärend man in der Konzeptionsphase ist müssen schon erste Prototypen für Usability-Tests ‚gebaut‘ werden. Da kann es dann schon mal vorkommen, dass man an die von mir beschriebenen Grenzen stößt 😉
    Ich setze Prototyping übrigens auch gerne ein, um ein Konzept selbst zu ‚testen‘ und auszuprobieren, bevor ich es an die Entwickler übergebe …

  5. Wolf Brüning

    Danke für deinen guten Artikel, Mimi. Ich denke, viele hier können deinen Frust ganz gut nachvollziehen. Ich habe auch schon einiges an Prototyping-Tools durch und so eine richtige „Heimat“ hab ich bisher nicht gefunden. Unser Umsatteln auf Responsive Design hat die Geschichte dann auch nochmal komplizierter gemacht.

    Aktuell versuche ich darum möglichst viel mit Stift und Papier zu machen und dann bei Lab-Tests auf Sketch + Axure umzusatteln, zumindest wenn der Nutzer denken, soll, er wäre auf der richtigen Seite. So richtig rund läuft das aber auch noch nicht.

    Ich werde mir auf jeden Fall mal Justinmind anschauen, ansonsten bin ich gespannt, was Adobe mit seinem Project Comet entwickelt. Schaut aus wie ein Sketch mit Möglichkeit zum Bau von Klickprototypen und könnte somit ganz vielversprechend sein.

    PS: Ich sitze übrigens grad im Lab und muss feststellen, dass Invision nicht so cool für User-Tests ist…

  6. Fahim

    Danke, du sprichst auch meine Probleme an… Gelöst habe ich die durch Sketch, fehlt mir auch in eurer Liste. Ist wirklich simple gehalten und in Kombination mit UXPin (oder ähnlichem) meiner Ansicht nach unschlagbar.

  7. FelixT1000

    Tool-hopping war für mich auch immer ein leidiges Thema. Egal ob GTD Tools, Texteditoren/Notizprogramme oder Prototyping-Software. Ich habe die Erfahrung gemacht, mich konsequent mit einem oder zwei Tools in einer Domäne auseinander zusetzen und dabei zu bleiben. Mittlerweile habe ich mit ihnen eine Expertise, die die vermeintlich schlechteren Funktionen dieser (die andere Programme besser umsetzen) kompensiert. Z.B. brauche ich für ausgefeilte Domain Modells kein anderes Tool als Axure. Die Flowchart Funktionen bieten mir ausreichend Möglichkeiten.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.