Nenn es nicht UX Research

TL;DR: Es ist nicht entscheidend, ob wir ein Vorgehen UX Research, Customer Discovery oder anders nennen. Entscheidend ist, dass wir zunächst das Problem und das tatsächliche Verhalten von Menschen verstehen – bevor wir eine Lösung bauen und anschließend um Zustimmung bitten.

Eine bekannte neue Erkenntnis

Ich hatte einem Projektpartner das Buch The Mom Test von Rob Fitzpatrick empfohlen. Einige Zeit später kam er mit einer Erkenntnis daraus auf mich zu: Wir sollten die Bedürfnisse der Nutzer verstehen, bevor wir mit der Entwicklung beginnen.

Mein erster Gedanke war wenig überraschend:

Na klar. Das weiß ich doch schon lange.

Zum Glück blieb es nicht bei diesem Reflex. Viel stärker war meine Freude darüber, dass wir nun gemeinsam auf diese Erkenntnis zurückgreifen konnten.

Das Buch hatte etwas zugänglich gemacht, das ich aus dem UX-Bereich kannte und in meinem Berufsleben oft einzubringen versucht hatte: nicht die eigene Idee vorstellen und nach einer Bewertung fragen, sondern zunächst zuhören. Keine fertige Lösung verkaufen. Keine Vorteile hervorheben. Keine Überzeugungsarbeit leisten.

Erst einmal verstehen, was im Leben der Menschen tatsächlich passiert.

Gefällt Dir, was wir gebaut haben?

In vielen Softwareprojekten, die ich erlebt habe, war die Reihenfolge eine andere. Zuerst wurde entwickelt. Danach zeigte man das Ergebnis und fragte sinngemäß:

Haben wir das, was gewünscht war, richtig umgesetzt?

Solche Termine hatten oft den Charakter eines Schulterblicks. Entscheidungsbefugte Stakeholder prüften, ob ihre Anforderungen korrekt in Software übersetzt worden waren. Das ist eine legitime Frage.

Nur wussten wir häufig gar nicht, was die späteren Nutzenden tatsächlich brauchten. Sie waren vorher nicht oder nur sehr begrenzt eingebunden worden.

Damit konnten wir gut prüfen, ob eine bestellte Lösung richtig umgesetzt war. Wir konnten aber kaum noch offen untersuchen, ob wir überhaupt die richtige Lösung bestellten.

Das ist ein wichtiger Unterschied.

Sobald eine Anwendung bereits entwickelt wurde, verändert sich das Gespräch. Zeit, Geld und fachliche Entscheidungen sind in das Ergebnis geflossen. Die Frage „Ist das jetzt gut?“ klingt offen, trägt aber ein deutliches Wunschbild in sich.

Es wäre schon schön, wenn die Antwort Ja lautet.

Feedback in einem fast geschlossenen Lösungsraum

Ich konnte solche Prozesse gelegentlich aufweichen. Zwischen der ersten Anforderung und der fertigen Umsetzung entstanden Zwischenschritte. Ich sprach auch mit Endnutzenden und brachte ihre Perspektive in die weitere Entwicklung ein.

Der Lösungsraum war zu diesem Zeitpunkt allerdings oft schon weitgehend festgelegt. Nutzende waren mit etwas Existierendem konfrontiert, das sich noch anpassen, aber nicht mehr vollkommen offen hinterfragen ließ.

Gerade in Behörden oder stark regulierten Bereichen kann das nachvollziehbare Gründe haben. Entscheidungsbefugte Stakeholder müssen Regeln, Organisation, Budget und weitere Interessen berücksichtigen. Sie können zu dem Ergebnis kommen, dass eine bestehende Lösung beibehalten wird und sich die Nutzenden an bestimmte Abläufe gewöhnen müssen.

Auch die Nutzerperspektive ist nicht automatisch vollständig. Menschen kennen ihren Arbeitsbereich, ihre Ziele und ihre Hindernisse besonders gut. Sie kennen aber nicht zwangsläufig alle Bedingungen, unter denen eine übergreifende Lösung entstehen muss.

Das macht ihre Stimme nicht weniger wertvoll. Es bedeutet nur, dass Produktentwicklung verschiedene Perspektiven zusammenführen muss.

Der Doppelagent

Meine Rolle fühlte sich dabei häufig wie die eines Doppelagenten an.

Ich wollte beiden Seiten gerecht werden. Einerseits versuchte ich, die tatsächlichen Belange der Nutzenden zu verstehen. Andererseits musste ich diese Erkenntnisse gegenüber den entscheidungsbefugten Stakeholdern vertreten und so übersetzen, dass der nutzerfreundlichere Weg auch aus ihrer Perspektive sinnvoll erschien.

Das Herausfinden der Nutzerbedürfnisse war dabei nicht immer der schwierigste Teil. Anspruchsvoller war häufig, den Erkenntnissen im Entscheidungsprozess genügend Raum zu verschaffen.

