Vom Erleben zum Verstehen: wie eigener UX-Research hilft, bessere Produkte zu bauen

In Produktteams, die an digitalen Lösungen arbeiten, wird nach aktuellen Vorgehensmodellen gerne in den Problem- und Lösungsraum aufgeteilt, bzw. in Research und Design oder auch in Discovery und Delivery. Wie auch immer wir diese zwei Phasen nennen, es geht immer erst darum, zu begreifen, wie eine nutzergerechte Antwort auf Herausforderungen im Leben von Menschen aussehen könnte, bevor wir uns an deren Umsetzung machen. Erst “Build the right thing”, dann “Build the thing right”.

Auch wenn mit einem neuen Feature oder gar einem neuen Produkt auf der grünen Wiese gestartet wird, der Ruf nach schnell greifbaren Ergebnissen klingt oft lauter als das Bedürfnis, sich erst ein klares Bild zu schaffen über Nutzer*innen und deren Umfeldbedingungen. Das führt in unserer Erfahrung als Berater*innen öfter zur Tendenz, in puncto Problemraum abkürzen zu wollen. Ein ambitionierter Desktop-Research verspricht schnell verfügbare Erkenntnisse über Nutzergruppen und Arbeitskontexte, selbst ChatGPT weiß heute schon angeblich, wie in der Vertriebsabteilung eines deutschen DAX-Konzerns gearbeitet wird. Und zur Not wird auf eine halbwegs aktuelle Studie zurückgegriffen oder diese wird vielleicht selbst in Auftrag gegeben, damit das Team schneller und zielgerichtet am Produkt arbeiten kann. Kaum jemand verlässt das Gebäude und bezieht Nutzer*innen außerhalb der eigenen Unternehmens- oder Projektblase mit ein, die extern erhobenen Erkenntnisse werden als Executive Summary in Confluence abgelegt. Check.

Ich möchte im Folgenden ein paar Gründe nennen, warum es eine gute Idee ist, sich als Produktteam selbst für Forschungsaktivitäten am echten Menschen in Verantwortung zu bringen. Wo liegt der Unterschied zwischen eigenem Erfahrungswissen und einer extern erhobenen Studie? Wie lässt sich Research als Team überhaupt etablieren und wie lassen sich Aufwände in einem vertretbaren Rahmen halten? Hier kommen ein paar Vorschläge.

Realitäts-Check

Stellen wir uns den Geschäftsführer eines mittelständischen Unternehmens vor, dessen Mitarbeiter*innen u. a. Solaranlagen auf Gebäudedächern installieren. Dazu nutzen die Installateur*innen eine inhouse entwickelte App, um Standorte zu planen, Installationsschritte zu verfolgen und die Leistungsmerkmale der Anlage zu überprüfen. Gerade auf den letzten Punkt legt unser Geschäftsführer viel Wert, auf die Themen Leistung und Diagnose setzt er große Hoffnungen und priorisiert diese beständig in den entsprechenden Meetings. Hinweise seitens des Produktmanagements, dass es beachtliche Usability-Probleme in der Anwendung gibt, werden kleingeredet. Die App lässt sich im Chefbüro auf dem Laptop neuester Generation testen, übertragen auf den 75-Zoll-Smart-TV-Monitor, der gegenüber der Couch steht. Auf den ersten Blick sieht alles schick aus. Überspitzt gesagt haben die Installateur*innen ja immer was zu meckern, nur in den neuen (und monetarisierbaren) Features spielt die Musik, so die Meinung.

Zusehen, ohne Eingreifen zu dürfen

Nun stellen wir uns vor, ein findiger Produktmanager hat es geschafft, das Budget für einen kleinen Live-Test der Applikation vor Ort mit drei Installateur*innen frei zu machen und lädt den Geschäftsführer ein, diesem Test remote in seinem Büro beizuwohnen, allerdings ohne eingreifen oder mit den Proband*innen kommunizieren zu können. Die Stimmung ist angespannt, wir sehen eine Bildschirmübertragung vom 10-Zoll-Baustellen-Tablet des Installateurs, auf dem die App läuft. Dabei filmt eine an der Jacke angebrachte mobile Kamera das Gesicht und nimmt gleichzeitig den Ton. Der Installateur soll nach Plan bestimmte Wartungsschritte an einer Anlage vor Ort durchführen und diese in der App dokumentieren. Dabei kämpft er mit Wind und leichtem Regen, seine touchfähigen Handschuhe reagieren auf dem Tablet wegen der Nässe nicht ganz zuverlässig und das verfügbare Funknetz am Einsatzort sorgt immer wieder für Wartezeiten beim Laden der Software. 

