User Centered Design - So gelingen digitale Produkte wirklich

Digitale Produkte scheitern selten an fehlenden Funktionen, sondern daran, dass sie am Arbeitsalltag vorbeiplannt werden. Genau hier setzt user centered design an: Ich richte Anforderungen, Prototypen und Tests so aus, dass sie zu echten Aufgaben, Erwartungen und Grenzen der Nutzer passen. In diesem Artikel geht es darum, wie der Ansatz in der Software- und Webentwicklung praktisch funktioniert, welche Methoden wirklich helfen und warum Barrierefreiheit und Datenschutz dabei nicht als Zusatz, sondern als Teil der Lösung gedacht werden sollten.

Was nutzerzentrierte Gestaltung im IT-Alltag bedeutet

Ich trenne nutzerzentrierte Gestaltung bewusst von einem bloßen „Wir fragen mal kurz im Team nach“. Der Unterschied ist entscheidend: Entscheidungen beruhen nicht auf Geschmack, sondern auf beobachtbaren Aufgaben, Kontexten und Zielkonflikten. In einer Banking-App zählt nicht, ob eine Oberfläche modern wirkt, sondern ob Überweisungen, Freigaben und Warnhinweise unter Zeitdruck fehlerarm funktionieren.

Die ISO 9241-210 beschreibt diesen Ansatz als Entwicklung, die sich am Nutzungskontext orientiert und Lösungen immer wieder gegen reale Anforderungen prüft. Für mich heißt das: erst verstehen, dann formulieren, dann entwerfen, dann testen. Genau diese Schleife macht aus einer Idee ein belastbares digitales Produkt. Wer sie auslässt, spart Zeit nur scheinbar, denn die Korrekturen kommen später umso teurer zurück.

Im IT-Umfeld ist das besonders wichtig, weil Software nie isoliert existiert. Sie hängt an Fachlogik, Datenstrukturen, Rechten, Rollen, regulatorischen Vorgaben und oft an Legacy-Systemen. Wer diese Realität nicht mitdenkt, baut zwar eine schöne Oberfläche, aber keinen tragfähigen Arbeitsprozess. Wie die Schleife konkret aussieht, zeige ich im nächsten Schritt.

So läuft der Prozess in der Praxis ab

Der größte Fehler besteht darin, nutzerzentrierte Arbeit als einmalige UX-Phase zu behandeln. In der Praxis ist es ein wiederholbarer Prozess, der in klassische Projekte ebenso passt wie in Scrum oder Kanban. Ich arbeite dabei meist mit vier klaren Fragen: Wer nutzt das System, was wollen diese Menschen erreichen, wo scheitern sie heute, und woran erkenne ich, dass eine Lösung besser ist?

1. Nutzungskontext verstehen - Ich kläre Rollen, Aufgaben, Umgebung, Geräte, Zeitdruck und mögliche Barrieren. Ein internes Fachverfahren wird anders genutzt als ein E-Commerce-Checkout.
2. Anforderungen ableiten - Aus dem Kontext entstehen konkrete Anforderungen: Welche Schritte sind kritisch, welche Informationen fehlen, welche Fehlermuster treten auf, welche Regeln darf das System nicht verletzen?
3. Lösungen entwerfen - Erst jetzt skizziere ich Informationsarchitektur, Wireframes oder klickbare Prototypen. So wird die Diskussion sachlicher, weil alle über konkrete Abläufe sprechen können.
4. Mit echten Nutzern prüfen - Ein Prototyp ist kein Beweis. Erst ein Test zeigt, ob Menschen die Aufgaben tatsächlich erledigen, ob sie die richtigen Begriffe verstehen und ob sie an denselben Stellen stocken.
5. Iterieren - Die Erkenntnisse fließen zurück in die nächste Version. Gute Teams verbessern nicht nur die Oberfläche, sondern auch Aufgabenreihenfolge, Fehlermeldungen und Informationslogik.

Ich halte diese Schleife für den eigentlichen Wert des Ansatzes. Sie verhindert, dass ein Projekt sich in Annahmen verrennt. Wenn die Schleife sitzt, wird auch die Auswahl der Methoden deutlich einfacher. Genau darum geht es im nächsten Abschnitt.

Welche Methoden im Alltag am meisten bringen

Nicht jede Methode liefert dieselbe Art von Erkenntnis. Ich kombiniere in Projekten meist qualitative und quantitative Signale, weil beide etwas anderes beantworten. Qualitative Methoden erklären das Warum, quantitative Daten zeigen das Wo und Wie oft. Beides zusammen ist deutlich stärker als jede einzelne Methode für sich.

Ich setze diese Methoden nie als Selbstzweck ein. Wenn ich eine Sprache von Nutzern verstehen will, helfen Interviews. Wenn ein Formularprozess in der Praxis versagt, liefert ein Usability-Test die schnellste Wahrheit. Wenn das Produkt bereits läuft, priorisieren Support-Tickets und Nutzungsdaten die dringendsten Baustellen. A/B-Tests sind sinnvoll, wenn die Ausgangsfrage sauber formuliert ist und genug Reichweite vorhanden ist, sonst erzeugen sie nur Scheinpräzision.

Für frühe IT-Projekte reicht oft schon eine kleine, saubere Runde mit 5 bis 7 Gesprächen oder Tests pro Zielgruppe, um wiederkehrende Muster zu sehen. Ich betone „Muster“, nicht „Statistik“: Es geht an dieser Stelle darum, die richtigen Probleme zu finden, nicht schon perfekte Marktanteile zu prognostizieren. Sobald der Fokus klar ist, wird ein anderes Thema unvermeidlich wichtig: Zugänglichkeit und rechtliche Robustheit.

