Usability-Berichte: Beobachtung, Deutung und Empfehlung trennen

Trennen Sie Beobachtung, Deutung und Empfehlung

„Die Person öffnete auf der Suche nach dem Export die Abrechnung“ ist eine Beobachtung. „Sie erwartete den Export bei den Kontoeinstellungen“ ist eine zu prüfende Deutung. „Den Button verschieben“ ist ein Gestaltungsvorschlag. Diese Trennung macht einen Usability-Bericht überprüfbar, ohne eine Lösung bereits als erwiesene Tatsache darzustellen.

Das folgende Beispiel ist hypothetisch. Es beschreibt weder eine echte ScribeFlash-Studie noch eine nachgewiesene Verbesserung durch ein neues Design.

1. Legen Sie die Aufgabe fest und zeichnen Sie extern auf

Vereinbaren Sie Ziel, Ausgangszustand, Produktversion, Gerät oder assistive Technik und das Kriterium für den Abschluss. „Bereiten Sie einen Bericht für eine Kollegin vor“ lässt den Weg offen. „Klicken Sie auf Exportieren“ verrät den Schritt, den Sie womöglich untersuchen möchten.

Der GOV.UK-Leitfaden für moderierte Usability-Tests empfiehlt glaubwürdige Aufgaben, die den Lösungsweg nicht vorgeben. Halten Sie außerdem jede Hilfestellung der Moderation fest.

Klären Sie die Aufnahmeerlaubnis und den Umgang mit persönlichen Informationen. Zeichnen Sie die Sitzung mit Ihren Forschungs- oder Besprechungswerkzeugen auf und laden Sie die Audio- oder Videodatei hoch. ScribeFlash zeichnet den Testbildschirm nicht auf und beobachtet keine Mausbewegungen automatisch. Ein Transkript erfasst Gesprochenes; stille Bedienhandlungen brauchen Beobachtungsnotizen und die externe Aufnahme als Quelle.

2. Schreiben Sie zuerst eine Belegnotiz

In der erfundenen Aufgabe T1 öffnet U1 die Abrechnung, kehrt zum Projekt zurück und fragt bei 04:18: „Wo bekomme ich eine Datei zum Verschicken?“ Danach zeigt die Moderation auf den Exportbutton.

Notieren Sie getrennt:

• Beobachtung: Navigation, Rückkehr, Frage und Hilfestellung. Ordnen Sie Bedienhandlungen der Beobachtung oder Videoaufnahme zu, das Zitat dem Transkript.
• Deutung: Position oder Beschriftung des Exports könnten den Erwartungen widersprechen. Berechtigungen oder ein ungewohnter Projektzustand sind weitere mögliche Ursachen.
• Empfehlung: Einen klareren Einstieg oder eine andere Beschriftung testen. Das bleibt zunächst ein Vorschlag.

Leiten Sie aus einem Satz allein weder Frustration noch einen Mauspfad ab. Fehlt die externe Aufnahme, kennzeichnen Sie die nicht prüfbaren Handlungen. Der Leitfaden zur Forschungsanalyse trennt ebenfalls Beobachtungen, Erkenntnisse und Maßnahmen.

3. Erstellen Sie einen prüfbaren Problemeintrag

Ein Eintrag für Design und Entwicklung sollte enthalten:

1. Konkreter Titel: „U1 findet den Berichtsexport nicht ohne Hilfe“.
2. Aufgabe und Umgebung: T1, Startseite, Prototyp oder Version, Gerät und relevante Kontobedingungen.
3. Beobachteter Ablauf: Tatsächlich gesehene Schritte einschließlich Moderationseingriffen.
4. Quellen: Personenkennung, Zeitstempel, genauer Wortlaut und zugeordnete Beobachtungsnotiz.
5. Auswirkung auf die Aufgabe: Abbruch, Abschluss mit Hilfe oder Umgehungslösung.
6. Mögliche Ursachen: Deutung, alternative Erklärungen und offene Fragen.
7. Weiteres Vorgehen: Verantwortliche Person, zu testende Änderung oder Frage und benötigte Belege.

Speichern Sie passende gesprochene Passagen als Belege, den beobachteten Kontext als Forschungsnotiz. Eine Forschungsfrage kann mehrere Momente derselben Aufgabe verbinden, ohne aus jedem Zitat eine eigene Erkenntnis zu machen.

4. Priorisieren Sie nach der Auswirkung auf die Aufgabe

Definieren Sie Ihre Prioritätsstufen. Eine Blockade ohne Ausweg, wiederholte Wiederherstellungsschritte und ein kurzes Zögern wegen einer Formulierung haben unterschiedliche Folgen. Prüfen Sie, ob die Moderation ein Scheitern verdeckt hat und ob die betroffene Aufgabe wesentlich ist.

„U1 brauchte einen Hinweis“ ist genauer als „Nutzer können nicht exportieren“. Nennen Sie bei Häufigkeiten, wer dieselbe Aufgabe unter vergleichbaren Bedingungen versucht hat. Eine kleine, gezielt rekrutierte Studie liefert keine Fehlerquote für die gesamte Nutzerschaft.

Bewahren Sie auch erfolgreiche Versuche auf. Findet die fiktive Person U2 den Export sofort, vergleichen Sie Startseite, Vorerfahrung und sichtbare Berechtigungen. Der Unterschied kann erklären, wann das Hindernis auftritt.

5. Richten Sie den Bericht auf den nächsten Test aus

Nennen Sie Entscheidung und Aufgabe, anschließend Hindernis, Quellen, Folgen, alternative Erklärungen und nächste Prüfung. Erfolgreiche Versuche und ungelöste Fragen gehören ebenfalls hinein.

Beim hypothetischen Exportproblem könnten Sie die bisherige Beschriftung mit einer klareren Variante vergleichen und die Aufgabe neutral halten. Vereinbaren Sie vorher, was Sie beobachten: selbstständiges Finden, Hilfebedarf, gewählter Weg und Eignung der Datei für die Übergabe. Beschreiben Sie zukünftige Beobachtungen nicht als bereits erzielte Verbesserung.

Prüfen Sie Erkenntnisse in ScribeFlash anhand ihrer Belege, bevor Sie sie bestätigen. Der Berichtseditor übernimmt bestätigte Erkenntnisse in einen bearbeitbaren Bericht. Die menschliche Prüfung muss weiterhin Gesprochenes, Beobachtungsnotizen und Vorschläge auseinanderhalten; sie kann keine nie aufgezeichnete Handlung ergänzen.

Beginnen Sie mit einer Vorlage

Wählen Sie den Usability-Test in den Forschungsvorlagen. Das Beispielprojekt mit Downloads zeigt die Verbindung von Belegen und Bericht mit deutlich gekennzeichneten Simulationsdaten. Für den Vergleich mehrerer Sitzungen hilft der Leitfaden zur Interviewanalyse.

Vor dem Teilen

Jeder Eintrag sollte Aufgabe, Quellen, Hilfe und beobachtete Folge benennen. Begrenzen Sie Deutungen, kennzeichnen Sie Empfehlungen als Vorschläge und entfernen Sie unnötige identifizierende Angaben. Der Empfänger muss erkennen können, was geschah, wie Sie es einordnen und was als Nächstes geprüft werden soll.