Ich musste nicht nur sagen: „Die Nutzer wollen das anders.“ Ich musste erklären, warum eine Beobachtung relevant war, wie sie sich mit anderen Anforderungen verbinden ließ und weshalb ein veränderter Lösungsweg für das gesamte Vorhaben besser sein konnte.

UX war damit nicht nur Research oder Gestaltung. Es war auch Übersetzungsarbeit zwischen Menschen mit unterschiedlichen Ausschnitten der Wirklichkeit und unterschiedlich viel Entscheidungsmacht.

Alle finden UX wichtig

Kaum jemand sagt offen, UX sei unwichtig. Wenn man hundert Entwickler fragt, werden vermutlich sehr viele zustimmen, dass eine gute User Experience zum Produkt gehört.

Was genau darunter verstanden wird, ist eine andere Frage.

Oft wird UX stellvertretend mit Visual Design gleichgesetzt: schöne Buttons, stimmige Farben, eine aufgeräumte Oberfläche. All das kann Teil einer guten Erfahrung sein. Es beschreibt aber nicht den gesamten Prozess, mit dem Probleme, Bedürfnisse, Verhalten und Nutzungskontexte verstanden werden.

Der Begriff UX Research kann dabei selbst zur Hürde werden. Er klingt nach einer klar abgegrenzten Expertise mit eigenen Methoden, Regeln und Fachbegriffen. Das ist nicht grundsätzlich falsch. Ein professionelles UX-Vorgehen ist genauer definiert und umfasst mehr als ein paar gute Gespräche.

In der Zusammenarbeit kann daraus trotzdem ein Expertise-Mysterium entstehen. Niemand weiß genau, was gemeint ist, aber alle nicken zustimmend. Anschließend entstehen schöne Buttons und der grundlegende Ablauf bleibt derselbe.

Deshalb halte ich mich mit dem Fachbegriff manchmal lieber zurück.

Frag nicht nach Deiner Idee

The Mom Test umgeht diese Hürde. Das Buch kommt nicht mit der Forderung daher, zunächst eine neue Disziplin anzuerkennen. Es beginnt mit einem unmittelbar verständlichen Problem: Menschen geben höfliche, ungenaue oder wenig belastbare Antworten, wenn wir sie nach unserer eigenen Idee fragen.

Wer bereits etwas entwickelt hat, möchte leicht ein Review. Wer für seine Idee brennt, beginnt unbewusst einen Sales-Pitch. Man erklärt Vorteile, liefert Kontext und hilft dem Gegenüber dabei, die gewünschte Antwort zu geben.

Das Buch lenkt den Blick stattdessen auf bessere Kundengespräche und darauf, reale Probleme zu erkennen, ohne die eigene Lösung verkaufen zu müssen. Es geht um brauchbare Informationen statt um Komplimente – und darum, nicht viel Zeit mit unnötigen Features zu verschwenden.

Das ist nah an grundlegenden Gedanken aus UX Research, verwendet aber einen anderen Zugang. Praktisch, menschlich und ohne große begriffliche Eintrittshürde.

Man muss nicht sagen:

Akzeptiere zuerst, dass es so etwas wie UX Research gibt.

Man kann stattdessen fragen:

Wie gehst Du heute mit dieser Situation um?

Wenn der Prozess wichtiger ist als sein Name

Für mich zählt am Ende der Prozess mit seinem Ergebnis. Wir können ihn UX Research, Customer Discovery oder völlig anders nennen.

Das bedeutet nicht, dass Begriffe und etablierte Methoden wertlos wären. Sie helfen dabei, ein Vorgehen zu präzisieren, typische Fehler zu vermeiden und Erkenntnisse nachvollziehbar zu machen. Ein Fachgebiet sammelt Erfahrungen, die man nicht jedes Mal selbst neu entdecken muss.

Aber der Begriff muss nicht am Anfang stehen.

Wenn jemand durch ein zugängliches Buch versteht, warum offene Gespräche vor der Umsetzung wichtig sind, ist die entscheidende Grundlage bereits da. Darauf lassen sich später konkrete UX-Methoden aufbauen. Dann wirken sie nicht mehr wie zusätzlicher Prozess oder ein von außen auferlegtes Ritual. Sie helfen bei etwas, dessen Nutzen schon verstanden wurde.

Genau deshalb hat mich die Reaktion meines Projektpartners gefreut. Ich musste UX Research nicht verkaufen. Ich konnte an ein vorhandenes Verständnis anknüpfen und meine Erfahrung dort einbringen, wo sie praktisch weiterhalf.

Vielleicht brauchen gute Ideen manchmal nicht mehr Fachbegriffe, sondern einen besseren Zugang.

Nenn es nicht UX Research, wenn der Begriff im Weg steht.

Aber hör zu, bevor Du baust.