Blog

Continuous UX: Anne Hess & Thomas Immich im Interview

Thomas Immich

Anne Hess ist Researcherin am Fraunhofer-Institut für Experimentelles Software Engineering. Im Rahmen der Interview-Reihe UX Neu Überdacht sprechen sie und Thomas Immich im Outdoor Office über modernes Requirements Engineering und kreative Ansätze, wie man an reichhaltigere Informationen von Nutzer*innen kommt und welche Methoden aus fachfremden Disziplinen UX Professionals inspirieren und beflügeln können, besser zu werden.

Zum Weiterlesen gibt es hier ein Paper von Anne Hess zu spannenden, alternativen RE Ansätzen: Conspiracy Walls in Requirements Engineering – Analyzing Requirements like a Detective

Interview zu Continuous UX und Requirements Engineering

Anne: Woher kommen aus UX-Sicht Anforderungen, speziell Nutzeranforderungen bzw. User Requirements? Welche Erhebungstechniken werden eingesetzt, was funktioniert gut, was funktioniert nicht gut? Dazu haben wir verschiedenste Fragen, die wir in verschiedene Themenblöcke eingeordnet haben. Kannst du aus deiner Arbeit ein Projekt auswählen, anhand dessen wir diese Fragen diskutieren? Bestenfalls ein Projekt, bei dem die Anforderungen vom Kunden oder den Stakeholdern kamen und die dann in einer entsprechenden Lösung umgesetzt wurden. Dann würde ich gerne spezifischer auf die Rollen im Team eingehen, welches das Projekt umgesetzt hat.

Thomas: Ich nehme ein anonymes Projekt aus der Finanzbranche. Es handelt sich um ein UX Design Projekt mit einem Team von sechs Leuten bei Centigrade: ein User Researcher, zwei Frontend Engineers, ein Visual Designer, ein Concept Designer und ich in der Projektleitung. Dazu kam das Team auf Kundenseite.

Anne: Das waren dann auch die Rollen, mit denen du über das Projekt hinweg intensiv zusammengearbeitet hast?

Thomas: Genau. Wobei die Intensität der Zusammenarbeit allerdings eher von der Projektphase abhing, in der wir uns gerade befanden. Am liebsten hätte man immer alle Menschen zu jedem Zeitpunkt mit dabei. Aus wirtschaftlicher Sicht ist das aber nicht sinnvoll. Deswegen versuchen wir immer, eine effiziente Überlappung der verschiedenen Disziplinen hinzubekommen. Am Anfang, wenn das Produkt noch in der Discovery Phase steckt und stärker von den User Research Ergebnissen abhängt, überlappen User Research und Concept Design sehr stark und finden ihre Gemeinsamkeiten im Requirements Engineering. Wenn man innerhalb der Product Discovery Phase stärker ins Prototyping gehen kann, überlappen Concept Design und Visual Design. Und dann, wenn es in die Umsetzung geht und es von der Discovery eher in eine kontinuierliche Delivery übergeht, überlappen Visual Design und Software Engineering mit Concept Design. Wir versuchen also, den richtigen Staffelstab im richtigen Moment dem richtigen Kollegen zu bringen, damit dieser das nötige Wissen bekommt und seinerseits den Staffelstab wieder weiterträgt.

Thomas Anne Interview

Anne: Verstehe. Das heißt, du warst über alle Phasen hinweg als Product Owner involviert?

Thomas: Nein, nicht als Product Owner, sondern als UX Manager, da die Product Ownership oft beim Kunden liegt. Das heißt, wenn der Kunde es nicht explizit anders möchte, machen wir keine strategischen Vorgaben wie es ein PO oft tut, sondern fragen eher die Gegebenheiten ab, ordnen sie aus nutzer-zentrierter Sicht ein und unterstützen der Priorisierung. Wir möchten also nicht direkt vorgeben, welches Backlog-Item nach oben oder nach unten gehört, sondern auf Basis der User Research Erkenntnisse informierte Empfehlungen geben. Wir können natürlich argumentieren, warum wir glauben, dass eine gewisse Richtung für die Nutzer*innen sinnvoll ist, aber letztlich müssen wir alle uns immer die Frage stellen „Welche Geschäftsmehrwerte möchte das Unternehmen mittels UX aus strategischer Sicht erzielen?“ Beantworten kann diese Frage nur der Kunde selbst. Deswegen liegt die PO Rolle auch fast ausschließlich beim Kunden. Wir sehen die UX Manager Rolle also als eine begleitende, assistierende Rolle für den PO: Der UX Manager muss im Gegensatz zum PO darauf achten, dass die Gewerke ineinandergreifen, dass sie übergabefähig sind und dass sie auf echten User Research Erkenntnissen fußen. Das war also auch meine Rolle als UX Manager des angesprochenen Projektes.

