Bei evux bin ich als Beraterin in unterschiedlichsten Kontexten für eine bessere UX unterwegs. Ob eine Website mit Marketing Automation, eine Beratungsapplikation oder als dritte Meinung für die Umsetzung einer nutzerbezogenen Teststrategie, die Aufgabenfelder sind vielfältig wie die Branchen, in denen wir tätig sind.
Wenn ich ein Projekt als Externe mit einem Kunden starte, habe ich mit ihm bereits eine zum Teil gewaltige Reise hinter mir. Warum ist Nutzerzentrierung eine gute Projektphilosophie, warum löse ich mit dieser Philosophie seine Schwierigkeiten und bringe den Nutzen, den er eigentlich sucht? Der Kunde ist aber nicht oder nur selten direkter Projektmitarbeiter, und obwohl ich offenbar erfolgreich war, ihn unterstützen zu dürfen, kommt jetzt die echte Skepsis.
Ob Großunternehmen oder KMU, als User Researcher, User Experience Researcher, User Experience-Analysten (oder weitere Bezeichnungen) sind wir heute (noch) Menschen, deren Kompetenzen durch Projekte nicht zwingend ohne Weiteres verstanden werden. Mein Glück ist, dass ich gern als Projektleiterin eingesetzt werde und so den Takt für User-centered Design mindestens mitbestimme, d.h. Teststrategie (also nutzerinvolvierende Tests) und Projektvorgehen sind bereits der Philosophie untergeordnet.
Marktforscher oder User Researcher?
Wenn die User Research nicht im Projektvorgehen verankert ist, entsteht gern – so beobachte ich das auch, wenn ich nicht die Führung habe – folgende Wahrnehmung: Die Fähigkeiten, Daten zu erheben (vom Contextual Inquiry bis zum Nutzertest oder Survey) und auszuwerten, stellt uns in die Marktforschung.
Wie nehme ich gemeinhin Marktforschung als Projektleiter wahr? «Wenn ich etwas wissen will, beauftrage ich die Marktforschung. Die machen dann ihrerseits ein Marktforschungsprojekt, das sie selbst managen.» Gut, klingt problemlos, ich bin nicht Teil des Ganzen, die informieren mich und ich mach dann was mit den Informationen oder nicht, mein Entscheid als Projektleiter.
In meiner Praxis habe ich aber konkrete Umsetzungsprojekte noch nie gesehen, die sich durch eine Marktforschung in eine andere Richtung gedreht haben. Denn wenn wir dabei sind, eine App zu entwerfen, eine Website neu zu konzipieren oder eine Software auszubauen, sind traditionelle Marktforschungsaufgaben (Marktdiagnose, Marktprognose und Marktkontrolle) nicht mehr oder noch nicht gefragt. In der Zeit dazwischen habe ich meine Ruhe als Projektleiter, alles unter Kontrolle.
Wenn in diese Wahrnehmung ein User Researcher eingepflanzt wird, hat er bitte die Aufgabe, die vorherrschende Meinung, oft die des Projektleiters oder des Auftraggebers, zu belegen und die anderen Projektmitarbeiter nicht von der eigentlichen Arbeit abzuhalten. Weit gefehlt, das wird er oder sie nicht tun, hoffentlich.
Hier stehen Nutzerbedürfnisse im Vordergrund: die Nutzer verstehen, die Nutzer modellieren (Personas z.B.), Probleme aufdecken, Hypothesen über Nutzerverhalten bilden und widerlegen und intensiv und ständig dazu beitragen, das entstehende Artefakt zu verbessern, das sind die wesentlichen Aufgaben, mit denen Projekte rechnen dürfen. Und das geht jeden Projektmitarbeiter an!
Um den Einsatz von User Research näher zu beleuchten, möchte ich euch anhand von 3 Geschichten auf Strategien aufmerksam machen, die vielleicht eure Perspektive ändern.
Strategie 1: User Research als In-house-Projekt
Bei dieser Strategie sind interne Experten unter sich. User Researcher finden sich als Einzelperson oder kleines Team, erhalten einen Research-Auftrag eines Projekts oder fachlichen Auftraggebers und legen los. Folgende Situation: Ein großes Fachprogramm mit >10 Einzelprojekten und genauso vielen Projektleitern beauftragt einen User Researcher, Customer Journeys für den interessierenden Fachprozess zu erstellen. Dies wird vorbildlich geplant, Interviews finden statt, Customer Journeys werden erstellt und analysiert, Pain Points erarbeitet und es entstehen «Beraterfolien» (das sind die Folien, die man wegen der Textmenge eher zum Lesen als zum Präsentieren verwendet).
Die Reaktion des Programms: «Projekt A und Projekt F, wenn euer Zeitplan es zulässt, macht doch bitte eine Impact-Analyse und berichtet in zwei Wochen, ob ihr die Erkenntnisse verarbeiten könnt.» Leider ist es schlecht gelaufen in diesen zwei Wochen: «Wir sind überzeugt, dass wir das bereits alles berücksichtigt haben.» Zerlegen wir die Geschichte in ihre Schritte:
Auftragsklärung: Mir stellen sich die Nackenhaare auf, wenn ich einen Auftrag erhalte, der da lautet, mach mal Fokusgruppen, mach mal Customer Journeys – in den häufigsten Fällen ist es die falsche Methode. Was am Anfang zählt, ist die Frage: Was will ich warum wissen, wen interessiert das und kann sich basierend auf den Ergebnissen überhaupt noch etwas ändern?
Aber die Nackenhaare legen sich auch gleich wieder hin, denn das muss unsere Aufgabe sein, den Fokus auf die Frage zu richten und den Methodenentscheid überzeugend zu vermitteln. In der Geschichte war die Methodenwahl völlig korrekt, aber die Stakeholder und ihre Dynamik, die Einstellung zu den möglichen Ergebnissen waren nicht wie gewünscht. Was kann man machen? Ich für meinen Teil versuche, so viele Betroffene wie möglich während der Erhebung einzubeziehen, z.B. für das Protokollführen.
Das geht aber nur mit strengem Briefing über Verhalten und Vorgehen beim Protokollieren und Debriefing der Schlussfolgerungen, damit klar ist, was eine valide Erkenntnis ist und was nicht. So werden Betroffene zu Beteiligten. Wie Reto in seinem Artikel schon einmal beschrieben hat: Es geht nicht um Show beim Einladen von Stakeholdern.
Damit sind wir bei der Durchführung: Transparenz schafft Verständnis. Wenn die Erhebungen keine Blackbox mehr sind, sondern klar ist, was dort passiert, ist das Nachvollziehen von Schlussfolgerungen viel leichter. Und der dritte Teil: die Ergebnispräsentation. Oft ist sie zu detailliert, die Problemfelder sind nicht priorisiert und das Projekt bleibt mit Problemen zurück, statt dass Lösungswege aufgezeigt werden.
Und das ist auch die Schwäche, wenn Design und Research streng getrennt werden.
Strategie 2: User Research konsequent extern
«Nirgendwo gilt ein Prophet weniger als in seiner Heimat, bei seinen Verwandten und in seiner eigenen Familie», das Phänomen hat schon die Bibel beschrieben. Wenn ein Projekt oder Programm entscheidet, User Research von extern zu beziehen, ist es so schlecht nicht beraten. Es gibt hierbei zwei Wege, die von Projektleitern, Product Owners oder Scrum Masters neue Skills verlangen:
- Weg 1: Situativ beauftragen, d.h. die Research-Strategie selbst festlegen und die Interventionen im Projektplan vorsehen.
- Weg 2: Die gesamte Research-Strategie auslagern.
Weg 1: Situative Beauftragung
Weg 1 verlangt von Projektverantwortlichen gute Kenntnisse und Erfahrungen, wann sich welche nutzerbezogenen Fragen stellen. Mit einigen Faustregeln ist man auch gewappnet, ein Gefühl dafür zu entwickeln, wann es Zeit wird, Nutzer anzuhören.
- Was Nutzer am besten können, ist Feedback zu geben, etwas zu beurteilen, was sie sehen oder am besten gerade erlebt haben. Dafür muss das Projekt entsprechende Artefakte erzeugen, dass das möglich ist. Skizzen, Prototypen, was immer den Sachverhalt veranschaulicht, und das mit echtem Inhalt (also kein «Lorem ipsum»).
- Zuerst die Frage, dann die Methode: Wer die Frage gut formulieren kann, kann die Methodenempfehlung dann den Externen überlassen, weil das in der Fachkompetenz der User Researcher durchaus möglich ist.
- Wenn ihr diese Aussagen hört oder sogar selbst sagt, liebe Projektleiter, wird es dringend Zeit für Nutzerinterventionen:
- «Das haben wir schon immer so gemacht.»
- «Ich weiß genau, was der Kunde will.»
- «Irgendwie fühlt sich die Lösung nicht gut an.»
Bei diesen Aussagen handelt es sich um psychologische Phänomene, die sich aus der Zusammenarbeit und Arbeitsroutine ergeben, die sich hervorragend aufbrechen lassen, wenn z.B. Nutzertests oder Interviews einen frischen Input von außen einbringen. Einige Filmausschnitte aus den Nutzerinterventionen wirken dann wahre Wunder.
- Für Wasserfallprojekte: In jeder klassischen Projektphase (Definitionsphase, Entwurfsphase, Implementierungsphase, Testphase) sollte einmal der Nutzer zu Wort kommen. So lässt sich das Ganze auch planen und budgetieren. Das befriedigt zwar noch nicht das Bedürfnis, auch kleinere Fragestellungen zu prüfen, ist aber für eine Minimalteststrategie durchaus tauglich. Hierbei gilt auch: Die früheren Interventionen (z.B. Contextual Inquiry in der Definitionsphase) sind wichtiger als die späten (z.B. Nutzertest in der Testphase), denn sie sparen bares Geld.
- Agile Projekte schauen am besten auf Features. Ein Feature ist für mich eine Sammlung einzelner Funktionen, die z.T. eine Menge von User Stories oder sogar Epics zusammennimmt, z.B. «Registrierung für einen my-Account finden und durchführen», also ausreichend groß, um durch Nutzer beurteilbar zu sein. Die Funktionalität sollte schlicht eine zusammenhängende Geschichte erzählen können, dann ist das Testen sinnvoll. Zu solchen Tests werden wir auch gern gerufen. Da agile Projekte die Ergebnisse solcher Tests schnell konsumieren müssen, sind wir darauf eingestellt. Schade ist, wenn Tests durchgeführt werden und erst für den übernächsten Sprint die Ergebnisse vorliegen. Desto weniger kann ja umgesetzt oder berücksichtigt werden.
Weg 2: Gesamte Research-Strategie auslagern
Weg 2 ist deutlich einfacher für die Planung, belastet aber recht explizit das Projektbudget mit Cash-out. Die Diskussion über den ROI von solchen Interventionen muss dann oft geführt werden. «Kannst du uns das Konzept nicht ohne die Nutzertests offerieren?» höre ich zwar immer seltener, aber wenn, dann gibt es eine breite Erklärung hauptsächlich über die Kosten, die entstehen können (und werden!), wenn man den kleinen Test rausnimmt. Die gesamte Research-Strategie auszulagern, hat den Vorteil, dass die Researcher unbefangen sind.
Sie hat aber auch Nachteile: Um an der Planung des Projekts dranzubleiben und Verschiebungen nachvollziehen zu können, gibt es viel Abstimmungsüberhang. Zudem fehlen oft Hintergrundinformationen z.B. über kleinere Entscheide, was die Analysegüte beeinträchtigt. Wer diesen Weg geht, sollte immer versuchen, die Researcher z.B. an Jour-fixes zu beteiligen, auf dass die Reibungsverluste so gering wie möglich sind.
Strategie 3: User Research als integrierter Bestandteil der Projektmethodik
Eine angenehme Gegengeschichte zu meinem Customer Journey-Beispiel oben war ein Hallway-Test für eine Beratungsapplikation, also eine Applikation, die Kundenberater gemeinsam im Gespräch mit Kunden verwenden. Hier bin ich als Teil des Projekts unterwegs, zwar extern, aber nicht aus der Ferne, sondern vor Ort im Team. Wir hatten eine eher kleinere Frage, wie der Einstieg in die Produktdarstellung funktioniert und einige Versionen dazu entwickelt.
Zwei davon haben sich als qualifiziert für uns herausgestellt. Eine, weil sie sehr nah an der Idee des Produktmanagements war, und eine, die unsere (aus UX-Sicht) beste Hypothese war. Zum Test haben wir einen Produktmanager eingeladen, der einen Hintergrund als Berater hatte, eben die Beraterrolle zu übernehmen und mit uns den Test mit Laufkunden auf dem Gang durchzuführen. Als die beiden Varianten dann diskutiert wurden, hatten wir einen Fürsprecher aus den eigenen Reihen, der nicht vom Hörensagen berichtete, sondern vom Erleben. Er war dementsprechend glaubwürdig, und die für Kunden tauglichere Variante setzte sich durch.
So handeln konnte ich aber nur, weil ich Teil der Umgebung war. Ich kannte die internen Beeinflusser, der Test saß zu richtigen Zeit und der Entscheid für eine Variante konnte schnell genug gefällt werden, weil ich den Entscheid auch selbst vertreten muss. Als User Researcher habe ich mich in diesem Fall der Produktvision unterworfen, und ich teile das gemeinsame Ziel des Teams, das Beste für die Applikation herauszuholen.
Wenn User Research zur Projektmethodik gehört (also in agilen Projekten Teil des Refinements, eine Bedingung in der Definition of Ready o.ä.) und kein separates Projekt ist, fallen die schier endlosen Rechtfertigungsdiskussionen weg (die hatte man vor dem Start). Das Projekt ist schneller in der Lage, einen anderen Weg zu gehen, weil Research und Design und Umsetzung nicht «künstlich» getrennt sind.
Als Projektverantwortlicher kann ich mich dann noch entscheiden, ob ich eine User Research-Rolle im Team haben möchte oder nicht. In meiner kleinen Welt ist User Research eine Projektaufgabe und keine Rolle.
Mein schönster Moment in dieser Hinsicht war in einem Wasserfallprojekt, in dem ich seit ca. sieben Monaten bereits als Business-Analystin unterwegs war (und so alle Projektmitarbeiter das ganze Thema Befragen und Testen schon kannten). Ein Entwickler rief mich an: «Du, Susanne, in deiner Spez ist doch die Interaktion so und so beschrieben. Das kommt mir komisch vor.» «Ach so, warum denkst du?» «Das ist doch viel zu kompliziert. Ich würde ein anderes Pattern vorschlagen.» «Ok, lass es mich anschauen.» «Ja, ich schick dir auch noch einen Link auf die drei Videos, die wir mit den Mädels von der Buchhaltung gemacht haben.» «Hä? Steh ich aufm Schlauch? Was hat das damit zu tun?» «Na, wir haben sie das Durchklicken lassen.» Zutiefst beeindruckend, dass ich sogar ihre Vorgehensweise prüfen konnte! In der Nachfolgestunde entwickelten wir einige neue Ideen für das Thema und lösten ein Nutzerproblem. Business-Analyst, Interaction Designer und Entwickler.
Alles in allem: Abgrenzung bringt uns keine guten Produkte
User Research als integrierter Bestandteil der Projektmethodik ist mein präferierter Weg. Selbstredend lassen sich nicht alle nutzerzentrierten Erhebungs- und Evaluationsmethoden von Laien durchführen. Bei einigen können Team oder Stakeholder partizipieren (z.B. Personas). Bei manchen lässt sich zuschauen (z.B. Interviews), andere erlebt man und lernt sie sukzessive (z.B. Hallway-Test). Warum darf ein Software-Entwickler keinen Hallway-Test machen? Wunsch und Wille, den Nutzer und Kunden zu hören, lässt sich leicht vorleben. Liebe Projektleiter, ihr seid gefragt!