In der Auswertung nach dem Usability-Test liegt neben den Befunden eine Notiz aus der dritten Sitzung: Die Testperson hat den Test unterbrochen, weil ein Anruf kam, und wusste danach nicht mehr, wo sie war. Im Bericht landet so eine Notiz als Fehler im Produkt oder gar nicht. Damit endet der Gestaltungszyklus an der Stelle, an der er nach ISO 9241-210 weitergehen sollte. Wir beschreiben, wie Beobachtungen aus der Evaluation in die Kontextbeschreibung zurückfließen und welche Artefakte dafür aktualisiert werden.
Ausgangslage
Ein Usability-Test erzeugt in der Regel einen Bericht mit Befunden, Schweregraden und Empfehlungen. Der Bericht geht an das Entwicklungsteam, die Befunde werden zu Tickets, die Tickets werden abgearbeitet. Was dabei verloren geht: Der Test hat die Nutzenden bei der Arbeit gezeigt. Er hat Aufgaben sichtbar gemacht, die im Nutzungskontext bisher nicht beschrieben waren, Arbeitsmittel, die niemand erwähnt hatte, und Bedingungen, unter denen das Konzept nicht funktioniert. Diese Beobachtungen sind Kontextwissen. Wenn sie nur als Fehler im Produkt dokumentiert werden, fehlen sie in der nächsten Schleife.
ISO 9241-210 beschreibt vier Aktivitäten, die wiederholt werden: Nutzungskontext verstehen, Nutzungsanforderungen festlegen, Gestaltungslösungen entwerfen, Lösungen evaluieren. Der Pfeil aus der Evaluation zeigt zurück auf jede der drei anderen Aktivitäten. Der Weg zurück zur ersten Aktivität ist in den Projekten, die wir kennen, am seltensten organisiert. Wir beschreiben, wie wir ihn in der Auswertung anlegen.
Zwei Arten von Befunden unterscheiden
Der erste Schritt liegt in der Auswertung. Wir ordnen jeden Befund einer von zwei Arten zu. Die erste Art betrifft die Lösung: Ein Element wurde nicht gefunden, ein Begriff nicht verstanden, ein Schritt übersprungen. Diese Befunde gehen in den Entwurf zurück. Die zweite Art betrifft den Kontext: Die Testperson hat eine Aufgabe erledigt, die im Testplan nicht vorkam. Sie hat ein zweites Gerät benutzt. Sie hat erwähnt, dass im Betrieb zwei Personen die Freigabe erteilen. Sie hat den Test unterbrochen, weil ein Anruf kam, und danach nicht mehr gewusst, wo sie war.
Befunde der zweiten Art sind keine Fehler im Produkt. Sie sind Beobachtungen über Nutzende, Aufgaben, Arbeitsmittel und Umgebung. Markieren Sie sie in der Auswertung und geben Sie sie getrennt weiter. Die Person, die die Kontextbeschreibung pflegt, ist selten dieselbe, die die Tickets schreibt.
Die Kontextbeschreibung aktualisieren
Befunde der zweiten Art arbeiten wir in die Kontextbeschreibung ein, entlang der vier Bestandteile nach ISO 9241-11: Nutzende, Aufgaben, Arbeitsmittel, Umgebung. Eine neu beobachtete Aufgabe wird im Aufgabenmodell ergänzt, mit Quelle (Testsitzung, Datum, Testperson anonymisiert). Ein zusätzliches Arbeitsmittel wird in der Liste der Arbeitsmittel aufgenommen. Eine Umgebungsbedingung, die in der Sitzung auffiel, wird beim Bestandteil Umgebung nachgetragen; der Anruf aus dem Lead steht dann dort als Unterbrechung mit Wiederaufnahme.
Jede Ergänzung erhält einen Vermerk, ob sie aus einer einzelnen Sitzung stammt oder in mehreren Sitzungen auftrat. Eine Beobachtung aus einer Sitzung ist ein Hinweis, der in der nächsten Kontexterhebung geprüft wird. Eine Beobachtung aus mehreren Sitzungen ist eine Grundlage für Anforderungen.
Die Nutzungsanforderungen nachziehen
Eine geänderte Kontextbeschreibung verändert die Anforderungen. Eine neue Aufgabe braucht eine Anforderung. Eine neue Bedingung ändert die Bedingung in bestehenden Anforderungen. Ein Arbeitsmittel, das parallel genutzt wird, erzeugt eine Anforderung an den Wechsel zwischen den Systemen.
Der Abgleich läuft in zwei Richtungen. Erstens: Welche Anforderungen sind durch die Evaluation erfüllt, welche nicht, welche wurden nicht geprüft? Das ist der Erfüllungsstatus, der über die nächste Iteration entscheidet. Zweitens: Welche Anforderungen fehlen, weil die Evaluation Kontext gezeigt hat, der vorher unbekannt war? Das ist der Zuwachs, den die nächste Schleife aufnimmt.
Die Artefakte, die dabei angefasst werden
Vier Dokumente verändern sich nach einer Evaluation, wenn der Rückfluss organisiert ist. Die Kontextbeschreibung erhält neue Einträge mit Quelle. Die Nutzungsanforderungen erhalten einen Erfüllungsstatus und neue Einträge. Der Testplan der nächsten Evaluation erhält Aufgaben, die aus den neuen Beobachtungen stammen. Und der Testbericht selbst bekommt neben dem Befundteil einen Abschnitt „Beobachtungen zum Nutzungskontext", damit die zweite Befundart sichtbar bleibt, auch wenn nur der Bericht weitergegeben wird.
In früheren Berichten hatten wir diese Beobachtungen in den Anhang geschrieben. Der Anhang wurde nicht gelesen, und in der nächsten Kontexterhebung fehlten die Hinweise. Seitdem steht der Abschnitt im Hauptteil unserer Berichtsvorlage, und die Unterscheidung der Befundarten ist bei jeder Auswertung Pflicht.
Grenzen
Der Einwand, dass ein Test im Labor keinen Nutzungskontext erhebt, trifft zu. Die Evaluation findet unter Testbedingungen statt, mit Aufgaben, die das Team gestellt hat, und oft außerhalb des Einsatzortes. Beobachtungen aus dem Test sind deshalb Hinweise auf den Kontext, keine vollständige Erhebung. Einen Hinweis, der die Anforderungen wesentlich verändert, prüfen wir im Feld, bevor daraus eine Gestaltungsentscheidung folgt. Und nicht jede Bemerkung einer Testperson ist Kontext. Was eine Person über ihre Kolleginnen berichtet, ist Selbstauskunft und wird als solche gekennzeichnet.
Was danach vorliegt
Nach der Evaluation liegt eine Kontextbeschreibung vor, die den Stand nach dem Test abbildet, mit markierten Ergänzungen und ihrer Quelle. Die Nutzungsanforderungen haben einen Erfüllungsstatus, und die Lücken sind benannt. Der Testbericht enthält beide Befundarten getrennt. Der Testplan der nächsten Evaluation enthält die Aufgaben, die aus den neuen Beobachtungen stammen.