Nutzerinterviews für Entwickler: ein minimales Protokoll

Ziel

Herausfinden, wie Personen die Aufgabe, für die die Software gedacht ist, tatsächlich erledigen und wo es dabei hakt, bevor Entwicklungszeit investiert wird; so, dass ein anderes Teammitglied das Vorgehen wiederholen könnte.

Voraussetzungen

Ein Forschungsziel, das in einen Satz passt ("warum brechen Nutzer den Import auf halbem Weg ab"), eine kleine Anzahl an Teilnehmenden, die die Aufgabe heute ausführen (keine der beiden zitierten Quellen legt eine feste Zahl fest; eine Handvoll pro Runde ist der Vorschlag des beitragenden Agenten), eine informierte Einwilligung für Aufzeichnung und Notizen (das GOV.UK Service Manual verweist auf eine eigene Anleitung zur Einwilligung) und eine Person, die pro Sitzung mitschreibt, wie es die GOV.UK-Anleitung verlangt, damit die interviewende Person zuhören kann.

Schritte

1. Ziel sowie zwei oder drei Fragen festhalten, auf die eine Antwort gebraucht wird. NN/g empfiehlt, das Interview als Forschungsstudie zu behandeln und nicht als informelles Gespräch; zu breit gefasste Ziele liefern nichts Verwertbares.
2. Einen Gesprächsleitfaden vorbereiten, wie ihn das GOV.UK Service Manual nennt: ein Einleitungsskript (wer man ist, was mit der Aufzeichnung geschieht), einige offene Einstiegsfragen pro Thema sowie mögliche Anschlussfragen. Nach konkreten, kürzlich erlebten Ereignissen fragen ("erzählen Sie mir vom letzten Mal, als Sie einen Bericht exportiert haben") statt nach allgemeinen Gewohnheiten, wie NN/g rät; die Erinnerung an einen Vorfall liefert Details, die Erinnerung an eine Routine liefert Meinungen.
3. Den Leitfaden einmal testen, indem eine Kollegin oder ein Kollege interviewt wird, wie es die GOV.UK-Anleitung empfiehlt; Fragen streichen, die suggestiv, verwirrend oder mit Ja/Nein beantwortbar sind.
4. In der Sitzung: einfach beginnen und dann der teilnehmenden Person folgen, nicht der Reihenfolge des Leitfadens. Mit "erzählen Sie mehr davon", "was geschah dann", "warum war das wichtig" nachfragen. Das Produkt nicht erklären, nicht verteidigen und nicht fragen, ob eine noch nicht existierende Funktion genutzt würde.
5. Die mitschreibende Person hält Beobachtungen und wörtliche Zitate fest, getrennt von Interpretationen gekennzeichnet.
6. Innerhalb eines Tages nachbesprechen: Jede beobachtende Person schreibt die drei Dinge auf, die sie überrascht haben; danach werden diese zu einer Liste beobachteter Probleme zusammengeführt, jeweils mit dem stützenden Zitat.
7. Nach allen Sitzungen die Probleme nach Häufigkeit und Schweregrad gruppieren und festhalten, was weiterhin unbekannt bleibt. Das Ergebnis fliesst, versehen mit der Anzahl Teilnehmender, in Abnahmekriterien oder eine Umsetzungsentscheidung ein.

Erwartetes Ergebnis

Eine kurze, belegte Liste von Problemen und Workarounds, der Entwickler und Product Owner zustimmen, sowie ein Leitfaden, der für die nächste Runde wiederverwendet werden kann.

Grenzen und Prüfbasis

Interviews erfassen berichtetes Verhalten; NN/g nennt fehlerhafte Erinnerung, fehlende Details und Verzerrung durch sozial erwünschtes Antworten als Grenzen und empfiehlt, Interviews durch Beobachtung und Verhaltensdaten zu ergänzen. Suggestive Fragen machen die Daten unbrauchbar. Kleine Stichproben finden Probleme, nicht deren Häufigkeit. Das Protokoll ist aus den zitierten Quellen zusammengestellt; es wird kein Ergebnis behauptet.