Ein Designprozess kann Interviews beinhalten und Nutzer*innen am Ende trotzdem kaum Einfluss auf das Ergebnis lassen. Wenn die Roadmap schon vor Beginn der Recherche steht und der Release-Termin keinen Spielraum lässt, um auf Testergebnisse zu reagieren, wird Nutzerfeedback lediglich zu einer Liste von Problemen, mit denen das Team ohnehin schon leben will.
User-Centered Design verankert das Verständnis für Nutzer*innen, ihre Aufgaben und ihren Kontext fest in der Entwicklung und Bewertung von Produkten. Es ist eine Haltung zum gesamten Prozess, nicht nur ein einzelner Workshop oder eine Methode. Formell festgehalten ist dieser Ansatz in der ISO 9241-210 zu menschzentrierter Gestaltung interaktiver Systeme.
Erst die Aufgabe verstehen, dann die Lösung definieren
Nehmen wir einen fiktiven Terminplaner: Mitarbeitende wünschen sich vielleicht eine schnellere Möglichkeit, Termine zu verschieben. Bei der Recherche stellt sich jedoch heraus, dass die eigentliche Hürde in der Abstimmung mit Personen liegt, die keinen Zugriff auf denselben Kalender haben. Das Team muss immer noch eine Lösung gestalten – versteht die Aufgabe und ihre Rahmenbedingungen nun aber viel genauer.
User Research zeigt, wer beteiligt ist, welches Ziel erreicht werden soll und was die Arbeit erschwert. Dieses Verständnis lässt sich in Anforderungen und Evaluierungsziele übersetzen, die nah am ursprünglichen Problem bleiben. „Personen können einen Termin verschieben, ohne den abgestimmten Zeitraum zu verlieren“ hilft in der Praxis mehr als „der neue Kalender soll sich intuitiv anfühlen“.
Nutzer*innen müssen die Lösung nicht selbst erfinden, damit ein Prozess nutzerzentriert ist. Design-Teams steuern Alternativen und Fachwissen bei, während Research dabei hilft, die Annahmen dahinter fundiert zu hinterfragen.
Evaluierung muss das Design auch verändern dürfen
Erstellen Sie Prototypen mit genau dem Detaillierungsgrad, den Sie für die wichtigsten Fragen brauchen. Eine Skizze reicht oft schon, um Abläufe zu besprechen. Fragen zu Interaktion, Sprache oder Barrierefreiheit erfordern dagegen meist einen realistischeren Prototyp.
Nutzen Sie formative Forschung, um Schwierigkeiten aufzudecken und das Design zu überarbeiten. Planen Sie Zeit für eine weitere Runde ein, falls wesentliche Fragen offenbleiben. Spätere Evaluierungen können dann messen, wie gut die gesetzten Ziele erreicht werden. Der Prozess ist iterativ, weil neue Erkenntnisse oft dazu führen, die Aufgabe noch einmal neu zu durchdenken – und nicht nur die Farbe eines Buttons zu ändern.
Binden Sie die relevanten Fachbereiche direkt ein. Ein Problem verlangt oft nicht nur Anpassungen am Interface, sondern auch an Richtlinien, Supportprozessen oder Berechtigungen. Wer das gesamte Erlebnis nur als Folge von Screens betrachtet, lässt die eigentliche Hürde oft unberührt.
Kompromisse sichtbar machen
Verschiedene Nutzergruppen haben oft widersprüchliche Anforderungen. Admins wünschen sich vielleicht strengere Kontrollen, während Gelegenheitsnutzer*innen einen schnellen, unkomplizierten Weg brauchen. Research sollte solche Spannungsfelder offenlegen – statt eine durchschnittliche Person zu erfinden, deren Bedürfnisse zufällig genau zum Entwurf passen.
Wirtschaftliche und technische Rahmenbedingungen gelten weiterhin. Machen Sie transparent, wo eine Entscheidung einen Kompromiss bei einem erkannten Bedürfnis bedeutet, welche Folgen das hat und wie das Team das überprüft. Das ist deutlich ehrlicher, als das Endergebnis nur deshalb nutzerzentriert zu nennen, weil man mit Nutzer*innen gesprochen hat.
Beobachten Sie auch nach dem Launch, ob das Produkt im echten Nutzungskontext wie gedacht funktioniert. Baseline-Metriken, gezielte User Research und Feedback zeigen, wo das Design nachjustiert werden muss, wenn sich das Angebot und seine Zielgruppe weiterentwickeln.