Anne: Und gab es außer dem PO auf Kundenseite noch weitere Rollen, mit denen du interagiert hast?

Thomas: Ja, bei diesem speziellen Projekt waren das sogar sehr viele. Es gab neben dem PO noch eine dedizierte Projektleitung, um das Projekt zu steuern sowie Ressourcen und Budgets im Blick zu halten. Es gab zudem einen Domäne-Experten, manchmal auch „Subject Matter Expert“ oder „Business Analyst“ genannt, speziell für die Finanzbranche, ein kleines Assistenzteam aus Werkstudenten für User Needs und Marketingrecherche sowie einen Software Architekt, der die gesamte IT-Infrastruktur den Kunden wie seine eigene der Westentasche kannte.

Anne: Was waren die primären Quellen, aus denen ihr eure Anforderungen erhalten habt?

Thomas: Da es sich um ein großes Finanzinstitut gehandelt hat, gab es natürlich eine dedizierte Marketingabteilung, die vorab schon Marketing-Personas in Richtung Milieus und Generationen segmentiert hatten. Aber diese Art von Profilen, á la Millenials vs. Generation Y waren noch zu grob für die UX Arbeit.
Daher haben wir im Centigrade Team die User Research Aktivitäten geleitet, Interviews geführt, in Foren gestöbert und spezielle Recherchen beispielsweise in Nutzerforen gemacht. Wir haben uns zum Beispiel durchgelesen, wie sich unsere Zielgruppe darauf vorbereitet, wenn sie mit 18 Jahren zum ersten Mal geschäftsfähig wird. Diese und andere Schlüssel-Lebenssituationen haben wir uns tiefer angeschaut, um herauszufinden, wann welches Nutzererlebnis welche Zielgruppe am besten erreicht.
Es gab hierzu glücklicherweise auch viele Freiwillige in diesem Konzern, die gesagt haben, ich melde mich als potenzieller Kunde und erzähle dir aus meinem Leben.
Wir haben diesen Menschen viele lösungsunabhängige Fragen gestellt, wie z.B.: „Wie war das, als du volljährig geworden bist, als du dein erstes Konto hattest?“, „Was hat das mit dir gemacht, plötzlich mündig zu sein?“ und so weiter.

Anne: Das heißt, ihr habt die Ist-Situation untersucht und vom Kunden keine konkreten funktionalen Anforderungen bekommen?

Thomas: Genau, es geht bei der Anforderungsanalyse vor allem um die Beschreibung von Lebenssituationen in Form sogenannter Nutzungs-Szenarien. Eine beispielhafte Lebenssituation wäre z.B. die, dass gerade der Urlaub eines Pärchens mit Nachwuchs finanziert werden muss. Das Pärchen weiß noch nicht, wie viele Ausgaben es mit Kind zu erwarten hat. Das Pärchen kann also noch gar nicht kalkulieren, was es sich leisten kann. Es braucht eine andere Wohnung, ist aber noch zu jung, um kreditwürdig zu sein. Das ist eine der vielen beispielhafte Stellen, an denen neue CX oder UX Lösungen einen echten Mehrwert liefern können. Hinter der Verknüpfung der Themen Wohnung, Reise und Finanzierung verbirgt sich offensichtlich ein großes Potenzial, wenn es darum geht, als Finanzinstitut hilfreiche Unterstützung für die gesetzte Zielgruppe anzubieten.
Aus Nutzungsszenario haben wir anschließend sogenannte User Needs abgeleitet. Im Grunde sind das nicht-verifizierte Annahmen darüber, welche konkreten Nutzerbedürfnisse in verschiedenen Kontexten existieren.

Thomas Anne Interview

Anne: Habt ihr die User Needs mit den Nutzern validiert?

Thomas: Wir haben sie zunächst einmal mittels User Research nur verifiziert. Indem wir mit Nutzern ins Gespräch oder in die Beobachtung gehen, erhalten wir konkrete Hinweise darüber, ob es korrekt ist, was wir als Anforderung vermuten. Aus den informellen, unverifizierten User Needs als reine Annahmen werden durch die Verifizierung dann schließlich User Stories, also echte Nutzeranforderungen.

