Research-basiertes UX-Design
...und die praktische Anwendung in agilen Entwicklungsprozessen
"Wie stellen wir die Daten zur Performance auf dem Dashboard am besten dar?" – "Frag UX."
So oder so ähnlich haben Sie das vielleicht bereits erlebt. Die einzelnen Elemente und Inhalte dieses kurzen Dialogs können beliebig ausgetauscht werden. Egal, ob es um Datenvisualisierung, die Darstellung von Call-to-Actions oder die Bezeichnung der Funktionen geht – UX wird hinzugezogen, wenn es um das Frontend geht. Das ist grundsätzlich gut so. UX muss und wird dann schon wissen, wie die Lösung aussehen soll, um eine positive Erfahrung für die Anwender sicherzustellen. In dem Beispiel wollen alle Beteiligten nur das Beste, und doch ist es irgendwie nicht richtig.
Geht es in diesem Beitrag um User-Interface-Design?
Nein. Es geht um mehr. Es geht um (Software-)Produkte und deren Schnittstelle zu Anwender:innen – und das schließt neben dem visuellen UI-Design auch konzeptionelle Themen mit ein. Beispielsweise die Anordnung von Elementen, die Reihenfolge von Prozessschritten, den grundsätzlichen Funktionsumfang, die textliche Beschreibung der Funktionen, die Performance und daraus resultierende "erlebte" Ladezeiten, etc. All diese Faktoren und Entscheidungen beeinflussen das Erlebnis der Anwender:innen. Dennoch gilt: Die Schnittstelle als solche ist nur eine Seite der Medaille.
User Experience ist keine Eigenschaft einer Software.
Die User Experience entsteht bei den Anwender:innen – und zwar vor, während und nach der Nutzung der Software. Das heißt also, dass Faktoren wie die persönliche Vorerfahrung das mentale Modell, Einstellungen und Werte, Emotionen und individuelle Entscheidungsprozesse die Experience beeinflussen. Um eine herausragende UX zu gewährleisten, müssen wir beides – das technische System (inkl. Frontend) und die Anwender:rinnen – kennen und verstehen.
Braucht Software eine herausragende User Experience?
Ja. Für den langfristigen Erfolg einer Software/ eines digitalen Produkts ist eine herausragende UX unverzichtbar geworden. Das gilt branchen- und zielgruppenübergreifend, im B2C- und B2B-Geschäft. Im B2B/Enterprise-Umfeld wird auch heute noch argumentiert: "Wir brauchen nur wenig UX, die Anwender:innen müssen das Tool sowieso nutzen" oder "die Einkaufsentscheidung tragen nicht die Anwender:innen, sondern die Einkäufer:innen. Und deren Anforderungen müssen implementiert werden".
Dieses Mindset birgt mittel- und langfristig enorme Risiken. Professionelle Software-Anwender:innen (z. B. von ERP-, CRM-, PIM-, CAD-, HR-, SCM-Software) sind zwar
- oft Heavy- und Frequent-User,
- oft spezialisiert auf ihren fachlichen Bereich und
- durch organisatorische Rahmenbedingungen erstmal zur Nutzung gezwungen,
aber: All die Profi-Anwender:innen sind außerhalb der Arbeitszeit mehr oder weniger 08/15-B2C-Anwender:innen. Sie genießen bequemes Online-Shopping, die intuitive Benutzung am Smartphone oder die sprachgesteuerte Smart-Home-Nutzung. Und diese Erfahrungen beeinflussen und verändern die mentalen Modelle der Anwender:innen. Diese Erfahrungen beeinflussen die Erwartungen und Anforderungen an Software und deren Schnittstellen und zwar unabhängig vom privaten oder geschäftlichen Kontext.
Reicht die Erwartung der Angestellten als Treiber für User Experience im B2B-Bereich?
Nein. Die Investition in eine bessere User-Experience lohnt sich – und zwar wirtschaftlich. Das ist aus zwei Perspektiven zu betrachten:
1. Aus Sicht des Unternehmens, das die Software anwendet. In diesem Unternehmen führt gute User Experience nachweislich zu:
- Einer effizienteren Arbeitsweise (z. B. durch eine schnellere Aufgabenbearbeitung) und folglich entsprechender Zeit-/Kostenersparnis.
- Höherer Mitarbeiterzufriedenheit und folglich geringerer Fluktuation und sinkenden Krankheits-/Ausfalltagen (mit allen positiven Folgen wie z. B. geringerem Recruiting-Aufwand, geringerem Know-how-Verlust, usw.).
- Positiven Effekten auf die Mitarbeitermotivation (z. B. durch motivierende Elemente/Abläufe, etc.)
- Qualitativ besseren Arbeitsergebnissen (z. B. durch geringere Fehlerraten und notwendige Korrektur-/Nachbearbeitungsaufwänden)
2. Aus Sicht des Unternehmens, das die Software entwickelt (das Unternehmen kann das gleiche sein, wie unter 1.). Für das Unternehmen führt eine gute User-Experience (bzw. eine nutzerzentrierte Produktentwicklung) zu:
- Kostenersparnis in der Softwareentwicklung. Durch frühzeitige Evaluationen, z. B. durch UX-Tests können Probleme etc. aufgedeckt und mit geringem Entwicklungsaufwand korrigiert werden.
- Einer Steigerung des Umsatzes (s. die Vorteile aus Sicht des Anwender-Unternehmens aus 1.).
- Verbesserte Markenwahrnehmung, z. B. durch Weiterempfehlungsverhalten seitens der Anwender:innen und Kunden:innen.
Dass sich UX und die positiven Folgen lohnen, darüber sind sich die meisten CEOs, CDOs, CPOs, POs und UXler einig, wahrscheinlich sogar die meisten Entwickler:innen. Wo ist dann die Herausforderung ?
Zurück zur Ausgangssituation und "Frag UX"
In dem oben skizzierten Szenario besteht die Herausforderung nicht darin, dass Beteiligte UX nicht wollen oder den Mehrwert nicht verstehen. Das Kernproblem ist die angedeutete Erwartungshaltung hinsichtlich des Prozesses/des Weges, wie Software mit guter User-Experience entwickelt werden kann. Der Fragende erhofft sich von UX eine Antwort, eine Lösung für seine Gestaltungsherausforderung – und zwar eine eindeutige und konkrete. Das ist vollkommen nachvollziehbar. Produktteams brauchen Antworten bzgl. der Priorisierung der Features, der UI-Gestaltung, dem Einsatz von passenden Interaktionen, usw.
Und wer hat die Antwort? Wie so oft im Leben erwarten wir die Antwort von Fachleuten. Maurer:innen wissen um die notwendige Fundamenttiefe; Banker:innen die ideale Geldanlagestrategie und Jurist:innen, welches Gesetz wann Anwendung findet. Und was antwortet UX auf die Frage der besten Datenvisualisierung? "Kommt drauf an" oder "Kann ich pauschal nicht sagen".
Für das Produktteam oder die Entwickler:innen mag das nicht zufriedenstellend sein, dennoch ist es richtig so. UX soll und darf die Antwort – das Ziel – nicht pauschal kennen. UX kennt aber den Weg, zu der Antwort zu kommen. Gute User-Experience/ gutes Design entsteht nicht durch Antworten, sondern durch Fragen. Das Design und die getroffenen Entscheidungen dürfen weder meinungsabhängig von Einzelnen, noch zufallsabhängig sein. Es braucht einen systematischen, nachvollziehbaren und datengetriebenen Gestaltungsprozess, das sogenannte "research-basierte UX-Design".
Nur durch einen research-basierten UX-Design-Prozess können:
- Design-/Produktentscheidungen datenbasiert getroffen werden,
- Design und dessen Effekte/Performance messbar und dadurch steuerbar und beeinflussbar gemacht werden und
- Design nachvollziehbar und skalierbar gemacht werden.
Design wird bewusst nicht als Ergebnis oder Produkteigenschaft verstanden, sondern als ein kontinuierlicher Prozess. Dessen Wirken muss über das einzelne Produkt weit hinausgehen.
Human-centered Design – Prozess und Werkzeuge sind schon da
Letztlich ist research-basiertes UX-Design nichts Neues. Das Human-centered-Design-Framework (ISO 9241-210) definiert den Prozess schon lange.
Auch die notwendigen Methoden zur Involvierung der Anwender:innen in den Entwicklungsprozess sind bekannt (von Contextual Inquiries über Personas, Rapid Prototyping und UX-Tests). Bei genauerem Hinsehen wird erkenntlich, dass der Titel dieses Artikels "Research-basiertes UX-Design" eigentlich eine Tautologie ist – UX-Design ist per Definition schon research-basiert.
Die lehrbuchkonforme Anwendung des HCD ist im Dev-Alltag nicht trivial, zugegeben. Welcher PO kann schon drei Sprints warten, bis das UX-Team Research durchgeführt hat, um eine Produktentscheidung datenbasiert zu treffen? Die Integration eines systematischen research-basierten UX-Design-Prozesses in vorhandene Softwareentwicklungsprozesse – gerade in agile – ist die größte Herausforderung bei der Entwicklung von Software mit guter UX. Diese Integration muss fachmännisch durchgeführt und begleitet werden, sonst wird UX unhandlich und bremsend – und verschwindet wieder. Nutzer:innen werden dann doch nicht systematisch eingebunden und die positiven Effekte von UX bleiben aus.
Research-basiertes UX-Design in der (agilen) Praxis
Kein noch so ausführlicher Artikel kann das Rezept liefern, mit dem research-basiertes UX-Design garantiert erfolgreich in ein agil arbeitendes Team oder Unternehmen implementiert wird. Die Integration von UX in agile Teams und Prozesse (Lean UX) muss auf die Arbeitsweise, die Ziele, das Unternehmen und das Team abgestimmt sein. Nur so kann die nahtlose Verzahnung und der bestmögliche Output sichergestellt werden. Der wichtigste Erfolgsfaktor hierbei ist die strategisch feste Verankerung von "Menschzentrierung" oder research-basiertem UX-Design im Unternehmen und den Teams. Dazu braucht es eine gemeinsam entwickelte Produktstrategie und -vision. So können Designer, Entwickler, Product Owner etc. ihre Entscheidungen daran ausrichten und nutzerzentriert arbeiten.
Mindestens genauso erfolgsentscheidend ist die Fähigkeit, diese Vision stets kritisch zu hinterfragen. Neue Erkenntnisse aus User Research, neue Technologien und sich ändernde Rahmenbedingungen erfordern den Mut, die Vision an diese anzupassen. Darüberhinaus müssen einige Kernfragen gestellt werden:
- Team-Setup: Wird das UX-Team zentral, dezentral oder hybrid organisiert? Gibt es einen Head of UX / UX-Manager? An wen berichten UX-Designer? Wer kümmert sich um Stakeholder-Management?
- Prozesse: Wie werden Aufgaben organisiert und verteilt? Wie werden Aufgaben priorisiert? Wie sind Kommunikationsstränge ideal und effizient? Wie werden UX-Prozesse in das Unternehmen integriert (z.B. braucht es standardisierte Prozesse, um schnell valides Nutzerfeedback unternehmensweit zugänglich zu machen)?
- Know-how-Aufbau und -Transfer: Welche Fähigkeiten braucht das UX-Team? Inwiefern braucht es Spezialisten oder Generalisten? Bezüglich welcher Spezialisierungen (UX-Writing, UX-Research, UX-Architect, …)?
- Erkenntnis-/Wissensmanagement: Wie wird sichergestellt, dass Erkenntnisse langfristig und einfach nutzbar bereitgestellt werden (Research Ops)? Wie wird sichergestellt, dass Synergien (Erkenntnisse und UI-Komponenten/-Interakionen) produkt-/teamübergreifend genutzt werden?
- Verantwortungsbereich: Was ist die Aufgabe des UX-Teams? Wofür trägt es Verantwortung, wofür nicht? Welche Entscheidung darf es treffen oder beeinflussen?
- Erfolgsmessung: Wie kann der Erfolg/ die Leistung des UX-Teams messbar und kommunizierbar gemacht werden?
Diese Faktoren müssen bei der Integration von research-basiertem UX-Design in agile Teams und Prozesse berücksichtigt und zum Unternehmen passend umgesetzt bzw. definiert werden. Dann gelingt research-basiertes UX-Design.
Fazit
Am Ende wollen alle Beteiligten eigentlich dasselbe: ein möglichst gutes Produkt entwickeln. Dabei muss verstanden werden, dass UI-Design (durchgeführt in späten Phasen der Softwareentwicklung) das alleine nicht liefern kann. Es braucht einen systematischen, research-basierten UX-Design-Prozess. Ob der nun SCRUM, SAFe, Human-centered-Design, Design-Thinking oder Lean heißt, spielt keine Rolle. Die Kernfragen sind:
- Werden in den Entwicklungsprozess regelmäßig und von Anfang an Anwender:innen miteinbezogen?
- Und die dort gewonnenen Erkenntnisse in der (Weiter-)Entwicklung berücksichtigt?
Als abschließenden Gedankenanstoß teile ich vier Ausreden, warum man kein research-basiertes UX-Design durchführt. Und alle vier gelten nicht (mehr):
- Wir brauchen kein UX, die Nutzer:innen unserer B2B-Software sind am Anschaffungsprozess nicht beteiligt.
- Wir machen schon UX, wir haben UX-/UI-Designer und Personas.
- Wir können unsere User/Zielgruppe nicht miteinbeziehen, die sind zu speziell.
- Wir arbeiten agil und iterativ, der UX-Prozess bremst uns nur.
Viel Erfolg bei der Nutzerzentrierung.
