Nutzerzentrierung beginnt mit Misstrauen gegenüber der eigenen Idee

Nutzerzentrierung ist eines dieser Schlagwörter, bei denen in Projekten selten jemand widerspricht. Der Anspruch dahinter klingt schließlich selbstverständlich: Digitale Produkte sollen sich an den Menschen und ihren tatsächlichen Aufgaben orientieren. Kaum jemand würde offen sagen, lieber an ihnen vorbeizubauen.

Genau diese breite Zustimmung macht den Begriff so furchtbar bequem. Er passt auf Präsentationsfolien, in Ausschreibungen, in Produktstrategien und in fast jede gut gemeinte Diskussion über digitale Angebote. Offen bleibt dabei jedoch häufig, wie ein Team herausfindet, was Menschen wirklich brauchen, und welche Konsequenzen es aus diesen Erkenntnissen zieht.

Im Projektalltag wird dieser Anspruch konkret: Wen beziehen wir ein? Welche Annahmen überprüfen wir? Und was passiert, wenn Rückmeldungen unserer ersten Idee widersprechen?

Je länger ich an digitalen Produkten arbeite, desto wichtiger erscheint mir dabei ein unbequemer Gedanke: Unsere erste Idee kann plausibel sein und trotzdem an der Realität anderer Menschen vorbeigehen. Sie ist nicht zwingend schlecht, entsteht aber zwangsläufig aus unserer eigenen Perspektive.

Für mich beginnt Nutzerzentrierung deshalb weder mit möglichst viel Empathie noch mit einem Workshop voller bunter Zettel. Am Anfang steht ein professionelles Misstrauen gegenüber der eigenen Idee. Gemeint ist damit eine nüchterne Arbeitsdisziplin: Auch eine gute Idee muss überprüft werden, bevor sie sich allzu selbstverständlich richtig anfühlt.

Die eigene Perspektive ist nie neutral

Wir gestalten selten aus dem Nichts. Wir bringen Fachwissen mit, technische Erfahrung, persönliche Vorlieben, interne Begriffe, organisatorische Zwänge und manchmal auch eine ziemlich klare Vorstellung davon, wie Menschen sich verhalten sollten.

Menschen benutzen Software allerdings nicht so, wie wir es uns in der Konzeption wünschen. Sie tun das in Pausen zwischen zwei Terminen, auf kleinen Bildschirmen, mit unvollständigen Unterlagen, unter Zeitdruck oder mit schlechter Verbindung. Manche verwenden Assistenztechnologien oder haben schlicht andere Begriffe im Kopf als das Team.

Eine Oberfläche kann aus Sicht des Teams völlig logisch aufgebaut sein und für Nutzer:innen trotzdem verwirrend wirken. Ein Button kann technisch korrekt beschriftet sein und trotzdem nicht die Handlung auslösen, die Menschen erwarten. Ein Hilfetext kann fachlich sauber formuliert sein und genau in dem Moment fehlen, in dem jemand ihn braucht.

Solche Fehleinschätzungen sind normal und kein moralisches Versagen des Teams. Sie entstehen, weil die eigene Perspektive eben nicht neutral ist.

Barrierefreiheit macht diese Grenzen der eigenen Perspektive besonders sichtbar. Wer bei der Gestaltung nur an Mausbedienung, einen großen Bildschirm, gutes Sehvermögen und volle Konzentration denkt, legt ein sehr enges Nutzungsszenario zugrunde. Für Menschen mit Behinderungen ist Zugänglichkeit oft die Voraussetzung, ein digitales Angebot überhaupt nutzen zu können. Eine verlässliche Tastaturbedienung und verständliche Fehlermeldungen helfen auch in anderen Situationen. Die technischen, rechtlichen und praktischen Fragen dazu behandle ich ausführlicher in meinem Artikel Barrierefreiheit im Web: Vom Sonderfall zur besseren Nutzererfahrung.

Nutzerzentrierung nimmt solche blinden Flecken methodisch ernst.

Was Nutzerzentrierung fachlich meint

Fachlich ist Nutzerzentrierung eng mit User Experience und menschzentrierter Gestaltung verbunden. User Experience, meist als UX abgekürzt, bezeichnet die gesamte Erfahrung, die Menschen vor, während und nach der Nutzung eines Produkts, Services oder Prozesses machen. Menschzentrierte Gestaltung oder Human-Centered Design beschreibt die Arbeitsweise dahinter. Die ISO 9241-210 fasst sie in konkrete Prinzipien: Teams sollen Nutzer:innen, Aufgaben und Nutzungskontexte verstehen, Nutzer:innen im Entwicklungsprozess einbeziehen, Lösungen anhand echter Nutzung bewerten, iterativ arbeiten und die gesamte Nutzungserfahrung betrachten.