Anne: Und diese Verifizierung, macht das eine bestimmte Person und ihr habt euch dann ausgetauscht oder hat jeder ein wenig Research betrieben und ihr habt eure Erkenntnisse zusammengetragen?

Thomas: Es sind meistens zwei Personen, die in den User Research gehen. Wir möchten hier bewusst eine Überlappung von User Researcher und Concept Designer. Der User Researcher hat dann allerdings den Lead. In diesem Fall ist das eine Psychologin gewesen, die den Konzepter mit ins Boot genommen hat, so dass die beiden für die kurze Phase der Verifizierung ein kleines Team gebildet haben; der User Researcher schielt dabei etwas mehr auf den Problemraum, der Konzepter etwas mehr auf den Lösungsraum.
User Research ist für uns nämlich eine rein lesende Disziplin. Sie gestaltet nicht, sie stellt in Frage. Sie dreht Steine um. Sie schaut hinter die Kulissen, aber sie setzt keine Ideen in die Welt. Diese harte Trennung finde ich wichtig. So sehr ich mit Continuous UX anstrebe, dass alle Gewerke letztlich ineinanderfließen, am Ende des Tages sollte man nie das testen, was man selbst gestaltet hat. Deswegen bin ich da für eine Gewaltenteilung.

Anne: Die User Researcherin war eine Psychologin. Sind es bei euch immer Psychologen, die diese Tätigkeit machen? Was gibt es sonst noch für Ausbildungshintergründe?

Thomas: Ja, das ist bei uns fast ausschließlich so. Wenn es keine reinen Psychologen sind, dann handelt es sich zumindest um eine informatische Ausbildung mit Psychologie als Nebenfach, was zum Beispiel an der Uni Duisburg-Essen inzwischen Kognitionswissenschaften heißt. Dort bekommt man genug psychologischen Hintergrund, um im User Research effektiv zu sein.

Anne: Wurden trotz der tiefen Nutzeranalyse Kreativitätstechniken und Design Thinking in diesem Projekt angewendet? Wie wird so etwas typischerweise durchgeführt und wer ist dafür verantwortlich?

Thomas: Ja! Mit Eintreffen der ersten User Research Erkenntnisse, gehen wir in die Ideenphase über. Hier wiederum ist der Konzepter im Lead und triggert die kreativen Impulse. Allerdings beschränkt er sich auf den Problemraum, den der User Researcher vorgibt. Wir sehen Kreativität immer dann besonders lebendig, wenn der Raum, indem man sich bewegt, möglichst begrenzt ist und eben nicht, wenn er zu offen ist. Wir gehen mit etwa 3 User Stories in Ideation Workshops. Diese beschreiben vielleicht gerade mal 4 Minuten im Leben des Nutzers und trotzdem entzünden sie oft ein Feuerwerk an Ideen. Es sind alle Ideen erlaubt, allerdings nur wenn sie zum Kontext der ausgewählten User Stories passen. Wenn eine Idee technisch nicht umsetzbar ist, darf sie trotzdem rein. Der in diesem Fall zweifelnde Engineer, darf dann höchstens eine weitere Idee vorschlagen, die noch einfacher umsetzbar ist, aber nicht die ursprüngliche Idee zunichte machen. Software Engineers sind bei diesem Format also explizit erwünscht!

Anne: Ihr habt ja ein ganzes Portfolio an Techniken, um Anforderungen zu erheben. Wenn ein neues Projekt kommt, macht ihr am Anfang eine Planung, welche Methoden ihr benutzen wollt? Und wenn ja, was sind Faktoren, die diese Auswahl beeinflussen?

Thomas: Wir versuchen, die besten Methoden herauszupicken und immer wieder mit möglichst den gleichen Methoden zu arbeiten. Ich glaube nämlich, dass auch eine gute Methode ein schlechtes Ergebnis produziert, wenn dort keine Routine existiert. Das heißt, du kannst natürlich immer aus einem Blumenstrauß von Methoden auswählen, aber, wenn du die ausgewählten Methoden nicht ständig jeden Tag anwendest, dann bringen sie dir zwar vielleicht neue Inspiration, aber nicht diese professionelle Routine, um effektiv und effizient zu sein. Ein Visual Designer wird auch nicht auf die Idee kommen, ständig seine Design-Tools zu ändern. Es gibt Skills, die man sich immer wieder neu drauf schafft. Natürlich darf man nicht stehen bleiben und muss links und rechts am Wegesrand die Augen offenhalten. Aber man muss auch eine Routine mitbringen.

