Agile Softwareentwicklungsprozesse stellen neue Anforderungen an User Research Methoden. Insbesondere klassische User Research-Methoden wie Usability Testing oder Contexual Inquiry passen mit ihren Durchführungszeiten von 4-8 Wochen* nicht so recht in die kurzen Takte der agilen Entwicklung. (* Von dem Tag an dem der Bedarf nach User Research entsteht bis zu dem Tag an dem der Bericht vorliegt)
Dieser Umstand kann dann dazu führen, dass sich ein Entwicklungs- oder Projektteam dafür entscheidet Kunden oder Anwender einfach, schnell und pragmatisch selbst zu befragen anstatt ein solides methodisches Vorgehen mit Unterstützung von Fachexperten zu wählen. User Research wirkt für Manche auf den ersten Blick verführerisch einfach. “Ist doch nur Fragen.” sagte mal jemand zu mir.
Nun spricht aus meiner Sicht nichts dagegen, wenn Entwicklungsteams Anwender bzw. Kunden selbst in ihre Projekte einbeziehen. Gerade in agilen oder lean Entwicklungsprozessen ist es sogar sehr hilfreich, wenn das Entwicklungsteam möglichst direkt in User Research involviert ist, da sich dadurch Dokumentationsaufwände minimieren lassen und das Verständnis zum Kunden schneller reift. Die Entscheidung dafür sollte aber bewusst und in Kenntnisse der Vor- und Nachteile getroffen werden.
Aufwand
User Research besteht nicht nur aus Interviews allein – auch wenn das Interview der Teil ist, der einem sofort ins Auge springt. Der Aufwand verteilt sich meiner Erfahrung nach ungefähr wie folgt:
45% Auswertung, Bericht und Präsentation
35% Interview
10% Rekrutierung
10% Organisation
Der größte Teil des Aufwandes fließt also nicht in das Fragen, sondern in das nachgelagerte Analysieren, Interpretieren und Schlussfolgern. Ein Orientierungswert: 12 qualitative Interviews a 1 Stunde erzeugen bei User Research-Profis ca. 3-5 Tage Aufwand, um zuverlässige Ergebnisse abzuleiten und diese zumindest grundlegend zu dokumentieren.
Verlässlichkeit der Ergebnisse
Um verlässliche Erkenntnisse zu erzielen, müssen Interview und Auswertung hohen Anforderungen gerecht werden. Es muss unvoreingenommen gefragt werden. Die Testpersonen dürfen nicht beeinflusst werden – auch nicht durch unbewusste Interviewer-Effekte. Manche Fragen können nicht direkt gestellt werden. Beispielsweise liefern hypothetische Fragen, wie “Würden Sie diese Funktion nutzen, wenn sie in dieser Situation wären?”, oft falsche Antworten. User Research ist nicht einfach. Fragen so zu stellen, dass man zuverlässige und belastbare Ergebnisse erhält, erfordert Expertise und Erfahrung.
Frischer Blick
Ich habe noch Niemanden erlebt, der zu Themen, an denen er mit Herzblut arbeitet oder in die er stark involviert ist, unvoreingenommene Fragen stellen kann. Selbst ausgewiesene User Research-Experten fragen unbewusst suggestiv, wenn sie ihre eigene Arbeit evaluieren. Das Ergebnis sind dann Fragen, welche die Antwort schon ein stückweit vorgeben, wie z.B. “Finden sie es nicht auch gut, dass diese Funktion so gestaltet ist?”. Außerdem brauchen manche Erkenntnisse “dumme” Fragen, die Mitglieder eines Entwicklungsteams gar nicht mehr stellen können oder würden, weil sie sich einfach zu gut auskennen bzw. ein festes mentales Modell vom Entwicklungsgegenstand haben. Ein unbedarfter User Researcher kann diese “dummen” Fragen sehr wohl stellen und erhält in der Regel antworten, die wertvolle Einblicke in das mentale Modell der Anwender bieten.
Fazit
User Research als Entwicklungsteam selbst durchzuführen, ist dann sinnvoll, wenn das Team über die notwendige Expertise und die Zeit für alle notwendigen Teilschritte verfügt. Auch wenn es auf den ersten Blick den agilen Taktschlag behindert: Auch beim User Research ist die Verlässlichkeit der Ergebnisse wichtiger als Geschwindigkeit. Unzuverlässige Ergebnisse erzeugen zwar eine Scheinsicherheit, die unter Umständen aber nur bis zur Markteinführung des fertigen Produktes anhält.
Um die notwendige Entscheidungssicherheit zu erzeugen und trotzdem mit der agilen Entwicklungsgeschwindigkeit mithalten zu können, ist es ratsam modernere User Research Methoden wie z.B. Crowd Usability Testing, Communities oder Analytics einzusetzen.