Ein derartiger Wartungseinsatz kann bei Idealbedingungen schon in etwa 20 Minuten erledigt werden. In unserem Fall kämpft der Installateur, der bereits seit 15 Minuten auf dem Hausdach steht, immer noch mit Bedienelementen der App. Ein leicht zu verhindernder Fehlklick hat ihn aus dem Kontext seiner Anlagenauswahl gerissen und er muss mühsam über eine Ausklapp-Navigation zurück zu seiner Wartungs-Checkliste zurückfinden. Die App lädt schleppend, eine Fehlermeldung poppt von unten auf den Bildschirm und verschwindet nach wenigen Sekunden wieder, so dass unser Proband den Inhalt nicht vollständig erfassen kann. Er musste nämlich gerade parallel einen Sicherungshaken überprüfen. Es wird geflucht, nicht nur auf dem Dach, auch im Chefbüro. 23 Minuten sind vergangen, der erste Checkpunkt ist dokumentiert. Am nächsten Arbeitsort dann wieder ein Fehlklick, der auf die Hilfeseite führt. Die kräftigen Finger des Installateurs haben den falschen von zwei eng zusammen stehenden Buttons erwischt, wir hören wieder Flüche über das Mikrofon und unser Proband steigt schlussendlich auf Papier und Kugelschreiber um für seine Dokumentation, die er später in der Applikation nachträgt, sobald er im Auto sitzt. So war das eigentlich nicht geplant.

Lösungen brauchen Erdung

Wir dürfen nun Wetten abschließen, ob der Geschäftsführer aus oben genanntem Beispiel im nächsten Priorisierungs-Meeting noch auf seine Leistungs- und Diagnose-Features setzt oder ob das Erlebte nicht auch bei ihm eine deutliche Veränderung in Denken und Handeln hervorgerufen hat.

Die Usability-Probleme der App standen vor dem Test schon im Raum, sie wurden mündlich immer wieder adressiert, aber erst das Erleben des Nutzungskontextes und das Mitfühlen der Schmerzen des Installateurs vor Ort veränderten die Diskussion nachhaltig. Und es ist nicht nur das empathische Teilhaben am reibungsvollen Arbeitsablauf, es wird auch aus einer rein geschäftlichen Perspektive deutlich, dass hier Effizienz und letztlich Geld verloren geht.

Es ließ sich nämlich nicht nur beobachten, dass der gesamte Wartungsvorgang mit mehr Aufwand verbunden war als gewohnt, am Ende fiel der Installateur auch auf ein früheres und für ihn praktikableres Verhalten zurück, nämlich die App erstmal komplett zu ignorieren. Die für das Unternehmen aufwändig entwickelte Lösung fühlte sich für den Nutzer auf dem Anlagendach eher hinderlich an. Ein bitteres Urteil, das aber von entscheidenden Stakeholder*innen erstmal gespürt werden wollte, bevor es die angemessene Dringlichkeit bekam. 

Reisen verändert

Ob es nun in einer Evaluation darum geht, wie Menschen mit der eigens entwickelten Lösung klarkommen oder um ein grundsätzliches Verständnis über die Welt bestimmter Nutzergruppen, die Erfahrungen sind am eindrücklichsten, wenn du dabei im übertragenen Sinne und auch wortwörtlich das Haus verlässt. Dabei ist es eben die Forschungsreise, die du selbst antrittst, die dich verändert. Sie ist geprägt von unzähligen und nachhaltigen Eindrücken, die bewusst und unterbewusst in dir arbeiten. Im Gegensatz dazu stellt der bloße Blick, beispielsweise auf eine Postkarte der Golden Gate Bridge, gespickt mit nackten Zahlen und Fakten, wahrscheinlich nicht viel mit dir an. Im Zweifel löst das Bild auch klischeehafte Vorannahmen aus, denen durch nichts widersprochen wird.

