Nach einer Beobachtungsrunde liegen Notizen von mehreren Personen vor, jede mit anderen Schwerpunkten. Daraus soll eine Nutzungsanforderung werden, die das Team teilt und die sich später prüfen lässt. Dieser Beitrag beschreibt den Weg von den Rohnotizen über die Verdichtung zu Befunden bis zur formulierten Anforderung, damit die Auswertung für Teams ohne Research-Stelle nachvollziehbar wird.
Ausgangslage
Die Auswertung ist der Schritt, der im Ergebnis unsichtbar bleibt. Ein Team sieht den Bericht oder das Anforderungsdokument, aber nicht die Entscheidungen dazwischen: welche Beobachtungen zusammengehören, was ein Befund ist und was ein Einzelfall, wie aus einem Befund eine Anforderung wird, die keine Lösung vorwegnimmt. Wenn das Team selbst mitgeschaut und notiert hat, ist die Auswertung der Punkt, an dem die gemeinsamen Beobachtungen entweder zu einer gemeinsamen Anforderung werden oder in Einzelmeinungen zerfallen.
Voraussetzung für das Vorgehen unten sind Notizen in einer gemeinsamen Form: je Beobachtung eine Zeile mit Aufgabe, Verhalten, Äußerung und getrennt davon der Deutung. Wie solche Notizen entstehen, beschreibt der Beitrag zum Mitschauen mit Auftrag.
Schritt 1: Notizen zusammenführen
Alle Notizen aller Beobachtenden werden in eine Liste überführt, je Zeile eine Beobachtung, mit Angabe, aus welcher Session und von welcher Person sie stammt. Deutungen bleiben in ihrer Spalte und werden nicht mit Beobachtungen vermischt. Beobachtungen, die sich auf dieselbe Stelle in derselben Session beziehen, werden nebeneinander gelegt, aber noch nicht zusammengefasst.
Der Zweck dieses Schritts ist Vollständigkeit. Wer hier bereits verdichtet, verliert Beobachtungen, die erst im Vergleich über Sessions Bedeutung bekommen.
Schritt 2: Beobachtungen zu Befunden verdichten
Ein Befund ist eine Aussage über ein wiederkehrendes Verhalten an einer bestimmten Stelle des Produkts. Er entsteht, wenn mehrere Beobachtungen dasselbe Muster zeigen: mehrere Teilnehmende suchen an derselben Stelle, brechen dieselbe Aufgabe ab oder deuten denselben Begriff anders als vorgesehen.
Die Verdichtung folgt einer Regel, die vorher festgelegt ist: ab welcher Anzahl von Teilnehmenden aus einer Beobachtung ein Befund wird und wie Einzelbeobachtungen behandelt werden. Einzelbeobachtungen werden nicht verworfen; sie bleiben als Hinweise mit geringerer Sicherheit im Katalog.
Jeder Befund erhält eine Beschreibung des Verhaltens, die Stelle im Produkt, die Aufgabe, die Verweise auf die zugrunde liegenden Beobachtungen und einen Schweregrad. Der Schweregrad folgt der dokumentierten Logik des Teams, etwa danach, ob die Aufgabe abgebrochen wurde oder ob ein Umweg zum Ziel führte.
Der Zweck dieses Schritts ist Nachvollziehbarkeit. Jeder Befund lässt sich bis zu den Beobachtungen zurückverfolgen, aus denen er entstand. Wenn jemand im Team einen Befund bezweifelt, lässt sich die Frage mit den vorliegenden Beobachtungen klären.
Schritt 3: Deutungen prüfen
Erst jetzt kommen die Deutungen aus der Notizspalte dazu. Je Befund werden die Deutungen der Beobachtenden gesammelt und gegen die Beobachtungen geprüft: Welche Deutung erklärt alle zugehörigen Beobachtungen, welche nur einen Teil, welche widerspricht einer Beobachtung. Deutungen, die sich halten, werden als Hypothese zum Befund vermerkt. Deutungen, die den Beobachtungen widersprechen, werden dokumentiert und verworfen.
Der Zweck dieses Schritts ist, die Erklärung von der Beobachtung getrennt zu halten und trotzdem zu nutzen. Das Team hat mitgedacht, und dieses Mitdenken geht in den Prozess ein, aber geprüft.
Schritt 4: Nutzungsanforderungen formulieren
Aus einem Befund wird eine Nutzungsanforderung, indem das beobachtete Verhalten in eine Aussage darüber übersetzt wird, was Nutzende mit dem Produkt erreichen können müssen. Die Form nach ISO 9241-210: Nutzergruppe, Aufgabe, Bedingung, prüfbares Ergebnis. Ein Beispiel: Aus dem Befund „Teilnehmende suchen die Funktion zum Verschieben eines Termins im Menü und brechen ab" wird die Anforderung „Sachbearbeiterinnen müssen einen Termin aus der Terminansicht heraus verschieben können, ohne die Ansicht zu verlassen".
Die Anforderung nennt das Ziel und die Bedingung. Sie nennt keine Lösung. „Es braucht einen Kalender mit Drag-and-drop" wäre eine Gestaltungsentscheidung, die im nächsten Schritt getroffen wird, mit Alternativen.
Jede Anforderung verweist auf den Befund und über ihn auf die Beobachtungen. Damit ist die Kette geschlossen: Wer die Anforderung liest, kann bis zur Session zurückgehen.
Schritt 5: Gemeinsam abnehmen
Die Anforderungen werden im Team vorgestellt, mit den Befunden und den Beobachtungen dahinter. Die Beobachtenden erkennen ihre Notizen wieder. Einwände beziehen sich auf die Beobachtungen und nicht auf die Person, die ausgewertet hat. Die Priorisierung der Anforderungen bleibt Aufgabe der Produktverantwortlichen, mit Blick auf Schweregrad und Geschäftsanforderungen.
Grenzen
Das Vorgehen setzt Notizen in gemeinsamer Form voraus. Aus Gedächtnisprotokollen oder freien Texten lässt sich die Kette nicht schließen. Es setzt außerdem eine Regel für die Verdichtung voraus, die vor der Auswertung feststeht; wer sie während der Auswertung festlegt, passt sie an das gewünschte Ergebnis an. Und es liefert Anforderungen für den beobachteten Ausschnitt. Aussagen über andere Nutzergruppen oder Aufgaben brauchen eine eigene Erhebung.
Für die Verdichtung braucht es Übung. In den ersten Zyklen übernimmt sie die Research-Rolle oder wir, und jede Entscheidung wird laut begründet. Danach kann das Team sie selbst durchführen.
Was danach vorliegt
Am Ende liegen ein Befundkatalog mit Schweregraden und Verweisen, eine Liste geprüfter und verworfener Deutungen und ein Anforderungsdokument vor, in dem jede Anforderung bis zu den Beobachtungen zurückverfolgbar ist. Das Team hat die Auswertung gesehen und kann sie beim nächsten Mal nachvollziehen oder übernehmen. Für die Gestaltung ist das Dokument die Übergabe, für die Evaluation der Maßstab.