Fünf gängige Fallgruben beim Prototyping

Usability_Tag_CloudNathan Curtis, eines der Genies aus dem UX-Unternehmen EightShapes, sagt gerne: "Erzählt’s mir nicht. Zeig’s mir." Wenn wir über ein Nutzererlebnis sprechen, will Nathan einen Prototypen sehen (und möglichst mit ihm spielen), um besser zu verstehen, was damit erreicht werden soll.

Nathan ist da nicht der einzige. Prototypen sind ein fabelhafter Weg, um Ideen mit einem Team zu erkunden. Sie verkürzen die Zeit zwischen "So denken wir uns das" und "Oh, kapiert".

Bei unserer Arbeit mit UX-Teams sehen wir viele, die heute Prototypen nutzen. Wir sehen darunter aber auch zahlreiche, die in Fallen tapsen, die die Effektivität ihrer Prototyping-Bemühungen reduzieren. Hier sind fünf der am häufigsten auftretenden Stolpersteine.

Fallgrube #1: Aufs Ergebnis und nicht aufs Lernen fokussieren

Ein großartiger Prototyp kann eine Idee besser verkaufen als eine Spezifikation oder eine andere Form der Beschreibung. Sieht man ein Design in Aktion und spielt mit ihm, erwachen die zugrunde liegenden Ideen zum Leben.

Es ist kein Wunder, dass wir uns so sehr darauf fokussieren, wie der Prototyp aussehen und wie er funktionieren wird. Wir wollen bei den Hauptentscheidungsträgern und Stakeholdern im Projekt diesen Wow-Effekt erreichen.

So wichtig ein funktionierender Prototyp ist, ist er dennoch nicht das wichtigste Ergebnis der Prototyping-Arbeit. Noch wichtiger ist das, was die Teams aus dem Prototyping-Prozess lernen.

Und man kann eine Menge in vielen verschiedenen Bereichen lernen, wenn man einen Prototypen baut:

Etwas über das Problem lernen

  • Was wissen wir darüber, was wir hier zu entwickeln versuchen?
  • Wie hat das Bauen des Prototyps unsere Perspektive dahingehend verändert, wie wir das Problem lösen wollen?
  • Welche Teile des Problems sind leicht lösbar?
  • Welche Teile des Problems bleiben große Herausforderungen?

Etwas über die Nutzer lernen

  • Welche neuen Dinge über unsere User wissen wir jetzt?
  • Welche neuen Fragen über unsere Nutzer sind aufgetreten?
  • Was wird unseren Nutzern leicht fallen?
  • Was könnte für die User immer noch unschön sein?

Etwas über die Umsetzung lernen

  • Was wird einfach zu implementieren sein?
  • Was wird nicht leicht sein, es gut aufzusetzen?
  • Welche neuen Fähigkeiten müssen wir haben, um das beste Nutzererlebnis zu erreichen?

Etwas über potenzielle Lösungen lernen

  • Welche Design-Alternativen gibt es?
  • Welche dieser Alternativen versprechen die besten Resultate?
  • Warum lassen die weniger ansprechenden Resultate das Design fehlschlagen?
  • Welche Elemente könnten künftig nützliche Design-Patterns sein?

Wir lieben es, wenn Teams nicht nur ihre Prototypen präsentieren, sondern auch das, was sie gelernt haben. Einige Teams führen ein offenes Tagebuch des Prototyping-Projekts, in dem sie kontinuierlich erzählen, was sie lernen. Wenn der Fokus aufs Lernen gerichtet wird, verstehen alle um das Team herum besser, was mit dem finalen Design erreicht werden soll.

Fallgrube #2: Zu viel konvergieren, nicht genug divergieren

Es ist verführerisch, sich auf den ersten Blick in eine Idee zu verlieben, die einen großen Forschritt gegenüber dem bisher Erreichten darstellt. Teams tun das ständig. Und sind sie erst verliebt, deklarieren sie es als "Das ist es!" und machen sich daran, die Idee zu perfektionieren und zu verfeinern.

Das Auswählen und Verfeinern einer Idee ist der Konvergenz-Teil des Prototyping-Prozesses. Fähige Teams wissen, dass sie damit warten und weitaus länger im Divergenz-Stadium bleiben müssen.

In diesem Stadium legt sich das Team nicht auf eine einzelne Idee fest. Stattdessen fragen sie, wie das Problem sonst noch gelöst werden könnte, und probieren so viele Ideen wie möglich aus. Was, wenn wir es auf diese Art machen würden? Was, wenn wir diesen Ansatz verfolgten? Diese Fragen helfen, Alternativen zu erkennen, die man vorher nicht in Betracht gezogen hat.

Verbringen Teams mehr Zeit mit dem Divergieren, lernen sie mehr über den Problemraum und die potenziellen Lösungen. Wenn sie Ansätze miteinander vergleichen, lernen sie viel über die Dimensionen und die Qualität dessen, was ein gutes Design ausmacht. Die Frage, welche Alternative besser ist, führt zu Diskussionen über die Nuancen des Problems und die möglichen Lösungen, was nicht passieren würde, gäbe es diese Vergleichspunkte nicht.

Wenn man jede Menge Alternativen ausprobiert, braucht man natürlich Prototyping-Werkzeuge und -Techniken, die schnell und flexibel sind, wo sich auch schon die nächste Fallgrube auftut.

Fallgrube #3: Mit der falschen Genauigkeit arbeiten

Prototypen gibt es in allen Formen und Größen, von Skizzen auf Whiteboards oder von mir aus auch Servietten bis hin zu absolut realistisch laufender Software. Sie können Stift und Papier nutzen, ein simples Zeichen-Tool wie Omnigraffle verwenden (obwohl Omnigraffle mir schwerer fällt, als es eigentlich sollte) oder mit jQuery, CSS und HTML im Browser entwickeln.