Das klingt vielleicht idealistisch in Anbetracht näher rückender Milestones und knapper Budgets im Projektalltag. Manchmal muss es aber im übertragenen Sinne gar nicht der Langstreckenflug des gesamten Teams für zwei Wochen nach San Francisco sein, um danach einen hochwertigen Fotoband rauszubringen. Manchmal reicht es, das eigene Gebäude zu verlassen, vielleicht sogar erstmal den eigenen Arbeitsplatz, um in eine andere Abteilung zu gehen und um sich bewusst mit Menschen und Situationen auseinanderzusetzen, die die eigenen mentalen Modelle herausfordern. Vielleicht stimmen ja bisher getroffene Annahmen gar nicht oder vielleicht gibt es Türen, die aufgehen, von denen du bisher noch nichts gewusst hast.

Begib dich dahin, wo deine Nutzer*innen sind

Als Produktverantwortliche*r solltest du zur Expert*in der Welt deiner Nutzer*innen werden. Es gilt, die Menschen, das Umfeld, die Arbeitsaufgaben, die Bedingungen und die Probleme bestmöglich zu verstehen und empathisch nachvollziehen zu können. Begib dich für kurze Zeit selbst auf die andere Seite, zu den Rezipient*innen deiner Lösung.

Entwickelst du mit deinem Team beispielsweise gerade eine App für Bahnreisende, solltet ihr euch vielleicht mal zum Bahnhof begeben. Ist es eine Lösung für Montagearbeiter*innen, solltet ihr die Luft von Fertigungshallen geschnuppert haben. Ist es eine neue Steuersoftware, sitzt ihr vielleicht bald in der Arbeitsecke eines heimischen Wohnzimmers. Der Methodenkoffer des menschzentrierten Designs beinhaltet an der Stelle ein sehr wirkungsvolles Werkzeug: die Contextual Inquiry, bzw. die kontextuelle Befragung, in der sich ganz viel vom Umfeld und einer möglichst realitätsnahen Nutzung mitnehmen lässt. Auch Usability Tests vorhandener Lösungen lassen sich möglichst nah am Lebens- oder Arbeitsalltag von Menschen durchführen. Die App aus dem Solaranlagen-Beispiel von weiter oben muss auf dem Dach stehend auf dem Bauarbeiter-Tablet des Installateurs funktionieren, nicht auf dem Smart-TV für den auf der Couch sitzenden Chef. Und wenn möglich, sollte sie dann auch auf dem Dach getestet werden und nicht im Büro.

Reiseplanung als Teamsport

Die Reise zu einem besseren Verständnis von Nutzer*innen ist bestenfalls eine Teamaktivität. Auch wenn es dedizierte Forscher*innen geben kann, hilft das Einbinden aller Teammitglieder und Stakeholder*innen über die klassische Rollenverteilung hinweg, die Erkenntnisse zu festigen und zu verinnerlichen. Sie können beispielsweise beobachtend oder als Note-Taker tätig werden und in der Vor- und Nachbereitung unterstützen.

Überhaupt liegt auch schon in der Planung und Vorbereitung von Research-Aktivitäten viel Lernpotenzial, und sei es nur über das eigene Unwissen. Wenn ihr im Team aktiv beispielsweise an der Formulierung eines Interview-Leitfadens arbeitet oder diskutiert, welche Aspekte in der Software ihr überprüfen wollt, lässt sich viel über gemeinsame Annahmen oder unterschiedliche Ansichten lernen. Und in der Auswertung und Einordnung des Erlebten können sich Erkenntnisse nochmal verdichten und schärfen.

Von der Reise erzählen kann nur, wer dabei war

Wenn möglich, solltet ihr keinen der genannten Schritte missen: Weder die gemeinsame Vorbereitung auf die Forschungsaktivitäten, noch die Durchführung, genauso wenig wie das spätere Einordnen und Verarbeiten. All das verändert euer Verständnis über Nutzer*innen nämlich nachhaltig. Und dieses Verständnis wirkt dann auch effizient weiter auf alle beteiligten Teammitglieder, die nicht mehr extra gebrieft und überzeugt werden müssen von dem, was ihr im Feld wahrgenommen habt.

Wenn ihr die Wissenserhebung komplett von außen liefern lasst, das Planen, Durchführen und Auswerten damit vollständig abgekürzt, lauft ihr nicht nur Gefahr, viel Subtext und unterschwellige Einflussfaktoren zu verpassen, mangels lebendigem Erleben etabliert sich das Wissen auch schlechter im Team. Im übertragenen Sinne verändert euch also nur das Reisen selbst, nicht die Postkarte. Für unseren Projektalltag heißt das: weniger Fokus auf das Ergebnis-Artefakt einer Studie, viel mehr Betonung auf das gemeinsame Erleben und Erarbeiten von Verständnis.

