5 häufige Fehler bei agilem UX-Testing und wie sie vermieden werden können

Ineinandergreifende Zahnräder Agil ist „in“ – und das ist gar nicht abgedroschen gemeint. Wir beobachten, dass immer mehr Entwicklungsprozesse mit kürzeren Zyklen bzw. Sprints und unter Einbeziehung verschiedener Abteilungen und Zuständigkeiten durchgeführt werden. Zumindest gibt es den Wunsch, dies zu tun. Es funktioniert nicht immer nach dem gleichen Schema und manchmal ist es auch mehr Wunsch als Wirklichkeit. Aber immerhin wird im Zuge der Umstellung von Entwicklungsprozessen auch versucht, Usability und User Experience stärker in diese Prozesse zu integrieren. Nicht der eine große Test am Ende, sondern mehrere kleine, am besten in jeder Entwicklungsphase, sollen es sein. Doch auch hier gibt es neben zahlreichen Chancen auch einige Stolperfallen und Probleme.

Eine gute Anleitung, wann welche UX-Methoden in agilen Prozessen zum Einsatz kommen können, wurde in folgendem Beitrag hier im Blog gegeben: Agile UX: User Research in agile Prozesse integrieren. Doch so läuft es in der Realität leider nicht immer. Die fünf häufigsten Fehler, die meinen Beobachtungen und Recherchen nach gemacht werden, habe ich im Folgenden einmal zusammengefasst – inklusive Tipps dazu, wie sie vermieden werden können. Ergänzungen als Kommentare sind ausdrücklich erwünscht!

  1. Nutzer werden erst einbezogen, wenn „man was sieht“ -> Fehlende Anforderungsanalysen
    Häufig wird UX in agilen Prozessen in der Form eingebunden, dass die Vorgabe herrscht, in jedem Sprint muss getestet werden. Das führt zum einen in den Zugzwang, immer was zum Testen zu fabrizieren und zum anderen wird vergessen, dass eine vorgeschaltete Anforderungsanalyse unverzichtbar ist, um in die richtige Richtung zu entwickeln. Denn wenn am Anfang die Bedürfnisse der Nutzer oder gar der Nutzer selbst (in Form von Personas) nicht deutlich herausgestellt werden, fehlen ein klares Ziel und eine Kommunikationsgrundlage für die weitere Entwicklung. Dann kommen im schlimmsten Falle auch Ideen in die Tests, die nie mit Nutzern hinsichtlich ihrer Tauglichkeit oder Qualität bewertet wurden (womit ich auch gleichzeitig für ein konsequentes Ideenmanagement plädiere, was auf Nutzermeinungen basiert und nicht von Zielvorgaben oder Autoritäten beeinflusst wird). Dies führt dann unweigerlich dazu, dass Diskussionen und Meinungsverschiedenheiten auftreten, weil jeder meint die Bedürfnisse der Nutzer zu kennen oder im schlimmsten Fall aus der eigenen Sicht argumentiert. Solche Diskussionen halten auf und gefährden die Projektpläne bzw. Zielerreichung innerhalb eines Sprints. Mentale Modelle, Bedürfnisse und Anforderungen der Zielgruppen müssen daher erhoben werden, bevor die Entwicklung startet.

  2. „Agil“ wird gleichgesetzt mit „schnell“
    Schon häufiger habe ich Vorurteile oder Ängste in Bezug auf agile Vorgehensweisen gehört, die in Richtung „Hektik“ oder „Chaos“ gingen. Jedoch ist in meinen Augen die Erwartung, dass „agil“ heißt, alles ginge viel schneller, genauso falsch wie die scheinbar unvermeidbare Verursachung von Stress. Entwicklung, Kommunikation und schließlich auch User Research/Testing: Das alles braucht nun mal eine gewisse Zeit. Für manche Teams können strenge Scrum-Prozesse bzw. feste Iterationen sogar hinderlich sein und sie haben sich von solchen losgesagt. Dies ist aber in meinen Augen auch nicht der entscheidende Punkt. Viel wichtiger ist es, sich die wahren Benefits von Agilität bzw. agilem UX-Testing klar zu machen: Bessere Produkte, Einsparung von nachträglichen Änderungen sowie kreativere und effizient arbeitende Teams, um nur einige zu nennen.

    Agile Prozesse schaffen nicht unbedingt mehr Zeit für UX, aber sie können dem UCD-Gedanken einen anderen Stellenwert geben und sind daher eine Chance, UX-Methoden in Entwicklungsprozessen zu verankern.

    Die ersten beiden Punkte lassen sich auch sehr gut durch ein Zitat von Hoa Loranger zusammenfassen:

    „The Agile user-experience process is more than just being a thoughtful designer; you must first know the user and continually test your assumptions. Don’t allow user research to run away from you during the compressed timeline of the agile process.”


  3. Zu hohe Ansprüche an die zu testenden Entwürfe und Prototypen
    In interdisziplinären Teams hat jeder sein Spezialgebiet, ist also Experte in seinem Thema. Das ist auch gut so, denn dafür ist er ja dabei, erhält ein Mitspracherecht und wird gebraucht. Nun beobachte ich aber häufig eine gewisse Zeitnot innerhalb von Iterationen, die manchmal paradoxerweise durch UX-Tests noch verstärkt werden zu scheint. Doch warum ist das so, wenn man doch von Anfang an weiß, dass ein Test vorgesehen ist? Oft ist es ein gewisser Perfektionismus, der sich ausbreitet, wenn es darum geht, etwas darzustellen und es dem Nutzer vorzustellen. Der Prototyp soll auf einmal aussehen wie eine fertige Website, das Design soll das optimale Feeling vermitteln und die zu testende Funktion soll einwandfrei auf alle Eventualitäten Model eines Wireframes reagieren. Das kann daran liegen, dass jeder Experte natürlich weiß, wie es im Optimalfall aussähe/sich verhielte und natürlich theoretisch auch das Knowhow hat, es so umzusetzen. Hinzu kommt, dass man im Nutzertest nur ungern Bemerkungen hören möchte, die sich auf die Unfertigkeit des Prototypen beziehen. Jede Kritik des Probanden wird erst einmal persönlich genommen, wenn es die eigenen Arbeits(Zwischen-)ergebnisse betrifft – ganz natürlich! Jedoch sollte in den Teams eine gesunde Feedbackkultur und vor allem das Wissen vorherrschen, dass es nur um die jeweils definierten Fragestellungen geht. Alles andere kann ausgeblendet werden und sollte nicht dazu führen, dass beim nächsten Mal ein noch schickerer Prototyp abgeliefert wird. Denn sonst gerät man nicht nur in Zeitnot, es besteht sogar die Gefahr, dass man nur noch einzelne Funktionen fertigstellt und testet, das große Ganze aber zu schnell aus den Augen verliert. Und das wäre im Sinne der User Experience, die sich eben nicht nur auf die Nutzung im Moment bezieht, fatal. Weil dennoch nicht immer alles nach Plan laufen kann und auch bei angemessener Fidelity der Prototypen zeitliche Engpässe entstehen können, ist der folgende Punkt ebenso wichtig.

  4. Fehlende Priorisierung in den Sprints
    User Tests fallen in agilen Prozessen bzw. einzelnen Iterationen vor allem aus einem Grund hinten herunter: Zeit – was sonst. Das ist bedauerlich, zeigt aber nur, dass es nicht hoch genug priorisiert ist. Für andere Dinge ist ja schließlich auch Zeit. Die Lösung besteht also darin, dass andere Dinge prinzipiell die Chance haben, niedriger priorisiert zu werden als UX-Testing. Das heißt auch, dass vielleicht die Umsetzung oder Entwicklung einzelner Funktionen oder Teilbereiche einmal nicht fertiggestellt werden kann. Das Team sollte sich von Anfang an darüber klar werden, wie die Ziele in den Sprints definiert werden, welchen Stellenwert UX grundsätzlich hat und wie mit Problemen wie „das haben wir nicht mehr geschafft“, umgegangen wird. Dies verhindert Unmut und Fehler im weiteren Verlauf. Mit Fehlern sind in dem Fall natürlich auch unentdeckte Usability-Probleme gemeint.

  5. Keine Flexibilität in der Vorgehensweise
    Ein zentrales Learning aus den Einblicken in mehrere agil arbeitende Unternehmen ist, dass es nicht den einen Königsweg gibt. Es müssen die Prozesse stets an die individuell vorherrschenden Bedingungen und Anforderungen angepasst werden. Das kann bedeuten, dass UX-Testing immer erst einen Sprint nach der Entwicklung stattfindet. Oder dass der/die UXler immer schon bei der Planung des nächsten Sprints einbezogen werden, also quasi schon einen Sprint eher gefragt sind. Was auch immer man für sich für Regeln aufstellt, wichtig ist, dass sie nicht in Stein gemeißelt sind. Kritische Stimmen und Gegenvorschläge sollten gehört und geprüft werden. Denn die Anforderungen eines Teams können sich im Zeitverlauf oder auch von Projekt zu Projekt ändern. Hier ist es wichtig, nicht zu starr an einmal aufgestellten Regeln festzuhalten. Dies kann für das Ziel sogar hinderlich sein, wenn Zeitintervalle nicht auf alle Vorhaben passen oder Teams je nach Problemstellung vielleicht anders zusammengesetzt sein müssen.

Letztendlich gehört zu einer Verankerung von UX in Entwicklungsprozessen natürlich mehr als dass agil gehandelt wird. Allen, die intern noch überzeugen müssen, sei an dieser Stelle nochmal der Artikel von Paul Bryan ans Herz gelegt. Er liefert damit gleichzeitig ein sehr schönes Schlusswort für meinen Artikel, da auch ich nochmals darauf hinweisen möchte, dass es nicht den einen Weg gibt:

“A UX team can greatly extend its impact on the company it serves by developing a deeper understanding of the company’s business strategy, what its competitors are releasing in terms of user experience, and what behaviours are characteristic of its customers. The effort that it takes for a UX team to gain this understanding pays off when business leaders begin to view user experience as a key to long-term competitive advantage rather than a cost center.”

Weiterführende Links:

Portraitfoto: Elske Ludewig

Elske Ludewig

Principal UX-Consultant & Managing Partner

eresult GmbH

Bisher veröffentlichte Beiträge: 111

Ein Kommentar

Schreibe einen Kommentar

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