UX und Usability Research in agilen Teams

Eines der häufig genannten Argumente gegen UX und Usability Research sind zeitliche Einschränkungen. Gerade angesichts der Tatsache, dass immer mehr Teams bei der Produktentwicklung auf agile Methoden setzen, handelt es sich hier um ein Problem, welches es zu lösen gilt. Agile Ansätze sind so vielfältig, wie die Teams, die sie einsetzen. Grundlegend gilt jedoch, dass in regelmäßigen (kurzen) Abständen neue Versionen des Produktes entwickelt werden und in der Regel auch kurzfristig live gehen. Auf Änderungen des ursprünglichen Plans kann so flexibel – idealerweise direkt im nächsten Sprint- eingegangen werden.Während Methoden wie das Wasserfallmodell oder User Centered Design im Prozess Zeit für User Research und – Testing einplanen, geben agile Frameworks keinen speziellen Zeitpunkt für Forschung und Evaluation des Produkts vor. Die Herausforderung, die sich stellt, ist also, den oft als aufwändig und zeitfressend geltenden Prozess der Nutzer-Forschung und User-Tests in agile Produktentwicklung einzubringen.

Die Rolle des UXlers im Team

Aus Sicht der agil arbeitenden Teams ist das Problem folgendes: innerhalb eines Sprints kann ein Team, dessen Mitglieder untereinander abhängig sind, nur so schnell arbeiten wie derjenige, der im Prozess am Weitesten “hinterher hängt”. Tatsächlich liegt es aber in der Natur der Arbeit als UX Researcher, dass man nach dem Entwicklungsteam arbeitet. Schließlich sollen Weiterentwicklungen am Produkt evaluiert werden. Die Annahme, dass für den UXler erst Arbeit anfällt, wenn eine Entwicklung stattgefunden hat, ist logisch. So gehen die Teams davon aus, dass User Testing nach Ende eines Sprints durchgeführt wird und die Ergebnisse zusätzlich aufgrund von Erhebungs- und Auswertungsdauer auf sich warten lassen.


Ein Lösungsansatz für dieses Problem ist es, den UX-Researcher komplett aus dem Team zu lösen und “voraus sprinten” zu lassen. Allerdings können so nur für die Zukunft geplante Ideen oder höchstens Mockups und Wireframes getestet werden. Tatsächliche Entwicklungen, welche im Rahmen eines Sprints entstehen oder neue Features zu testen bleibt weiterhin schwierig. Hinzu kommt, dass so gewonnene Erkenntnisse unter Umständen veraltet sind, bevor sie in die tatsächliche Produktentwicklung einfließen können. Diese Vorgehensweise ist also eher ineffizient und in den meisten Fällen nicht zielführend. Vor allem da das entstehende Produkt nach wie vor gar nicht oder frühestens nach dem Fertigstellen einer vorläufigen Produktversion getestet wird.

Auslagern der Grundlagen und Zielgruppenforschung

Gewisse Teile der User Research können durchaus vor Beginn des ersten Sprints oder komplett losgelöst vom Projekt durchgeführt werden. Hierzu gehört beispielsweise das Erheben grundlegender Informationen und Charakteristika der Zielgruppe. Auch das Erstellen von Personas kann losgelöst von der eigentlichen Entwicklung stattfinden. Durch die Abgrenzung von den zeitlich beschränkten Sprints, bzw. das Vorverlagern der Forschung, sind die zeitlichen Begrenzungen weniger eng. Trotzdem liefern diese grundlegenden Informationen die Basis für die Entwicklung von Produkten, Features und Neuerungen. Natürlich sollte dieser Zweig der User Research nicht nach einmaliger Befragung oder Untersuchung als abgeschlossen angesehen werden. Auch diese Basisdaten veralten nach einiger Zeit. Zudem kann sich die Zusammensetzung sowie Bedürfnisse, Emotionen und Absichten der Zielgruppe immer ändern.

UX Research innerhalb der agilen Produktentwicklung: kleinere Tests häufiger durchführen

Wie bereits erwähnt gibt es auch Nutzertests, die innerhalb der Entwicklung – idealerweise während des Sprints – stattfinden müssen. Hierzu gehört das zeitnahe Klären aufkommender Fragen an die Nutzer, sowie das Testen neu entwickelter Funktionalitäten. Zu klären bleibt die Frage, wie der Prozess der Forschung maximal beschleunigt werden kann. Im Vergleich zum “klassischen” Ansatz (einen komplett funktionsfähigen Prototypen zu bauen und diesen nach Fertigstellung wochenlang auf alle Fragestellungen zu testen) ist die durchzuführende Forschung herunterzubrechen und auf die einzelnen Sprints zu verteilen.

Praktisch bedeutet das, dass die große Forschungsfrage nach der optimalen User Experience in möglichst überschaubare und klar definierte Pakete unterteilt wird. So werden die zu testenden Fragestellungen sehr klein und damit auch die benötigte Zeit minimal. Tatsächlich muss so wesentlich öfter getestet werden. Da die Entwicklung von Produkten in mehreren Sprints stattfindet, können die Summe der kleinen Tests allerdings gut verteilt werden. So kann innerhalb jedes Sprints die aktuell aufkommende Fragestellung geklärt oder kleine, neu entwickelte Funktionalitäten getestet werden. Getestet werden sollte idealerweise regelmäßig (etwa 2-wöchentlich) um anfallende Probleme sofort zu klären und zu vermeiden, dass ein “Forschungsstau” entsteht.

User Research passt sich so dem agilen Framework an und kann wieder sinnvoll in den Prozess der Produktentwicklung integriert werden. Die einzige Voraussetzung die gegeben sein sollte, ist, dass jedem Team ein UX Researcher zur Verfügung steht, der spontan reagieren kann.

Sie möchten die Usability Ihrer Produkte verbessern und haben Interesse daran, wie UX-Research am besten in Ihr Team integriert werden kann? Wir beraten Sie gerne!