Ein Plädoyer für den Kontakt zu echten Menschen

Hier nochmal kurz zusammengefasst, welche Vorteile ihr als Team aus einem eigens durchgeführten Research ziehen könnt:

Zu tieferen Erkenntnissen gelangen

Bist du selbst im Feld unterwegs, spürst du feinsinniger mögliche Einflussfaktoren, kannst besser nachhaken oder weiterforschen an Punkten, die neugierig machen. Manchmal entdeckst du im Nutzungskontext Türen, die zu weiteren Türen führen und hinter denen dann unentdecktes Wissen schlummert.

Empathie bilden

Spürst du selbst die Schmerzpunkte im Alltag deiner Nutzer*innen oder kannst ein Stück weit teilhaben an Erlösungs- und Erfolgsmomenten, so kannst du dich auch besser in die betroffenen Menschen hineinfühlen. So sind sie für das gesamte Team Menschen aus Fleisch und Blut geworden, und nicht nur Rollenbeschreibungen in einem Textdokument. Jetzt lassen sich Lösungen sorgfältiger auf echte Bedürfnisse zuschneiden.

Eigene Annahmen hinterfragen

Im direkten Kontakt mit Menschen lassen sich ganz gezielt auch eigene Vorannahmen überprüfen und nachschärfen. Arbeitest du beispielsweise mit Personas, lässt sich dann auch wunderbar reflektieren, inwieweit ein menschliches Erlebnis sich in bestehende Konzepte einordnen lässt oder nicht. Wichtig dabei ist, möglichst diversifizierte Eindrücke zu sammeln und nicht immer mit denselben Menschen zu sprechen.

Team Ownership stärken

Ist das komplette Team selbst verantwortlich und aktiv im Nutzer*innen Kontakt, so formiert sich eine gemeinsame Sicht und damit auch ein gemeinsames Gefühl der Verantwortung gegenüber der eigenen Lösung. Steht dann zum Beispiel eine unangenehme Aufgabe an, wie beispielsweise das Redesign einer Hauptnavigation, geht das komplette Team eher mit, wenn alle aktiv erlebt haben, dass die alte Variante in der Welt der Zielnutzer*innen nicht funktioniert hat.

Effizienten Forschungsprozess etablieren

Gerade im B2B-Bereich kann es hilfreich sein, wenn du dir einen eigenen Pool an möglichen Proband*innen für Fragen oder Tests aufbaust und warm hältst. Ist dieser Kontakt dann etabliert, kannst du dann meist leichtgewichtig und kurzfristig auf diese Menschen zugreifen. Wenn Menschen perspektivisch von einer Lösung betroffen sind, ist die Bereitschaft erfahrungsgemäß recht hoch, sich an dem Gestaltungsprozess zu beteiligen, auch z. B. in Form von kollaborativen Design-Workshops.

Klarheit über das eigene Unwissen

Arbeitest du selbst aktiv an der Planung und Umsetzung der Research-Aktivität, machst du im Vorfeld das eigene Unwissen explizit. Was wissen wir im Team, wie sicher sind wir über diese Annahmen und wo muss noch Licht ins Dunkel bezogen auf das Verständnis unserer Nutzergruppen? Die Diskussion darüber ist sehr wertvoll und schärft wieder das gemeinsame Bild.

Passgenaue Lösungen entwickeln

Wenn das Produktteam selbst zu Expert*innen des Nutzungskontextes und der betroffenen Menschen geworden ist, richten sich viele kleine Entscheidungen im Projektalltag effizienter an diesem Verständnis aus. Die Lösungen, die für Nutzer*innen gebaut werden, sind von vornherein treffsicherer und nachhaltiger, wenn das Team stetig Glaubenssätze in greifbares Wissen umwandelt.

Wann setze ich Unterstützung von außen ein?

Nach diesem beherzten Aufruf, das Erleben und Lernen über den Nutzungskontext möglichst in eigenen Händen zu halten, kann es selbstverständlich hilfreich sein, sich in bestimmten Fällen doch von außen unterstützen zu lassen. Die Bitte an der Stelle wäre wiederum, trotz des Outsourcings von Wissenserhebung, aktiv im eigenen Forschungsinteresse zu bleiben und die extern generierten Insights wieder möglichst lebendig in den eigenen Wissensschatz und ins Team zurück zu transportieren. 

