Legen Sie zuerst das Risiko fest, das Sie überprüfen möchten, bereiten Sie realistische Inhalte und die wichtigsten Zustände vor, erstellen Sie den einfachsten geeigneten Prototyp und geben Sie den Teilnehmenden konkrete Aufgaben. Übersetzen Sie die Erkenntnisse vor dem visuellen Design oder der Entwicklung in Entscheidungen und Akzeptanzkriterien.
Ein Website-Prototyp ermöglicht es, Struktur, Inhalte und Verhalten zu überprüfen, bevor das Team in das finale Design und den Code investiert. Ein Wireframe kann eine einfache Skizze des Layouts sein, ein klickbarer Prototyp zeigt dagegen den Weg zwischen den Bildschirmen. Der Wert liegt nicht in der optischen Detailtreue, sondern in der Möglichkeit, eine falsche Reihenfolge, einen fehlenden Zustand oder eine unklare Aktion kostengünstig aufzudecken.
Der Detaillierungsgrad muss an die Fragestellung angepasst werden. Geht es um Bezeichnungen und Informationsarchitektur, lenken visuelle Effekte nur ab. Bei der Prüfung eines komplexen Formulars können eine realistischere Interaktion und realistischere Inhalte nötig sein. Ein Prototyp ist kein Versprechen einer fertigen Implementierung; seine Grenzen müssen den Teilnehmenden ebenso klar sein wie den Personen, die das Projekt freigeben.
Wählen Sie die Detailtreue des Prototyps nach der Fragestellung
Eine Papierskizze oder ein einfaches Wireframe genügt für die Reihenfolge der Abschnitte, die Hierarchie und den grundlegenden Ablauf. Ein klickbarer Prototyp hilft bei Navigation, mehrstufigen Formularen oder Rollen. Ein programmierter Prototyp ist sinnvoll bei technisch unsicherem Verhalten, bei Performance- oder Integrationsfragen. Höhere Detailtreue ist nicht automatisch besser und kann die Kosten von Änderungen unnötig erhöhen.
Schreiben Sie zu Beginn auf, was der Prototyp enthält und was er nur simuliert. Fiktive Daten, eine nicht funktionierende Schaltfläche oder vereinfachte Berechtigungen können den Test beeinflussen. Glaubt ein Teilnehmer, es handle sich um ein fertiges Produkt, beschäftigt er sich mit Gestaltungsdetails und Fehlern, die nichts mit der Forschungsfrage zu tun haben. Eine angemessene Einführung sichert die Interpretation der Ergebnisse.
Arbeiten Sie mit realistischen Inhalten und Grenzfällen
Blindtext zeigt nicht, ob eine Überschrift das Angebot erklärt, ein Menüpunkt passt oder eine Tabelle lesbar bleibt. Verwenden Sie echte Bezeichnungen, typische Längen, Beispielfehler und Inhalte in den Sprachen, die die Website benötigt. Ersetzen Sie sensible Daten durch sichere synthetische Beispiele. Inhalte sind Teil der Benutzeroberfläche, keine nachträgliche Füllung.
Entwerfen Sie den leeren Zustand, das Laden, ungültige Eingaben, verweigerte Berechtigungen und den erfolgreichen Abschluss. Der Idealpfad verdeckt oft die teuersten Unklarheiten. Prüfen Sie auf Mobilgeräten Reihenfolge, Tastatur, lange Werte und die Erreichbarkeit der Hauptaktion. Beim responsiven Design genügt es nicht, das Desktop-Layout zu verkleinern; die Prioritäten können sich ändern.
- Typische und lange Inhalte
- leerer, Fehler- und Erfolgszustand
- mobile Reihenfolge und Bedienung
- Rollen und Grenzen der verfügbaren Aktionen
Bereiten Sie ein Szenario auf Basis einer realen Aufgabe vor
Eine Aufgabe sollte Kontext und Ziel haben, ohne den genauen Lösungsweg zu verraten. Statt „Klicken Sie auf Leistungen“ beschreiben Sie, was die Person herausfinden oder erledigen möchte. So sehen Sie, welche Bezeichnungen und welchen Weg sie erwartet. Verwenden Sie bei mehreren Teilnehmenden denselben Kern des Szenarios, damit sich Muster vergleichen lassen, passen Sie die Nachfragen aber dem Verhalten an.
Der Moderator sollte während einer Aufgabe weder den Entwurf verteidigen noch sofort Ratschläge geben. Er fragt nach Erwartungen, der Bedeutung von Informationen und dem Grund für eine Entscheidung. Halten Sie Erfolg, Zögern, falsches Ziel und benötigte Hilfe fest. Die Zeit kann ein nützlicher Kontext sein, doch bei einer kleinen qualitativen Stichprobe sollten Sie daraus keine scheinbar präzise Kennzahl ableiten.
Trennen Sie Feedback vom beobachteten Verhalten
Ein Kommentar zur Farbe ist eine Meinung, ein Klick auf einen falsch benannten Eintrag ist beobachtetes Verhalten. Beide Informationen lassen sich festhalten, haben aber ein unterschiedliches Gewicht. Suchen Sie bei einem Problem die Ursache im Inhalt, in der Hierarchie, in der Erwartung oder in fehlendem Feedback. Übertragen Sie den Vorschlag eines einzelnen Teilnehmers nicht direkt in die Oberfläche, ohne das Gesamtbild zu bewerten.
Fassen Sie nach jedem Test die Erkenntnisse kurz zusammen und beheben Sie nur kritische Fehler, die weiteren Personen die Fortsetzung unmöglich machen. Wenn Sie den Prototyp laufend ändern, kennzeichnen Sie die Version, damit sich die Ergebnisse nicht vermischen. Suchen Sie nach wiederkehrenden Mustern und Fällen mit großer Auswirkung, nicht nach der Anzahl der Stimmen für eine bestimmte visuelle Variante.
Übergeben Sie Entscheidungen an Design und Entwicklung
Das Testfazit sollte Problem, Beleg, Auswirkung und Entscheidung enthalten. Aktualisieren Sie Inhalt, Ablauf, Komponente oder Anforderung und ergänzen Sie ein Akzeptanzkriterium. So weiß das Team, was die Implementierung sicherstellen muss. Ein bloßer Link zum Prototyp reicht nicht, da er weder die Diskussion über Alternativen noch die Grenzen der Simulation enthält.
Kennzeichnen Sie vor der Entwicklung, welche Zustände verifiziert wurden, welche Hypothese bleiben und wo ein technischer Prototyp nötig ist. Kehren Sie bei Änderungen während der Implementierung zum ursprünglichen Ziel zurück, nicht zur visuellen Ähnlichkeit. Testen Sie nach dem Deployment das Live-Produkt; Technologie, Inhalte und reale Daten können neue Probleme verursachen.
- Problem und beobachteter Nachweis
- freigegebene Entscheidung und ihre Grenzen
- Abnahmekriterium für die Implementierung
- verantwortlicher Eigentümer offener technischer Unsicherheit
Häufige Fragen
Was ist der Unterschied zwischen einem Wireframe und einem Prototyp?
Ein Wireframe zeigt in der Regel das grundlegende Layout und die Hierarchie. Ein Prototyp kann zusätzlich Übergänge und Verhalten simulieren. In der Praxis überschneiden sich die Begriffe; wichtiger ist es, den Detailgrad und den Zweck anzugeben.
Muss ein Prototyp wie die finale Website aussehen?
Nein. Er sollte realistisch genug für die Frage sein, die Sie überprüfen. Ein zu fertiges Erscheinungsbild kann Änderungen erschweren und von Inhalt, Ablauf oder Funktion ablenken.
Kann ein Prototyp als Vorgabe für die Entwicklung dienen?
Er ist ein wichtiger Bestandteil, muss aber um Regeln, Zustände, Daten, Barrierefreiheit, Sicherheit und Akzeptanzkriterien ergänzt werden. Ein klickbarer Prototyp erklärt nicht von sich aus alle betrieblichen Anforderungen.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
