Agile UX: User Research in agile Prozesse integrieren

Zum Thema Agile UX gibt es hier im Blog bereits einige Beiträge, sowohl von mir als auch von anderen Autoren. Bei diesen liegt der Fokus allerdings eher auf allgemeinen Grundsätzen und Strategien für die Integration von UX, insbesondere Design, in agile Prozesse. Speziell der User Research stellt im agilen Umfeld aber häufig eine Herausforderung dar.

User Research ist ein zentraler Aspekt von UX, und fällt trotzdem als erstes hintenüber in der agilen Produktentwicklung. Durch das konstante Streben nach einem lauffähigen Produkt wird User Research leider häufig als zu zeitaufwändig gesehen. Während es ohne Design kein Produkt gibt, geht es prinzipiell auch ohne Research. Zum Verhängnis wird dies erst später.

Gleichwohl ist es absolut möglich, auch in agilen Projekten User Research zu betreiben. Dies Bedarf jedoch einem festen Platz im Prozess und vorausschauender Planung. An vielen Stellen gibt es Chancen, schneller zu werden und direktere Ergebnisse zu erzielen. Je nach Methode kann die Durchführung dabei innerhalb oder außerhalb der normalen Sprints erfolgen. Kritische Erfolgsfaktoren sind neben der Methodik aber auch das richtige Team und die Aufbereitung und Kommunikation der Ergebnisse.

Kurzfristig: Design Research in den Sprints

Meist geht es beim User Research um die Evaluation von mehr oder weniger ausgereiften Designs. Solcher Design Research kann relativ kurzfristig und mit kurzer Vorlaufzeit durchgeführt werden. Folgende Methoden sind besonders geeignet:

  • Für sehr kleine und spontane Tests sind automatisierte Remote-Tests eine kostengünstige Möglichkeit. Ergebnisse sind bereits nach wenigen Tagen vorhaben. Schwierigkeiten gibt es dabei aber mit erklärungsbedürftigen Prototypen und speziellen Zielgruppen.
  • Moderierte Usability-Tests können ebenfalls innerhalb von Sprints durchgeführt werden. Da die Rekrutierung aber etwas Vorlauf braucht, ist es am sinnvollsten, feste und regelmäßige Termine für die Tests zu definieren – etwa alle 2 Sprints. Auf diese Weise gibt es keine Ausreden: Es wird getestet was zum Termin da ist. Dies können Wireframes und Prototypen sein, aber gerade in agilen Projekten gibt es auch häufig bereits lauffähigen Code, der etwa von einem Entwicklungsserver aus aufgerufen werden kann.
  • Für diese, aber auch andere Methoden kann es sinnvoll sein, ein kleines Panel von Probanden zu organisieren, aus dem mit kurzer Vorlaufzeit rekrutiert werden kann. So lassen sich auch sehr spontane Vorhaben wie eine Umfrage schnell realisieren.
  • Am Sprintende gibt es meist eine Demo mit Stakeholdern. Auch wenn es keinen richtigen Usability-Test ersetzt, kann diese doch für Design Research genutzt werden. Anstatt die Stakeholder durch die Anwendung zu führen, können sie diese anhand von Test-Aufgaben selber ausprobieren. Dabei gibt es dann auch nützliches Feedback zur Usability.
  • Für besonders schnelle Fortschritte im Design von Prototypen eignet sich die RITE-Methode (Rapid Iterative Design and Evaluation). Dabei wird nicht bis zum Ende des Usability-Tests gewartet, um Verbesserungen vorzunehmen. Stattdessen werden sofort, wenn Probleme eindeutig identifiziert wurden, Lösungen gesucht und der Prototyp angepasst. So steht am Ende der Tests eine ausgereifte und bereits erneut getestete Version. Eine ähnliche Vorgehensweise habe ich auch schon in meinem Beitrag „Really Rapid Prototyping“ beschrieben.

Langfristig: Grundlegender User Research außerhalb der Sprints

Unabhängig von konkreten Designs sollten in agilen Projekten aber auch weitere Methoden zum Einsatz kommen, um etwa Anforderungen oder allgemeine Nutzungsweisen zu ermitteln und so das Design zu informieren. Dazu gehören etwa:

Zwar können auch diese Methoden schneller und agiler duchgeführt werden als dies häufig gemacht wird, doch um einen gewissen Aufwand kommt man dabei nicht herum. Aus diesem Grund ist es meist nicht möglich, sie innerhalb eines Sprints anzuwenden. Gerade zur Anforderungsermittlung werden sie deshalb häufig als Teil des Sprint Zero eingesetzt. Eine Alternative während laufender Sprints ist, den Researcher teilweise aus dem agilen Prozess herauszunehmen. Er arbeitet also nur Teilzeit im Agile-Team und sonst losgelöst vom Sprint-Timing an umfangreicherem User Research.

Das richtige Team für Agile User Research

Durch die teilweise Herauslösung des User Researchers aus dem Agile-Team wird eine gleichzeitige Arbeit als Designer jedoch stark erschwert. Die Stärke eines UX-Designers in agiler Entwicklung entsteht nicht zuletzt aus direkter Erreichbarkeit und intensiver Kommunikation mit den Entwicklern. User Research erfordert häufig eine fokussierte Arbeit über längere Zeit, die sich nur schlecht dauernd unterbrechen lässt.

Aus diesem Grund macht ab einem gewissen Umfang des User Research die personelle Trennung von UX-Designer und User Researcher Sinn und wird sogar erforderlich. Häufiger als Designer werden Researcher nicht nur einem agilen Entwicklungsteam zugeordnet, sondern betreuen mehrere gleichzeitig in Teilzeit. Natürlich lässt sich nicht verleugnen, dass die Trennung von Design und Research mehr Kommunikation erfordert – somit sollten solche Lösungen immer ausprobiert und individuell abgewogen werden.

Leichter als im Bereich Design kann User Research alternativ auch extern abgegeben werden. Besonders geeignet ist dies eben für längerfristige Forschungsprojekte, die nur schlecht mit der Arbeit in Sprints zu vereinbaren sind. Dabei sollte aber darauf geachtet werden, die externe Agentur gut zu integrieren und von agilen Prinzipien nicht in alte Muster wie umfangreiche Reports zurückzufallen.

Ergebnisse effizient aufbereiten und kommunizieren

Die Durchführung des User Research ist die eine Sache, die Auswertung die andere. Tatsächlich gibt es in diesem Schritt das größte Potentzial, Zeit zu sparen, ohne dabei schlechtere Ergebnisse zu erzielen.

Grundsätzlich sollte den agilen Prinzipien nach Dokumentation minimiert und direkte Kommunikation bevorzugt werden. Dokumentation sollte nur der Kommunikation der eigentlichen Ergebnisse dienen und nicht als Ergebnis an sich.

Es empfiehlt sich, die Teammitglieder direkt in den Prozess der Analyse einzubeziehen, indem etwa direkt nach dem Testing ein gemeinsamer Workshop durchgeführt wird. So entfällt zeitraubende Dokumentation fast komplett, da alle bereits involviert sind und die Ergebnisse kennen.

Damit die Ergebnisse trotz aller Kommunikation nicht unbeachtet verpuffen, ist es unbedingt notwendig, sie möglichst schnell in User Stories zu überführen bzw. damit Einfluss auf bestehende User Stories zu nehmen. User Stories lenken die Produktentwicklung, so dass über diese der User Research seine Wirkung entfalten kann.

Ein Gedanke zu „Agile UX: User Research in agile Prozesse integrieren

  1. Pingback: Die Qual der Methodenwahl - Helfen Methodenmatrizen? - Usabilityblog.de

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *