Agile Research sorgt dafür, dass ein Produktteam kontinuierlich mit Nutzer:innen in Kontakt bleibt, während sich das Produkt weiterentwickelt. Dadurch wird Research zu einem festen Bestandteil von Planung, Design und Delivery. Anstehende Entscheidungen können sich so auf gezielt dafür erhobene Insights stützen – statt auf alte Reports zu nur vage ähnlichen Themen.
Der Begriff „agile“ beschreibt, wie die Arbeit organisiert ist. Er schreibt weder eine bestimmte Research-Methode noch eine universelle Stichprobengröße vor – und auch nicht, dass jede Studie zwingend in einen Sprint passen muss.
Von anstehenden Entscheidungen her denken
Ein sinnvoller Research-Plan unterscheidet zwischen Fragen zur aktuellen Nutzungserfahrung und Unsicherheiten, die weiter in der Zukunft liegen. Vielleicht muss das Team diese Woche überarbeitete Kontoberechtigungen testen, während es im kommenden Monat untersucht, wie größere Organisationen neue Software freigeben. Beide Aktivitäten zahlen auf die Delivery ein, laufen aber auf ganz unterschiedlichen Zeitschienen.
Der Bericht des Government Digital Service über Research in agilen Teams hebt hervor, wie wichtig regelmäßige Research-Aktivitäten parallel zu unmittelbaren und strategischen Fragestellungen sind. Das verhindert eine zu enge Routine, in der jede Studie nur den nächsten Screen bewertet, während niemand die grundlegenden Annahmen hinter dem gesamten Service hinterfragt.
Verknüpfe jede Studie mit einer konkreten Entscheidung und kläre, wer die Ergebnisse braucht. Ein kurzer Usability-Test kann eine gezielte Interaktionsfrage klären. Einen langwierigen Beschaffungsprozess zu verstehen, erfordert hingegen vielleicht Interviews mit mehreren Rollen, Zugang zu Dokumenten und einfach mehr Zeit. Diese Untersuchung in handhabbare Einheiten aufzuteilen, ist absolut sinnvoll – so zu tun, als sei die Frage kleiner geworden, ist es nicht.
Strukturen schaffen, die Research wiederholbar machen
Regelmäßige Studien fallen deutlich leichter, wenn Recruiting, Consent, Terminierung und Analyse in festen Händen liegen. Die Struktur eines bestehenden Interview-Leitfadens oder eine erprobte Einladung wiederzuverwenden, spart Zeit bei der Vorbereitung, ohne den Inhalt jeder Studie starr vorzugeben.
Entscheide je nach Art der Unsicherheit zwischen moderierten und unmoderierten Formaten. Aufgezeichnete Tasks eignen sich gut für eigenständige Interaktionstests. Bei unvertrauten oder sensiblen Themen braucht es dagegen oft eine:n Researcher:in, der/die zuhört und gezielt nachhaken kann. Ballparks Recruiting-Tools unterstützen bei der Teilnehmergewinnung, doch wer genau teilnehmen soll und welche Zielgruppen abgedeckt werden müssen, muss für die jeweilige Studie weiterhin klar definiert werden.
Plane ausreichend Puffer zwischen einem Insight und der Entscheidung ein, die er beeinflussen soll. Eine pünktlich abgeschlossene Session nützt wenig, wenn die Analyse erst eintrifft, sobald sich an der Umsetzung kaum noch etwas ändern lässt.
Unsicherheiten während der Arbeit sichtbar machen
Teile genug Evidenz, damit Kolleg:innen die Erkenntnisse nachvollziehen können – einschließlich der Frage, bei wem und unter welchen Bedingungen ein Problem aufgetreten ist. Eine kurze Aufnahme kann ein konkretes Problem anschaulich machen, sollte aber nicht als alleiniges Argument für weitreichende Schlüsse herhalten.
Mache offene Fragen parallel zur Delivery sichtbar. Manche rechtfertigen eine weitere kleine Runde iterative Research, andere verlangen nach einer größeren Untersuchung. Agile Research funktioniert dann, wenn das Team seine Pläne flexibel an diese Unterschiede anpassen kann – statt sich vom Sprint-Kalender diktieren zu lassen, wie viel Erkenntnisgewinn gerade erlaubt ist.