Anne: Was funktioniert bei euch in der Anforderungserhebung besonders gut?

Thomas: Ich glaube, was wir sehr gut schaffen ist, den Nutzungskontext hart einzugrenzen und „Scope Creep“ zu verhindern. Den User Research dazu nennen wir daher auch „Scoped User Research“, also User Research in begrenztem Umfang. Du kannst nämlich ganz leicht deinen User Research starten, in eine Maschinenhalle fahren und dort halb-erschlagen von 1.001 Eindrücken zurückkehren. Du kannst mit jeder Menge Nutzer*innen dort sprechen, aber so viele Notizbücher kannst du gar nicht füllen, wie du dort an Erkenntnissen mitnimmst. Und was machst du dann damit? Du oder deine Kolleg*innen bekommen das gar nicht verarbeitet.
Im Scoped User Research legen wir daher explizit vorher fest, was dasjenige Nutzungsszenario ist, welches den höchsten geschäftlichen Mehrwert verspricht. Wir legen vorher fest, welches unsere Schlüsselpersona und unsere wichtigsten User Needs sind und genau die schauen wir dann per Interview oder Beobachtung im Detail an. Klar erzählen die Nutzer*innen auch mal von anderen spannenden Sachen, aber wir versuchen, das weitestgehend für später zu parken bzw. als „Gefühl“ mitzunehmen, ohne uns eingängiger damit auseinanderzusetzen. Den Finger legen wir auf diejenigen Punkte, die durch das Nutzungsszenario vorgegeben sind. Und dieses Szenario ist immer sehr knackig formuliert, weswegen wir meistens mit einem Tag oder zwei super hinkommen.

Anne: Wo siehst du Probleme oder Herausforderungen in der Erhebung?

Thomas: Die größte Herausforderung beim Requirements Engineering besteht darin, Anforderungen so zu dokumentieren, dass jemand sie richtig versteht, der nicht von Anfang an dabei war. Da habe ich selbst noch nicht den „Sweet Spot“ gefunden. Was ist zu viel, was ist zu wenig Doku? Manchmal höre ich z.B. Software Engineers sagen, „Es interessiert mich nicht, was die Persona ist. Ich will nur wissen, was ich jetzt entwickeln soll.“ Da bin ich skeptisch, ob das eine gute Einstellung ist. Ich glaube, jeder in einem Frontend-nahen Entwicklungsteam muss UX denken wollen und hier muss man die Software Engineers dann ein Stück zu ihrem Glück zwingen, beispielsweise indem man sie zum Ideen-Workshop einlädt, an dem die Persona zu Beginn groß und breit vorgestellt wird. Das macht die Herausforderung hinten raus deutlich kleiner. Außerdem sind immer auch mal wieder Leute krank oder das Team erhält Zuwachs oder was auch immer. Und wie vermittelst du jetzt diesem Neuling in kurzer Zeit, was eigentlich das Problem ist, wenn du auf keinerlei Dokumentation zurückgreifen kannst. Das ist extrem schwer. Im Grunde haben wir bei Centigrade den Continuous UX Baukasten ja auch nur deshalb erfunden, damit wir trotz vieler externer Veränderungen, die eine Agentur immer wieder hat, also Kundengröße, Teamkonstellationen, UX Maturity, Agilitätsgrad usw. dennoch immer eine reproduzierbare Qualität liefern können. Ich glaube unser Erfolg bei verschiedensten Weltmarktführern sowie zahlreiche Designpreise zeigen, dass das eine wirklich gute Investition war.

Anne: Wir haben von Personas gehört, von Szenarien, User Needs, User Stories, aber auch die von dir im Rahmen von Continuous UX immer wieder genannten User Booklets fand ich spannend. Kannst du dazu mehr erzählen?