Entscheidend ist, wann die Perspektive der Nutzer:innen in die Arbeit einfließt. Ein Usability-Test kurz vor der Fertigstellung kann zeigen, wo eine bestehende Lösung hakt. Stellt sich dabei heraus, dass das Team die falsche Aufgabe löst, sind grundlegende Korrekturen zu diesem Zeitpunkt bereits aufwendig.

Nutzerzentrierung setzt deshalb früher an und verändert die Reihenfolge der Fragen: Welche Aufgabe versucht ein Mensch zu erledigen? In welcher Situation geschieht das? Welche Hürden gibt es dabei? Erst auf dieser Grundlage lässt sich entscheiden, welche Lösung wirklich hilft.

Wer nutzerzentriert gestaltet, prüft nicht nur, ob ein Interface verständlich ist. Ebenso wichtig ist, ob das richtige Problem gelöst wird, der Weg zum Ziel passt, die Sprache trägt und der Aufwand gerechtfertigt ist. Die Lösung muss auch dann funktionieren, wenn jemand müde, technisch unsicher oder schlecht vorbereitet ist.

Eine gute Nutzungserfahrung endet daher nicht bei einem auffindbaren Button. Menschen müssen ihr Ziel erreichen können, ohne unnötig über das System nachzudenken.

Empathie reicht nicht

Ich mag den Begriff Empathie in diesem Zusammenhang nur eingeschränkt. Empathie ist wichtig. Der Begriff klingt hier jedoch fast so, als müssten wir uns nur stark genug in Nutzer:innen hineinversetzen, um zu guten Entscheidungen zu kommen.

Überraschung: Das reicht nicht.

Wir können uns irren, auch wenn wir es gut meinen. Gerade bei digitalen Produkten überschätzen wir häufig, wie eindeutig unsere Begriffe sind, wie linear Menschen denken und wie viel Geduld sie für unsere interne Logik aufbringen. Gute Absichten verhindern keine schlechten Nutzungserfahrungen.

Deshalb braucht Nutzerzentrierung Belege. Dahinter müssen nicht immer große Studien oder wochenlange Forschung mit Nutzer:innen stehen. Entscheidend sind Einblicke in die tatsächliche Nutzung: Gespräche, Beobachtungen, Support-Rückfragen, Suchanfragen, Prototypen, kurze Tests oder Nutzungsdaten. Je nach Projekt werden diese Einblicke in einem kleinen, pragmatischen Rahmen oder umfassender und systematischer gewonnen.

Feedback ist dabei nicht dazu da, eine fast fertige Idee abzunicken. Es soll zeigen, wo unsere Annahmen nicht stimmen.

Die britische Verwaltung formuliert das in ihrem Service Manual sehr klar: Teams sollen das Problem verstehen, das Nutzer:innen lösen wollen, statt sich zu früh an eine bestimmte Lösung zu klammern. Das ist nicht nur für staatliche Services richtig. Es ist für fast jedes digitale Produkt eine hilfreiche Erinnerung.

Bedürfnisse sind keine Wunschliste

Ein Missverständnis begegnet mir immer wieder: Nutzerzentrierung werde so verstanden, als müsse man einfach bauen, was Nutzer:innen fordern.

Das wäre aber viel zu kurz gegriffen.

Wenn jemand sagt: „Ich brauche einen Excel-Export“, kann dahinter vieles stecken. Vielleicht muss die Person Daten mit einem anderen System abgleichen oder braucht eine Übersicht für die eigene Ablage. Vielleicht muss sie einer Berichtspflicht nachkommen, für die sich eine bessere Lösung finden ließe. Der Export kann tatsächlich die richtige Lösung sein, aber auch nur der naheliegendste Workaround, den die Person aus ihrer aktuellen Situation heraus beschreiben kann.

Ähnlich ist es mit Wünschen nach zusätzlichen Hinweisen, mehr Optionen oder weiteren Bestätigungsschritten. Sie können sinnvoll sein oder darauf hindeuten, dass der eigentliche Ablauf nicht klar genug ist.

Wer Nutzer:innen ernst nimmt, setzt daher nicht jede konkrete Wunschlösung um. Ein Wunsch ist zunächst ein Hinweis: Was versucht die Person zu erreichen? Wo entsteht Unsicherheit? Welche Einschränkung prägt die Situation? Welche Aufgabe steckt hinter der geäußerten Lösung?

Das ist auch der Punkt, an dem User Experience und Produktverantwortung zusammenkommen. Nutzerzentrierung nimmt Teams nicht die Entscheidung ab. Sie macht Entscheidungen besser begründbar.

Der Kontext entscheidet

Eine Funktion ist nicht einfach gut oder schlecht. Ihre Wirkung hängt vom Kontext ab.

Ein freundlicher Erfolgstext kann in einem Produkt sehr passend sein. Eine kleine Animation nach einem abgeschlossenen Vorgang kann Freude auslösen. Ein lockerer Ton kann ein digitales Erlebnis menschlicher machen. In vielen Situationen ist das genau richtig.

Und dann gibt es Situationen, in denen dieselbe Idee plötzlich falsch wirkt.