Warum Barrierefreiheit und Datenschutz dazugehören

In Deutschland gehören beide Themen inzwischen fest in die Produktarbeit. Seit dem 28. Juni 2025 gilt das BFSG für viele digitale Produkte und Dienstleistungen; wer eine Website, ein Portal oder einen Online-Prozess für Endkunden entwickelt, sollte Barrieren also früh mitdenken und nicht am Ende hektisch nachbessern. Für mich ist das kein separates Compliance-Projekt, sondern Teil guter Gestaltung.

Wenn ich auf Barrierefreiheit prüfe, beginne ich fast immer mit drei Punkten: Tastaturbedienung, Kontrast und verständliche Fehlermeldungen. Dazu kommt die semantische Struktur, also die Frage, ob Überschriften, Formulare und Hinweise so gebaut sind, dass Screenreader und andere Hilfen sie sauber erfassen können. Was für Menschen mit Einschränkungen funktioniert, macht das Produkt fast immer auch für alle anderen robuster.

• Tastaturbedienung - Alle Kernfunktionen müssen ohne Maus erreichbar sein.
• Klare Rückmeldungen - Fehler, Erfolg und Ladezustände brauchen verständliche Sprache.
• Genügend Kontrast - Sichtbarkeit ist keine Stilfrage, sondern ein Nutzbarkeitsfaktor.
• Datensparsamkeit - Ich frage nur Daten ab, die für den Schritt wirklich nötig sind.
• Saubere Freigaben - Consent-Flows sollten kurz, lesbar und ehrlich sein.

Datenschutz gehört hier direkt dazu. Ein Formular, das unnötige Daten verlangt oder Einwilligungen versteckt, ist nicht nur rechtlich unsauber, sondern auch schlecht nutzbar. Gerade in deutschen IT-Projekten sehe ich oft, dass Teams Barrierefreiheit und Datenschutz getrennt diskutieren. In der Praxis hängen sie zusammen: Beide zwingen dazu, Abläufe zu vereinfachen, Sprache zu präzisieren und Technik transparent zu machen. Wer das ignoriert, baut meist nicht nur unzugänglicher, sondern auch teurer.

Typische Fehler, die ich in IT-Projekten sehe

Die meisten Probleme entstehen nicht aus bösem Willen, sondern aus Zeitdruck und zu viel Vertrauen in Annahmen. Ich sehe in Projekten immer wieder dieselben Muster, und sie sind erstaunlich stabil. Wenn man sie früh erkennt, spart man sich viel Nacharbeit.

• Zu spät testen - Dann ist das Design schon festgezurrt und echte Erkenntnisse werden als Störung behandelt.
• Nur mit dem eigenen Team arbeiten - Interne Kolleginnen und Kollegen sind fast nie repräsentativ für die spätere Nutzung.
• Oberfläche mit Lösung verwechseln - Ein hübscher Screen hilft nicht, wenn der Prozess inhaltlich falsch ist.
• Feedback als Meinungskampf führen - Gute Entscheidungen entstehen aus beobachteten Aufgaben, nicht aus Lautstärke im Meeting.
• Edge Cases ignorieren - Gerade seltene Fälle verursachen in Fachsystemen oft die größten Kosten.
• Personas ohne echte Daten bauen - Fiktion ist kein Ersatz für belastbare Nutzerkenntnis.

Der härteste Punkt ist oft dieser: Ein sauberer Prototyp kann eine falsche Annahme nicht retten. Wenn die Grundlogik des Prozesses nicht stimmt, müssen Aufgabenreihenfolge, Informationsarchitektur oder Berechtigungsmodell geändert werden, nicht nur Farben und Icons. Ich sage das bewusst so direkt, weil sich viele Teams zu lange an visuellem Feinschliff festhalten. Genau an dieser Stelle trennt sich echte nutzerzentrierte Arbeit von bloßer Oberflächenpflege.

Was ich Teams für den nächsten Sprint mitgebe

Wenn ich ein Team auf den Einstieg vorbereite, beginne ich klein und bewusst mit einem klaren Ausschnitt. Eine gute Schleife ist besser als zehn halb fertige Ideen. Das Ziel ist nicht, alles auf einmal zu perfektionieren, sondern eine belastbare Routine aufzubauen, die Entscheidungen schneller und besser macht.

1. Formuliere pro Zielgruppe genau ein Kernziel.
2. Schreibe die drei wichtigsten Aufgaben auf, die wirklich gelingen müssen.
3. Prüfe den Ablauf mit 5 bis 7 echten Nutzern oder Vertreterinnen der Zielgruppe.
4. Baue einen klickbaren Prototypen, bevor die Entwicklung zu viel Zeit bindet.
5. Miss nicht nur Klicks, sondern auch Abbrüche, Fehler, Rückfragen und Bearbeitungszeit.
6. Plane mindestens eine Iteration ein, die nur auf Basis der Beobachtungen verbessert wird.

So wird aus einer abstrakten UX-Idee ein Arbeitsstil, der in Informatik und IT wirklich trägt: weniger Annahmen, weniger Nacharbeit und mehr Klarheit für Nutzer, Produkt und Entwicklung. Ich würde in einem echten Projekt immer dort anfangen, wo der Schaden am größten ist, und nie versuchen, alles gleichzeitig zu lösen. Wer diesen Ansatz konsequent anwendet, baut am Ende nicht nur bessere Oberflächen, sondern bessere digitale Prozesse.