Prototyping im UX-Prozess – Wie viel Detail braucht ein Prototyp?

Eine digitale Funktion muss nicht bis ins letzte Detail feststehen, bevor ein Team sie prüft. Ein Prototyp macht die Idee früh greifbar. Doch wie realistisch muss er dafür sein? Beim UX-Prototyping geht es oft um eine einfache Frage: Reicht ein grober Ablaufplan oder braucht es einen klickbaren, visuell ausgearbeiteten Entwurf?

Die kurze Antwort lautet: Das hängt davon ab, was das Team herausfinden oder entscheiden muss. Dabei beeinflusst der Detailgrad, welche Rückmeldungen ein Team erhält. Ein grober Entwurf lenkt den Blick eher auf die Struktur, ein klickbarer Prototyp auf einen Ablauf. Beide sind hilfreich, wenn sie zur Fragestellung passen. Dieser Artikel zeigt, wie sich Low- und High-Fidelity-Prototypen unterscheiden, wann welcher Detailgrad sinnvoll ist und wo die Grenzen liegen.

‍

Was ein Prototyp leistet

Ein Prototyp ist eine vereinfachte Darstellung eines Produkts oder einer Funktion. Er kann aus Skizzen, verbundenen Screens oder einer interaktiven Anwendung bestehen. Teams nutzen ihn, um Annahmen zu prüfen, Ideen zu vergleichen oder Rückmeldungen von Nutzer:innen einzuholen. Oft ist er daher kein früher Produktstand, sondern ein bewusst begrenztes Modell.

Fidelity bezeichnet den Detailgrad eines Prototyps: wie nah er einem möglichen Endprodukt kommt. Dieser Detailgrad hat mehrere Ebenen. Ein Prototyp kann visuell detailliert sein und trotzdem nur wenige Interaktionen bieten. Ein anderer sieht schlicht aus und bildet dennoch einen Ablauf realistisch ab. Deshalb reicht es nicht, Prototypen nach ihrem Aussehen in „schlicht“ und „detailliert“ einzuteilen.

Drei Ebenen des Detailgrads

Für die Auswahl zählen drei Ebenen:

• Visuelle Ausarbeitung: Farben, Typografie und Bildsprache
• Interaktivität: klickbare Wege, Zustände und Reaktionen auf Eingaben
• Inhaltliche Genauigkeit: realistische Texte und Daten

Ein Team kann jede Ebene einzeln steuern. Es kann etwa mit realistischen Texten arbeiten und Farben sowie Bildsprache offenlassen. Der Prototyp richtet sich so nach der Frage, die er beantworten soll.

‍

Wireframe und Prototyp

Auch die Begriffe Wireframe und Prototyp werden oft vermischt. Ein Wireframe zeigt die Struktur eines Screens: Inhalte, Bedienelemente und Bereiche. Ein Prototyp kann diese Struktur übernehmen und zusätzlich einen Ablauf abbilden. Beide schließen sich nicht aus, denn ein Wireframe kann Teil eines Prototyps sein.

Der Unterschied liegt in der Funktion. Ein statisches Wireframe eignet sich, um Layout und Informationshierarchie zu besprechen. Ein interaktiver Prototyp zeigt, wie Nutzer:innen zwischen Ansichten wechseln oder auf Eingaben reagieren. Ein klickbarer Entwurf ist aber nicht automatisch besser, wenn die Interaktion für die Entscheidung keine Rolle spielt.

‍

Low Fidelity für offene Fragen

Ein Low-Fidelity-Prototyp zeigt eine Idee mit wenigen Details. Das kann eine Papierskizze, ein grobes Wireframe oder eine einfache Folge von Screens sein. Er kann einen Ablauf andeuten, muss ihn aber nicht technisch ausführen.

Diese Form passt, solange grundlegende Annahmen offen sind. Verstehen Nutzer:innen die Struktur? Finden sie einen möglichen Weg durch eine Aufgabe? Welche Inhalte erwarten sie an welcher Stelle? Ein grober Entwurf lässt sich leicht verändern, wenn sich die Richtung als unpassend erweist. Außerdem lassen sich mehrere Varianten nebeneinander diskutieren, ohne dass eine davon wie die fertige Lösung wirkt.

Wann Low Fidelity passt

Low Fidelity eignet sich besonders für frühe Konzeptarbeit. Das Team betrachtet zuerst die Informationsstruktur, die Reihenfolge der Schritte oder verschiedene Lösungsansätze. Auch ein früher Test ist sinnvoll, wenn die Aufgabe vor allem Orientierung oder Begriffsverständnis betrifft.

Ein Team plant etwa einen neuen Buchungsablauf, kennt aber die nötigen Angaben und ihre Reihenfolge noch nicht. Eine Skizze mit wenigen Feldern stellt die Struktur zur Diskussion. Eine ausgearbeitete Oberfläche wäre für diese Frage noch nicht nötig.

Die Grenze liegt dort, wo Vereinfachungen die Beobachtung verzerren. Fehlen Reaktionen auf Eingaben, lassen sich Fehlermeldungen kaum beurteilen. Fehlen wichtige Inhalte, können Teilnehmer:innen die Aufgabe nicht realistisch durchspielen. Low Fidelity heißt also nicht, beliebige Details wegzulassen. Die Darstellung braucht genug Kontext für die geplante Prüfung.

‍

High Fidelity für konkrete Interaktionen

