Im Research-Board stehen Notizen aus mehreren Sitzungen. Ein Teil betrifft denselben fehlenden Hinweis, andere beschreiben technische Defekte oder Ideen der Teilnehmer. Wenn jede Notiz als gleichwertige Aufgabe ins Backlog wandert, hat das Team zwar eine lange Liste, aber noch keine Reihenfolge.
Erst den Befund bilden, dann priorisieren
Damit du aus einer Research-Notiz eine sinnvolle Änderung ableiten kannst, brauchst du den Zusammenhang zwischen Aufgabe und Beobachtung. „Person sucht zweimal in der Navigation“ beschreibt zunächst nur Verhalten; „Die Kategorien sind falsch“ legt dagegen bereits eine Erklärung fest. Welche Aufgabe die Person erledigen und welche Information sie finden wollte, hilft dir zu beurteilen, ob diese Erklärung durch den beobachteten Weg gestützt wird.
Die GOV.UK-Anleitung zur Research-Auswertung trennt Beobachtungen, zusammengeführte Befunde und nachfolgende Aktionen. Verknüpfe im Backlog deshalb die Änderung mit dem Befund und den zugrunde liegenden Notizen. Mehrere Beobachtungen desselben Problems müssen nicht zu mehreren Umsetzungstickets werden.
Vier Fragen für die Reihenfolge
Für die Reihenfolge kommt es darauf an, was das Problem bei der betroffenen Aufgabe bewirkt. Ein häufig kommentiertes Detail muss den Abschluss nicht verhindern, während ein selten beobachteter Fehler den ganzen Vorgang blockieren kann. Die folgenden Fragen helfen dir, diese Folgen gemeinsam mit den Abhängigkeiten zu beurteilen.
| Frage | Was du dazu festhältst |
|---|---|
| Welche Folge hat das Problem? | Abbruch, falsches Ergebnis, Umweg oder Verständnisfrage |
| Für wen gilt der Befund? | Untersuchte Nutzergruppe und passende Situationen |
| Wie gut ist die Erklärung gestützt? | Beobachtungen, Gegenbeispiele und offene Annahmen |
| Was hängt an der Änderung? | Technische Voraussetzung, fachliche Entscheidung und Zuständigkeit |
Du brauchst dafür keine scheinbar genaue Punktzahl. Wenn zwei Aufgaben konkurrieren, sollte das Team erklären können, warum die eine zuerst bearbeitet wird. Unsichere Reichweite bleibt als offene Frage stehen, statt aus einer kleinen Testgruppe hochgerechnet zu werden.
Eine Beschriftung und ein Datenproblem sind verschiedene Aufgaben
Angenommen, Teilnehmer erkennen in einer Terminübersicht nicht, ob ein Platz angefragt oder bestätigt ist. Wenn die Untersuchung sowohl eine unklare Beschriftung als auch eine später eintreffende Serverbestätigung aufzeigt, muss die Änderung beide Ursachen berücksichtigen: Eine neue Farbe allein beschleunigt die Bestätigung nicht.
Ein brauchbarer Backlog-Eintrag hält deshalb fest, welches Verhalten gelten soll: Nach dem Absenden ist die Anfrage erkennbar; eine Bestätigung erscheint erst nach der tatsächlichen Freigabe. Design und Entwicklung können dazu getrennte Aufgaben bekommen. Die gemeinsame Abnahme prüft den gesamten Ablauf.
Andere Befunde können zunächst eine Rückfrage auslösen. Wenn niemand erklären kann, wann eine Anfrage als bestätigt gilt, fehlt eine fachliche Regel. Sie darf nicht im Interface stillschweigend erfunden werden.
Aus dem Bericht eine überprüfbare Änderung machen
Jede priorisierte Aufgabe sollte auf den Befund zurückführen und ein erwartetes Ergebnis nennen. Lege fest, wie die Änderung geprüft wird: erneuter Nutzertest, technische Gegenprobe oder Beobachtung im Betrieb. Ein erledigtes Ticket sagt nur, dass Arbeit abgeschlossen wurde; ob das ursprüngliche Hindernis kleiner geworden ist, muss passend überprüft werden.
Bewahre zurückgestellte Befunde mit ihrer Begründung. Dann beginnt die Diskussion beim nächsten Release nicht wieder mit denselben losgelösten Screenshots.
Wenn in der nächsten Priorisierungsrunde zwei Befunde konkurrieren, könnt ihr ihre Folgen und Abhängigkeiten nebeneinanderlegen. Daraus sollte verständlich werden, warum eine Aufgabe zuerst ansteht. Lässt sich das noch nicht entscheiden, zeigt der Vergleich, welche Information euch dafür fehlt. Diese Unterlage lässt sich in der UX-Entscheidungsberatung weiterbearbeiten. Für eine erneute Untersuchung gehören die passenden Aufgaben und Erfolgskriterien dazu.