In einer Antragssoftware, an der mein Team arbeitet, gab es nach dem Absenden eines Antrags eine kleine Belohnung: freundliche Worte, einen klaren Abschluss, in manchen Konstellationen sogar virtuelles Konfetti. Technisch war das sauber umgesetzt. In Demos kam das gut an. Es war ein sympathischer Abschluss in einem sonst eher nüchternen Prozess.

Bis klar wurde, dass nicht jeder erfolgreiche Antrag ein Anlass zur Freude ist.

Spätestens bei der Beantragung einer Sterbeurkunde fühlt sich Konfetti nicht mehr charmant an. Die Komponente ist nicht an sich falsch, ignoriert in diesem Fall aber den emotionalen Kontext.

Das ist mein liebstes Beispiel dafür, warum Nutzerzentrierung mehr ist als Bedienbarkeit. Niemand scheitert an dieser Stelle technisch. Der Antrag ist abgeschickt. Der Prozess funktioniert. Und trotzdem ist die Nutzungserfahrung nicht stimmig.

Wir haben die Rückmeldung zum Anlass genommen, Texte und Verhalten neutraler und konfigurierbarer zu machen. Das war keine große Produktvision, aber die richtige Korrektur: den Kontext ernst nehmen, statt unsere Idee zu verteidigen.

Wenn Forschung nichts ändern darf, ist sie Dekoration

Nutzerzentrierung wird oft über Methoden sichtbar. Interviews, Tests, Prototypen und Nutzungsdaten geben Einblick in die tatsächliche Nutzung. Personas und Journey Maps helfen dabei, diese Erkenntnisse für die weitere Arbeit zu ordnen: Eine Persona bündelt Ziele, Aufgaben, Einschränkungen und Nutzungssituation einer typischen Nutzergruppe. Eine Journey Map zeichnet den Weg nach, den Menschen durch einen Prozess oder Service nehmen. Keine dieser Methoden ist Selbstzweck.

Entscheidend ist, ob die gewonnenen Erkenntnisse etwas verändern. Eine Persona kann sehr hübsch aussehen und trotzdem keine einzige Produktentscheidung beeinflussen. Ein Usability-Test kann professionell durchgeführt sein und am Ende in einer Ablage verschwinden. Ein Workshop kann viele Erkenntnisse produzieren und trotzdem an der Roadmap abprallen, weil die wichtigen Entscheidungen längst getroffen wurden. Dann bleibt Forschung mit Nutzer:innen Dekoration.

Die Folgen müssen nicht spektakulär sein. Vielleicht wird ein Begriff geändert, obwohl er intern beliebt ist. Ein Feature wird kleiner, weil sich die Aufgabe einfacher lösen lässt. Eine Idee wird nicht gebaut, weil sich kein tragfähiger Bedarf zeigt. Oder eine Kennzahl misst künftig nicht nur Klicks, sondern ob Menschen ihr Ziel erreichen.

In meinem Alltag helfen dafür ein paar einfache Fragen:

• Für wen genau ist diese Lösung gedacht?
• Welche Aufgabe versucht diese Person in diesem Moment zu erledigen?
• Was weiß sie nicht, was wir längst wissen?
• Woran würden wir erkennen, dass unsere Idee falsch ist?
• Was würden wir streichen, wenn es zwar schön ist, aber nicht hilft?

Diese Fragen sind schlicht, verändern aber unsere Diskussionen: weg vom persönlichen Geschmack, hin zu überprüfbaren Annahmen.

Die bessere Idee hält eine Prüfung aus

Das Misstrauen gegenüber der eigenen Idee ist kein Plädoyer gegen Intuition. Erfahrung, Fachwissen und gestalterische Qualität bleiben wichtig und sind die Essenz menschlicher Arbeit. Teams sollen nicht jede Entscheidung endlos relativieren.

Aber gute Ideen werden besser, wenn man sie der Realität aussetzt.

Ein früher Prototyp, der scheitert, ist kein Rückschritt. Er ist oft das Günstigste, was einem Projekt passieren kann. Ein verwirrter Blick im Test ist unangenehm, aber wertvoll. Eine Support-Mail kann mehr über ein Interface erzählen als drei interne Abstimmungen. Eine Funktion, die im falschen Kontext schief wirkt, weist auf eine präzisere Lösung hin.

Nutzerzentrierung ist deshalb für mich weniger ein freundliches Etikett als eine Arbeitsweise mit Konsequenzen. Sie zwingt uns, Annahmen sichtbar zu machen. Sie schützt uns davor, interne Logik mit echter Verständlichkeit zu verwechseln. Und sie erinnert daran, dass Menschen Produkte nicht in unseren Konzeptpapieren benutzen, sondern in ihrem Alltag.

Vielleicht ist das der wichtigste Punkt: Nutzerzentrierung heißt nicht, dass wir keine eigenen Ideen haben dürfen. Sie heißt nur, dass wir ihnen nicht zu früh glauben sollten.