Ein High-Fidelity-Prototyp bildet ausgewählte Merkmale des späteren Produkts genauer ab. Er kann dem vorgesehenen Design entsprechen, realistische Inhalte zeigen und mehrere Interaktionen ermöglichen. Häufig ist er klickbar. Das heißt jedoch nicht, dass im Hintergrund echte Daten verarbeitet werden oder die Anwendung technisch vollständig funktioniert.

Er ist sinnvoll, wenn konkretes Verhalten zu prüfen ist. Verstehen Nutzer:innen eine Schaltfläche? Können sie einen mehrstufigen Prozess bewältigen? Wird klar, was nach einer Eingabe passiert? Der höhere Detailgrad erleichtert solche Beobachtungen, weil Nutzer:innen weniger ergänzen müssen. Verlässlicher macht er die Ergebnisse aber nicht automatisch. Dafür braucht es passende Aufgaben, eine klare Fragestellung und sorgfältige Auswertung.

Wann High Fidelity passt

Ein High-Fidelity-Prototyp bietet sich an, wenn die grobe Struktur steht und eine konkrete Interaktion im Mittelpunkt steht. Das kann ein Formular mit Fehlermeldungen, ein komplexer Buchungsweg oder eine Funktion mit mehreren Zuständen sein. Wenn Beteiligte einen Ablauf selbst durchspielen sollen, ist ein klickbarer Prototyp oft geeigneter als eine statische Skizze.

Zu viel Detail kann allerdings ablenken. Teilnehmer:innen könnten Farben oder Bildsprache bewerten, obwohl eine Prozessfrage offen ist. Eine fertige Anmutung weckt zudem Erwartungen, die der Prototyp nicht erfüllt. Das Team markiert deshalb, welche Teile geprüft werden und welche offen sind. Nicht funktionsfähige Elemente kennzeichnet es als Platzhalter.

‍

Den passenden Detailgrad wählen

Der Projektzeitpunkt allein entscheidet nicht. „Low Fidelity am Anfang, High Fidelity am Ende“ ist eine Orientierung, keine Regel. Ein frühes Konzept braucht Details, wenn sonst die Interaktion unklar bleibt. Umgekehrt genügt für eine späte Frage manchmal eine einfache Darstellung, wenn es nur um wenige Inhalte geht. Vor dem Erstellen klärt das Team vier Fragen:

• Entscheidung: Welche Annahme oder welchen offenen Punkt soll der Test klären?
• Handlung: Was müssen Nutzer:innen tatsächlich tun? Bei Orientierung genügt oft eine statische Darstellung. Bei einem Ablauf braucht es klickbare Schritte.
• Details: Welche Inhalte und Zustände beeinflussen das Ergebnis? Nur diese ergänzt das Team.
• Ergebnis: Was soll nach dem Test entschieden werden? Der Prototyp muss dafür genug Informationen liefern.

Ein Team arbeitet also nicht möglichst viele Screens aus, sondern ergänzt gezielt die relevanten Details. Entstehen beim Erstellen neue Fragen, passt es den Umfang an oder plant einen separaten Prototyp für eine weitere Annahme.

Vom Low- zum High-Fidelity-Prototyp

Der Detailgrad wächst oft im Laufe eines Projekts. Der Wechsel bietet sich an, sobald die Struktur geklärt ist und nur noch die Interaktion offen bleibt. Im Buchungsbeispiel steht dann fest, welche Angaben in welcher Reihenfolge nötig sind. Das Team übernimmt diese Struktur und arbeitet Eingaben, Fehlermeldungen und Zustände aus.

‍

Auswertung im UX-Prozess

Die Wahl des Detailgrads endet nicht mit dem Bau. Sobald ein Test läuft, entscheidet die Auswertung, was das Team daraus lernt. Prototyping begleitet den gesamten UX-Prozess: Teams nutzen Prototypen, um Ideen zu sortieren, Strukturen zu prüfen oder Abläufe mit Nutzer:innen zu testen.

Bei der Auswertung trennt das Team Beobachtungen von Deutungen. Wenn jemand eine Schaltfläche nicht findet, ist das zunächst die Beobachtung. Mögliche Ursachen sind eine unklare Beschriftung, ihre Position oder ein fehlender Hinweis. Erst weitere Beobachtungen zeigen, welche Erklärung sich stützen lässt.

Diese Trennung gilt auch für Feedback. Einzelne Wünsche sind Hinweise, aber nicht automatisch für alle Nutzer:innen relevant. Ein Test zeigt, wie die geprüfte Aufgabe für die beteiligten Personen funktioniert. Er ersetzt jedoch nicht weitere Formen von UX-Research. Das Team ordnet die Aussagekraft deshalb ein und prüft offene Fragen gezielt.

‍

Prototyping gemeinsam planen

Die UseTree GmbH unterstützt Unternehmen dabei, Prototypen gezielt im UX-Prozess einzusetzen. Wir klären gemeinsam, welche Fragestellung ein Prototyp beantworten soll, welcher Detailgrad dafür nötig ist und wie sich der Entwurf sinnvoll testen lässt. Dabei verbindet UseTree UX-Research mit UX-Design und begleitet Teams bei der Auswertung.

‍

Fazit

Beim UX-Prototyping erfüllen Low- und High-Fidelity-Prototypen unterschiedliche Aufgaben. Ein einfacher Entwurf eignet sich, um offene Strukturen und frühe Annahmen zu prüfen. Ein detaillierter Prototyp hilft bei konkreten Interaktionen und Abläufen. Entscheidend ist, nur so viel auszuarbeiten, wie die nächste Produktentscheidung braucht.

‍