Es ist verlockend, schnell zu etwas zu springen, das wie das finale Design aussieht. Darin wären die richtig aussehenden Icons und die richtige Typographie enthalten. Es hätte stilisierte Layouts und ein ausgeklügeltes Farbkonzept. (Wer will schon auf ein ausgeklügeltes Farbkonzept verzichten?)

Großartige UX-Profis wählen jedoch die richtige Genauigkeit für jedes Projektstadium. Eine geringere Genauigkeit wie die einer Papier- und Bleistift-Skizze bringt eine andere Art von Reaktionen hervor als eine sehr genaue jQuery-Demonstration. (Deshalb versuchen Tools wie Balsamiq so intensiv, eine geringere Genauigkeit vorzutäuschen.)

Ungenaue Prototypen lassen sich schneller und einfacher erstellen. Sie sind perfekt für das Divergenz-Stadium des Projekts. 20 Varianten zu skizzieren und sie nebeneinander an die Wand zu hängen, eröffnet dem Team eine nette Perspektive auf die Möglichkeiten. "Oooh! Was wäre, wenn wir dieses Ding mit diesem da kombinieren würden?"

Das Erstellen sehr genauer Prototypen dauert länger, sie bringen aber mehr Feinheiten und Nuancen ein. Sie vermitteln ein Gefühl und sind einfacher mit den Details des Szenarios vergleichbar. "Was passiert, wenn unser Nutzer in diese speziellen Umstände gerät? Wie geht die Anwendung mit diesem Fall um?"

Es ist essenziell für den Erfolg des Projekts und den Wert des Prototyps, den Grad an Genauigkeit zu wählen, den das Projekt gerade braucht.

Fallgrube #4: Zu wenig Evaluierung

Eine Prototyp-Iteration lässt sich in vier Stadien aufbrechen:

Planen: Was wollen wir aus dieser Prototyping-Runde lernen? Woran machen wir fest, dass wir dem finalen Design nähergekommen sind?

Implementieren: Den Prototypen des Prototyps bauen.

Messen: Daten wie Meinungen oder Nutzungsinformationen sammeln, die uns sagen, wie gut sich der Prototyp gemacht hat.

Lernen: Auf die Iteration zurückblicken und aufdecken, was wir nun mehr wissen als zuvor und welche Fragen wir in der nächsten Iteration beantworten wollen.

In diesen letzten beiden Stadien – dem Messen und dem Lernen – evaluieren wir den Prototypen, den wir gebaut haben. Viele Teams erstellen Prototypen, ohne sie jemals zu evaluieren oder auch nur daran zu denken, dass sie es tun sollten.

Wenn Sie die Evaluations-Stadien überspringen, können Sie nicht sagen, was Sie aus dieser Prototyping-Arbeit gelernt haben. Evaluation muss nicht schwierig sein. Sie kann die Form einer einfachen Kritik der Art "Tut es das, wovon wir wollten, dass es das tut?" daherkommen. Oder sie besteht aus einem Szenario-Walkthough oder einem simplen User-Test.

Die besten Teams wissen, wie sie den Prototypen evaluieren, bevor sie ihn bauen. Das hilft ihnen, die richtige Genauigkeit für die Iteration festzulegen, und bringt sie schnell zu den besten Ergebnissen.

Fallgrube #5: Fixierung auf ein einziges Prototyping-Tool

Einige Prototyping-Tools wie Axure oder iRise sind sehr vielversprechend. Aber es braucht auch Zeit, bis man sie beherrscht. Es dauert auch, bis man geschickt im Zeichnen von Skizzen ist oder mit jQuery umgehen kann.

Wegen dieses Aufwands wollen einige Teams ein Tool finden, das sie für alles nutzen können. Sie sagen, dass sich diese Investition ins Lernen rentieren müsse, also planen sie, das Tool überall einzusetzen.

Die besten Teams limitieren sich allerdings nicht auf lediglich ein Protoyping-Tool. Sie schärfen ihre Expertise im Hinblick auf verschiedene Tools kontinuierlich. (Tipp: Führen Sie regelmäßig "Prototypathons" durch, in denen sich kleine Teams mit Tools auseinandersetzen, mit denen sie auf Kriegsfuß stehen.) Sie sind für jeden Genauigkeitsgrad und somit für jede Herausforderung gewappnet.

Die Fertigkeit im Umgang mit einem Werkzeug kommt mit der Praxis. Erweitern Teams diese Fertigkeiten auf mehrere Tools, sind sie flexibel. Letztlich dreht sich alles ums Ausprobieren und Variieren.

Das meiste aus dem Prototyping herausholen

Oberflächlich betrachtet, sieht Prototyping aus, als würde man etwas machen, das funktioniert. Aber dieser Blick ist eingeschränkt.

Beim Prototyping geht es darum, Ideen zu umreißen, um sie besser zu verstehen. Es bietet dem Team die Möglichkeit, tief in den Prozess einzudringen und ein tiefes Verständnis vom Problem aufzubauen, das gelöst werden soll. Es ist ein effektiver Weg, um Fortschritte über den Projektverlauf hinweg nicht nur in Form substanzieller Präsentationen zu zeigen. Es geht um das Schaffen eines Unterbaus, auf dessen Grundlage die Entscheidungen diskutiert werden können, die das Team treffen muss.

Umgehen sie diese gängigen Fallgruben, können Teams mehr aus dem Prototyping-Prozess ziehen. Im Gegenzug produzieren sie bessere Nutzererlebnisse.

Dieser Artikel wurde im Original am 2. Mai 2013 unter dem Titel Five Prevalent Pitfalls when Prototyping von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar