Wie realitätsnah soll’s denn sein? Warum Prototyping mehr ist als „mal eben einen Entwurf zu bauen“

Database Structure

Prototyping hilft dabei, bares Geld einzusparen. Denn mit ihrer Hilfe können bereits in frühen Designphasen erste Konzeptideen getestet werden – und in diesen Phasen lassen sich Probleme meistens noch ohne größeren zeitlichen Aufwand beheben.

Verschiedene Prototyping-Tools ermöglichen es, bereits in kürzester Zeit klickbare Prototypen einer Anwendung (oder auch nur einen einzelnen Funktion) zu erstellen und diese im Usability-Test zu überprüfen. Wer nun aber glaubt, Prototyping heißt „Ich bau mal eben einen Entwurf und dann schauen wir mal“, der irrt. Denn nur wenn der Konzepter im Auge behält, was mit dem Prototyp im Test eigentlich erfasst werden soll, kann er diesen auch effizient und zielgerichtet erstellen.

Je später desto teurer…

Prototypen kommen in vielen Bereichen zum Einsatz. Ihr Sinn ist es, einen frühen Entwurf eines Produktes, einer Anwendung o.ä. abzubilden – entweder komplett oder aber nur in Teilen. Und dies ist auch sehr sinnvoll – ist laut einer Studie von Bias und Mayhew doch die Behebung von Usability-Problemen umso teurer, je weiter der Designprozess bereits fortgeschritten ist. Was auch logisch ist, denn muss eine Funktion z. B. komplett neu programmiert werden kostet dies mehr Zeit, als wenn man die selbe Anpassungen in einem Computerprototyp vornimmt, wo diese i.d.R. durch wesentlich weniger Aufwand zu realisieren sind. Heißt: Je früher ich meine Ideen anhand von Prototypen teste, desto einfacher (und kostengünstiger) kann ich Usability-Probleme beheben.

Phasen

Kostenentwicklung für die Fehlerbehebung im Design-Prozess (Quelle: Bias & Mayhew, Cost Justifying Usability)

Soweit wissen wir also: Prototyping ist sehr sinnvoll, um Probleme frühestmöglich zu beheben. Ebenfalls sinnvoll ist es allerdings, wenn man nicht einfach „drauf los konzipiert“, sondern vorab genau überlegt, was man eigentlich testen möchte. Vor diesem Hintergrund stellt sich also – z. B. vor der Erstellung eines Website-Prototyps die Frage:

Wie ähnlich muss mein Prototyp der späteren Webseite eigentlich sein?

Doch diese Fidelity oder Realitätsnähe eines Prototyps ist schon im Allgemeinen gar nicht so einfach zu bestimmen. Grundsätzlich beschreibt der Begriff der Fidelity, inwiefern der Nutzer in der Lage ist, zwischen einem Prototyp und der realen (späteren) Anwendung zu unterscheiden. Das bedeutet also erst einmal:

Je geringer der augenscheinliche Unterschied zwischen z. B. dem Klickdummy einer Webseite und der der realen Webseite, desto höher die Fidelity.

Aber was bedeutet das eigentlich – augenscheinlicher Unterschied…? Zunächst wurde – sowohl in der Theorie als auch in der Praxis nur in „high“ oder „low Fidelity“ unterschieden. Als low-Fidelity-Prototyp wurden gemeinhin z. B. Papierprototypen verstanden, während klickbare Computerprototypen als high Fidelity galten. Dies klingt auf den ersten Blick nachvollziehbar – immerhin entspricht es nicht unbedingt der realen Nutzungssituation, dass eine Webseite zu bedienen, die nur aus mehreren Papier-Ausdrucken besteht. Da ist es schon realitätsnäher, direkt am Computer mit dem Prototypen zu interagieren.

Aber was ist, wenn mir z. B. der Computerprototyp eines Onlineshops nur ermöglicht, zwei Rubriken in der Hauptnavigation anzuklicken, während ich im Papierprototypen eine komplette Produktsuche inklusive Bestellung ausführen kann?

Solche und ähnliche Fragestellungen machten schließlich deutlich, dass es nicht ausreicht, die Fidelity von Prototypen nur in high oder low zu kategorisieren. Vielmehr stellte sich – sowohl in der Wissenschaft als auch in der Praxis – heraus, dass sich die Realitätsnähe eines Prototyps auf mehreren Dimensionen bestimmen lässt, die voneinander unabhängig sind. Eine sehr bekannte Differenzierung Michael McCurdy.

McCurdy differenziert insgesamt 5 Dimensionen von Fidelity:

  • Visuelle Verfeinerung (Aussehen)
  • Tiefe der Funktionalität
  • Breite der Funktionalität
  • Ausmaß der Interaktionsmöglichkeiten
  • Vollständigkeit des Datenmodells

Jeder der o.g. Dimensionen kann auf dabei unabhängig von den anderen manipuliert werden und entweder über hohe oder geringe Fidelity verfügen. Das dahinterstehende Konzept wird daher auch als „mixed Fidelity“ bezeichnet.

Was hat das nun mit der Konzeption von Prototpyen zu tun?

Ganz einfach: Das Konzept der mixed Fidelity bietet einen guten Anhaltspunkt um vor dem Hintergrund der jeweiligen Fragestellung (z. B. für einen Usability-Test) genau den Prototyp zu entwickeln, der benötigt wird. Ohne dass bei der Konzeption Zeit (und Geld) in die Ausarbeitung von Dimensionen investiert werden, die für die Evaluation gar nicht benötigt werden.

Beispiel: Wenn ich z. B. testen möchte, ob die Nutzer eines Webseiten-Prototyps bestimmte Inhalte auch in der entsprechenden Rubrik der Navigation verorten, sollte mein Prototyp auf der Dimension „Breite der Funktionalität“ über hohe Fidelity verfügen. So kann für jeden Dimension vor dem Hintergrund der Fragestellungen entschieden werden, wie hoch die Fidelity sein muss. Dies gewährleistet eine zielgerichtete Konzeption.

Low and High Fidelity

Unabhängige Manipulation unterschiedlicher Fidelity-Dimensionen (eigene Darstellung).

Nichtsdestotrotz stellt vor allem die Dimension der visuellen Verfeinerung häufig eine Schwierigkeit dar: Fragen wie „Wie ähnlich muss das Layout des Prototyps dem der späteren Anwendung sein?“, „Welche (verzerrenden) Auswirkungen hat die Optik ggf. auf die Bewertung der Anwendung durch die Nutzer?“ sind nur einige Fragen, die hier oftmals diskutiert werden. Auf eine von eResult durchgeführte Grundlagenstudie zu diesem Thema werde ich in meinem nächsten Beitrag näher eingehen.

Welche Erfahrungen haben Sie mit der Konzeption von Prototypen gemacht? Wenden Sie das o.g. Modell bei der Konzeption an? Und: Welche anderen Herausforderungen sehen Sie ggf. bei der Konzeption? Ich freue mich auf Ihre Kommentare!

Ein Gedanke zu „Wie realitätsnah soll’s denn sein? Warum Prototyping mehr ist als „mal eben einen Entwurf zu bauen“

  1. Pingback: Heute teste ich mal ohne Layout – Warum ein Prototyp nicht immer so aussehen muss wie die spätere Webseite | usabilityblog

Schreibe einen Kommentar

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