Thomas: Bei der User Booklet Methode geht es einzig darum, nutzerzentrierte Artefakte wie User Research Erkenntnisse, Konzeptideen oder Screen Mocks zwischen interdisziplinären Teammitgliedern möglichst schnell auszutauschen.
Denn: Das reine „Anforderungsdaten reinkippen“ machen viele. Viele kippen Daten in Confluence oder ein beliebiges anderes Wiki ein. Aber was passiert dann mit diesen Daten? Nichts, wenn der jeweils nächste sich nicht auch konsumieren kann. Daher reichen wir jeder User Story sukzessive mit nur den Informationen an, die in diesem Kontext relevant sind. Wir kippen nicht alle User Research Ergebnisse in den einen Ordner und alle Figma Prototypen in den anderen Ordner. Wir dokumentieren explizit immer nur diejenigen Artefakte, die für ein*e bestimmte*n Nutzer*in in einem bestimmten Nutzungskontext relevant sind. Jemand, der neu ins Team zustößt, kann so beispielsweise direkt von einer bestimmten Lösungsidee zurückspringen auf deren Ursprung und Motivation.

Zudem erzeugen wir aus unseren Anforderungsdaten automatisiert Poster und Geschichten, die andere schnell auf hoher Flugebene abholen. Wir erschaffen per Knopfdruck spannende Stakeholder Infografiken, die auf einen Blick verraten, welche Stakeholder Endnutzer und welche Kaufentscheider oder sogar beides sind. Wir nutzen dafür das Software Tool LeanScope, welches sich perfekt für Storytelling-basiertes Requirements Engineering sowie für die User Booklet Methode eignet.

Anne: Spielst du auch immer alles zurück, was sich während Projektretros ergibt?

Thomas: Natürlich! Man kann manchmal viel falsch machen, bis ein Projekt wirklich knallt. Das hat sich aber dann meistens abgezeichnet und es knallt dann so richtig. Man kann leider auch viel richtig machen und es knallt trotzdem! Daher ist es wichtig zu beobachten, was im Detail an einem Projekt gut funktioniert hat und was nicht. Und was davon ist generalisierbar und was davon ist einfach der Projektkonstellation anzurechnen.
Ich sehe den Continuous UX Baukasten wie ein versioniertes Produkt. Mit jedem Projekt kommt eine kleine Versionsnummer dazu und wir releasen unser neues Continuous UX Playbook. Und so entwickeln wir uns automatisch immer weiter und Continuous UX wird evolutionär besser mit jedem Tag.

Anne: Was ist denn die größte Herausforderung beim Umsetzen von Anforderungen?

Thomas: Die Königsdisziplin ist es, den Sprung zu schaffen vom Design ins Engineering. Es ist einfach unglaublich schwer, weil es sich gegenseitig so oft bedingt. Bringt man immer alle Software Engineers von Anfang an rein und dann sind sie plötzlich alle Designer? Oder bringt man die Designer am Anfang rein und die Engineers ein bisschen später, aber dann geht die Akzeptanz der Software Engineers flöten? Wir glauben daran, dass es gut ist Software Engineers früh zu involvieren und als Sparringspartner für die Designer zu sehen. Letztlich sage ich auch immer: Designer sind auch Entwickler, genau wie Engineers. So war es in der Videospiel Branche schon immer… und da komme ich her.

Anne: Ihr arbeitet hier räumlich eng zusammen. Wie läuft so die typische Kommunikation ab?

Thomas: Wir sehen kollaborative Workshops mit den Kunden als Pfeiler unseres Continuous UX Prozesses. Die sind unverschiebbar. Es geht los mit dem Scoping Workshop, dann gehen wir in den Ideation Workshop usw. Es gibt diese Workshops zur Synchronisierung zwischen Teams und die sind nach Möglichkeit face-to-face, funktionieren seit Corona aber auch wunderbar remote. Zwischen den einzelnen Workshops werden die Fachdisziplinen aktiv, schaffen ihre Artefakte und sammeln sie in den User Booklets. Die Workshops sind also kleine strukturgebende Stationen, und dazwischen ist auch mal Freestyle angesagt auf fachlicher Ebene. Aber es kommt eben immer kontinuierlich zu einem Austausch mit einem klar definierten Ziel. Das bringt alle Teammitglieder weiter und lasst sie zusammenwachsen statt in Silos zu denken.

 

Möchten Sie mehr zu unseren Leistungen, Produkten oder zu unserem UX-Prozess erfahren?
Wir sind gespannt auf Ihre Anfrage.

Client Relationship Manager
+49 681 959 3110

Bitte bestätigen Sie vor dem Versand Ihrer Anfrage über die obige Checkbox, dass wir Sie kontaktieren dürfen.