Das gilt natürlich auch, wenn ihr eure hauseigene UX Abteilung schon klar in die Gewerke Design und Research aufgeteilt habt. Umso besser, hier könnt ihr euch als Designer*innen noch stärker involvieren und den Wissenstransfer mit den forschenden Kolleg*innen aktiv gestalten.    

Gründe für einen ausgelagerten Prozess können zum Beispiel sein, wenn größer angelegte Studien mit einer Vielzahl Proband*innen, vielleicht sogar sprach- und länderübergreifend, geplant sind und dabei alleine das Rekrutieren einen beachtlichen Aufwand darstellt. Eventuell fallen Einzelinterviews in andere Zeitzonen oder benötigen Muttersprachler*innen in der Moderation für eine saubere Durchführung. Einzelne Studien können aber auch technisch oder fachlich sehr spezifisch und anspruchsvoll werden und benötigen Unterstützung in einem Maße, dass es das eigene Team vollkommen überfordert. Hier gilt es, wie oben schon erwähnt, Ergebnisse, Erkenntnisse, aber auch Erlebnisse so aufzuarbeiten, dass daraus auch erlebtes Wissen für das Team wird. Gutes Storytelling hilft an dieser Stelle.

Menschzentrierung als kulturelle Haltung

Zwischen der groß angelegten Studie mit tausenden Proband*innen und dem anderen Extrem, nämlich der stur selbst-referenziellen Entwicklung, ohne den Blick nach außen zu richten, gibt es eine Vielzahl von wirksamen und handelbaren Methoden, die eigenen Ideen auf die Realität stoßen zu lassen. Wer will, kann auch einfach mal anfangen, mit Nutzer*innen zu reden, ohne Angst davor haben zu müssen, etwas falsch zu machen. Manchmal lohnt sich auch ein Vorgespräch mit der hauseigenen Vertriebs- oder Serviceabteilung und der Aufbau eines Friendly-Customer-Pools, bei denen sich milde gestimmte Unternehmen mit ausgewählten Mitarbeiter*innen bereit erklären, dauerhaft in den Kontakt zu treten, um eine Lösung zu evaluieren und damit weiterzuentwickeln. Ein erster Kontakt, so niederschwellig er auch sein mag, ist immer besser als gar kein Kontakt. In diesem Handlungsfeld ist auch immer Raum, zu lernen und besser zu werden. Lies ein paar gute Bücher über Research Methoden oder lasst euch beratend unterstützen im richtigen Umgang mit User-Feedback. 

Testen muss nicht teuer sein

In der Praxis begegnen wir häufig dem Vorurteil, Usability Tests beispielsweise seien zeitlich und monetär recht aufwändig und damit eine Hürde im Entwicklungsprozess. Aber mit einem einmal sauber etablierten Setup und einer überschaubaren Vor- und Nachbereitungszeit lassen sich diese oft gut in den eigenen Räumen durchführen. Das trägt nicht nur kulturell zu einer sichtbar menschzentrierteren Haltung im Unternehmen bei, es macht ein Stück weit auch Spaß und kann als Teamevent Stakeholder*innen und aktive Teammitglieder zusammenbringen und lang etablierte Denkmuster über die eigene Kundschaft aufbrechen.

Wer sich diese Haltung zu Nutze machen kann, und dies nicht nur einmalig, sondern dauerhaft in seinem Vorgehen verankert, hat gute Chancen, eine lebendige Lernkultur zu etablieren und auch den Grad der gefühlten Selbstwirksamkeit im Team zu stärken. Und am Ende profitieren die Nutzer*innen, deren Schmerzen und Erfolgsmomente so näher an die Seele des Teams gerutscht sind. Ihre Bedürfnisse finden auf die Art sichtbar im Entwicklungsprozess Eingang und von zufriedenen Kund*innen profitiert letztlich auch das Business. 

Welche weiteren Vorteile dein Unternehmen aus dem Einsatz von UX ziehen kann und wie sich konkrete Zahlen berechnen lassen, findest du übrigens auch in meinem Artikel über den ROI von UX-Maßnahmen. Und auch über den richtigen Umgang mit User-Feedback habe ich mir ein paar Gedanken gemacht. Lies darüber gerne hier: Hör nicht (einfach) auf User-Feedback.