Der UX-Prozess im Überblick: Vom Problem zur Lösung

Eine Volkshochschule bekommt jeden Montag Dutzende Anrufe. Menschen wollen wissen, ob im Spanischkurs noch Plätze frei sind, warum die Anmeldung nicht klappt oder wo der Kurs eigentlich stattfindet. Die Leitung hat eine klare Vorstellung: „Wir brauchen eine neue Website. Moderner, mit App.“ Ein Budget ist schnell beantragt, eine Agentur schnell gefunden.

Ob die neue Website die Anrufe tatsächlich reduziert, weiß zu diesem Zeitpunkt niemand. Denn bisher hat niemand gefragt, warum die Menschen überhaupt anrufen. Vielleicht ist die Anmeldung zu kompliziert. Vielleicht fehlen Infos zum Kursort. Vielleicht rufen vor allem ältere Menschen an, die am Telefon einfach lieber sprechen. Jede dieser Antworten führt zu einer ganz anderen Lösung.

Genau hier setzt der UX-Prozess an. Er ist keine starre Methode, sondern eher eine Landkarte: Sie zeigt dir, wo du in einem Projekt gerade stehst, welche Fragen an dieser Stelle wichtig sind und welche Abkürzungen gefährlich werden. Dieser Artikel erklärt die Landkarte Schritt für Schritt, ohne dass du Vorwissen brauchst. Die Volkshochschule begleitet dich dabei als durchgehendes Beispiel.

Was mit „UX-Prozess“ gemeint ist

User Experience (kurz UX) beschreibt das gesamte Erlebnis, das Menschen mit einem Produkt oder Service haben: ob sie ihr Ziel erreichen, wie viel Mühe es kostet und wie sie sich dabei fühlen. Ein UX-Prozess ist die Abfolge von Arbeitsschritten, mit denen ein Team dieses Erlebnis gezielt verbessert. Mehr zum Begriff selbst findest du im Artikel Was ist User Experience?.

Wichtig ist dabei: Es gibt nicht den einen UX-Prozess. Es gibt mehrere bekannte Modelle, etwa den Double Diamond, Design Thinking oder Lean UX. Sie unterscheiden sich in Begriffen und Schwerpunkten, folgen aber fast alle derselben Grundidee. Wenn du diese Grundidee verstanden hast, findest du dich in jedem der Modelle zurecht.

Diese Grundidee lässt sich in einem Satz zusammenfassen: Erst das richtige Problem finden, dann die richtige Lösung. Das klingt banal. In der Praxis wird der erste Teil aber so oft übersprungen, dass es sich lohnt, ihn ernst zu nehmen.

Die Grundidee: Öffnen und Schließen

Das bekannteste Bild für den UX-Prozess ist der Double Diamond, auf Deutsch doppelter Diamant. Er stammt vom britischen Design Council, einer unabhängigen Organisation zur Förderung von Gestaltung, und wurde nach dessen Angaben 2004 vorgestellt. Das Modell zeigt zwei Rauten nebeneinander. Die erste steht für das Problem, die zweite für die Lösung.

Jede Raute öffnet sich zuerst und schließt sich dann wieder. Beim Öffnen denkst du breit: Du sammelst Eindrücke, Fragen und Ideen, ohne dich festzulegen. Das nennt man divergentes Denken. Beim Schließen sortierst du, wählst aus und triffst Entscheidungen. Das nennt man konvergentes Denken.

Ein Vergleich aus dem Alltag: Wenn du eine Wohnung suchst, schaust du dir zuerst viele Anzeigen an, auch welche, die nicht perfekt passen (öffnen). Dann legst du fest, was dir wirklich wichtig ist: Lage, Größe, Miete (schließen). Danach besichtigst du mehrere Wohnungen (öffnen) und unterschreibst am Ende einen Vertrag (schließen). Wer direkt die erste Wohnung nimmt, kann Glück haben. Meistens ärgert man sich später.

Aus den zwei Rauten ergeben sich vier Phasen, die der Design Council so benennt:

1. Discover (Entdecken): verstehen, was das Problem wirklich ist, statt es vorauszusetzen.
2. Define (Definieren): die Erkenntnisse ordnen und die Aufgabe neu und klar formulieren.
3. Develop (Entwickeln): verschiedene Lösungsideen erarbeiten.
4. Deliver (Umsetzen): Lösungen im Kleinen testen, Schwaches verwerfen und Vielversprechendes verbessern.

Diese vier Phasen sind die Landkarte, die du im Rest des Artikels kennenlernst. Ergänzt wird sie um einen fünften Schritt, der in vielen Modellen nur am Rand vorkommt, für Einsteigende aber wichtig ist: das, was nach dem Launch passiert.

Die Phasen im Detail

1. Verstehen: Was ist eigentlich los?

In der ersten Phase geht es darum, die Menschen und ihre Situation kennenzulernen. Die zentrale Frage lautet nicht „Was sollen wir bauen?“, sondern „Was passiert da gerade, und warum?“. Dafür gibt es eine ganze Reihe von Methoden, die man unter dem Begriff User Research zusammenfasst, also Forschung mit und über die Menschen, die ein Produkt nutzen.

Typische Methoden in dieser Phase sind:

• Gespräche mit Betroffenen, oft als halbstrukturierte Interviews mit vorbereiteten, offenen Fragen.
• Beobachtung im echten Umfeld, zum Beispiel am Telefon der Anmeldung oder neben jemandem, der gerade versucht, sich online anzumelden.
• Vorhandene Daten auswerten: Supportanfragen, Statistiken der Website, Beschwerden.

Im Beispiel der Volkshochschule hört das Team zwei Vormittage lang bei der Telefonanmeldung mit und notiert, worum es in jedem Anruf geht. Außerdem spricht es mit acht Menschen, die in den letzten Monaten einen Kurs gebucht haben, und schaut sich an, wo auf der Website am häufigsten abgebrochen wird. Das Ergebnis ist überraschend: Rund die Hälfte der Anrufe dreht sich gar nicht um die Anmeldung, sondern um eine einzige Frage: „Ist der Kurs für mich geeignet?“ Die Kursbeschreibungen erklären nämlich kaum, welches Vorwissen nötig ist.

Was du am Ende in der Hand hast: eine Sammlung von Beobachtungen, Zitaten und Mustern. Noch keine Lösung, und das ist auch richtig so.

2. Definieren: Welches Problem lösen wir?

Nach der ersten Phase hast du meist mehr Material, als du verarbeiten kannst. Jetzt schließt sich die erste Raute: Du sortierst die Erkenntnisse, erkennst Muster und entscheidest, welches Problem ihr angehen wollt.

Dabei helfen Werkzeuge, die Erkenntnisse greifbar machen. Eine Persona ist ein fiktives, aber auf echten Daten basierendes Profil einer typischen Nutzergruppe. Eine Journey Map zeigt den Weg, den Menschen Schritt für Schritt gehen, inklusive der Stellen, an denen es hakt. Beides ist kein Selbstzweck, sondern ein Mittel, damit das ganze Team dasselbe Bild im Kopf hat.

Am Ende dieser Phase steht eine klar formulierte Problemstellung. Eine gute Problemstellung beschreibt, wer was erreichen will und woran es scheitert. Sie enthält bewusst noch keine Lösung.

Vorher: „Wir brauchen eine neue Website mit App.“

Nachher: „Menschen, die einen Kurs suchen, können online nicht einschätzen, ob ein Kurs zu ihrem Niveau passt. Deshalb rufen sie an oder melden sich gar nicht erst an.“

Der Unterschied ist groß. Die erste Formulierung legt die Lösung schon fest. Die zweite lässt mehrere Lösungen zu, und sie macht messbar, ob eine Lösung wirkt: nämlich, wenn weniger Menschen mit genau dieser Frage anrufen.

Was du am Ende in der Hand hast: eine gemeinsame, schriftliche Problemstellung und ein Ziel, an dem ihr Erfolg später messen könnt.

3. Ideen entwickeln: Welche Lösungen sind denkbar?

Mit der zweiten Raute beginnt die Lösungssuche, und sie beginnt wieder breit. In dieser Phase ist Menge wichtiger als Qualität. Die erste Idee ist selten die beste, sie ist nur die naheliegendste.

Gute Ideen entstehen oft dann, wenn unterschiedliche Menschen zusammen nachdenken: Design, Entwicklung, Fachabteilung und im besten Fall auch Menschen, die das Produkt später nutzen. Typische Formate sind Brainstorming, bei dem Ideen erst gesammelt und später bewertet werden, oder schnelle Skizzenrunden, bei denen jede Person in wenigen Minuten mehrere Varianten auf Papier bringt.

Im Beispiel entstehen in einem zweistündigen Workshop unter anderem diese Ideen:

• ein kurzer Einstufungstest vor Sprachkursen,
• ein Abschnitt „Für wen ist dieser Kurs?“ in jeder Kursbeschreibung, mit Beispielen,
• ein Rückruf-Service, bei dem Lehrkräfte kurz beraten,
• Filter nach Niveau in der Kurssuche.

Erst danach wird bewertet. Welche Idee löst das definierte Problem am direktesten? Welche ist mit wenig Aufwand prüfbar? Das Team entscheidet sich, zuerst den neuen Abschnitt „Für wen ist dieser Kurs?“ und den Niveau-Filter auszuprobieren.

Was du am Ende in der Hand hast: eine Handvoll ausgewählter Ideen, die ihr als Nächstes prüfen wollt.

4. Prototypen bauen und testen: Funktioniert das?

Jetzt werden Ideen greifbar. Statt sofort zu programmieren, baust du eine vereinfachte Version, mit der Menschen schon etwas ausprobieren können. Dafür gibt es verschiedene Stufen:

• Ein Wireframe ist ein schlichter Bauplan einer Seite, oft nur in Grautönen. Er zeigt, was wo steht, aber noch nicht, wie es aussieht.
• Ein Prototyp ist eine ausprobierbare Version, von Papierskizzen bis zu klickbaren Entwürfen in einem Design-Tool.

Diesen Prototyp prüfst du in einem Usability-Test: Menschen aus der Zielgruppe bekommen eine realistische Aufgabe, etwa „Finde einen Spanischkurs, der zu deinen Vorkenntnissen passt“, und du beobachtest, wo sie zögern, suchen oder scheitern. Das Ziel ist nicht, die eigene Idee zu bestätigen, sondern herauszufinden, wo sie noch nicht funktioniert.

Im Beispiel zeigt der Test mit fünf Personen zwei Dinge. Der Abschnitt „Für wen ist dieser Kurs?“ hilft deutlich, wird aber übersehen, weil er unten auf der Seite steht. Und die Niveau-Bezeichnungen A1, A2 und B1 sagen vielen Menschen nichts. Das Team schiebt den Abschnitt nach oben und ergänzt zu jedem Niveau einen Satz in Alltagssprache, zum Beispiel „A2: Du kannst dich in einfachen Alltagssituationen verständigen“. Dann testet es erneut.

Was du am Ende in der Hand hast: eine getestete, verbesserte Lösung und das Wissen, warum sie so aussieht, wie sie aussieht.

5. Umsetzen, messen und weiterlernen

Wenn der Prototyp überzeugt, wird die Lösung umgesetzt und veröffentlicht. Für viele Einsteigende fühlt sich das wie das Ende an. Tatsächlich ist es eher ein Zwischenstand. Erst im echten Betrieb zeigt sich, ob die Lösung das Problem aus Phase 2 wirklich löst.

Deshalb lohnt es sich, schon vor dem Launch festzulegen, woran ihr Erfolg erkennt. Im Beispiel ist das die Zahl der Anrufe mit der Frage „Passt der Kurs zu mir?“. Das Team bittet die Anmeldung, diese Anrufe vier Wochen lang mit einer Strichliste zu zählen, wie schon in Phase 1. Sinkt die Zahl, war die Lösung wirksam. Bleibt sie gleich, beginnt eine neue Runde, mit einem klareren Bild als beim ersten Mal.

Was du am Ende in der Hand hast: eine Antwort auf die Frage, ob sich etwas verbessert hat, und meist schon die nächste offene Frage.

Drei bekannte Modelle, eine gemeinsame Logik

Wenn du dich weiter mit UX beschäftigst, begegnen dir verschiedene Prozessmodelle. Sie wirken auf den ersten Blick unterschiedlich, lassen sich aber gut auf die Landkarte oben legen.

Double Diamond

Der Double Diamond ist vor allem ein Verständigungswerkzeug. Er macht sichtbar, dass die Problemphase genauso viel Raum braucht wie die Lösungsphase. Der Design Council hat das Modell später zum „Framework for Innovation“ erweitert. Darin ergänzt er unter anderem vier Grundsätze: Menschen in den Mittelpunkt stellen, visuell und verständlich kommunizieren, gemeinsam gestalten und in Schleifen arbeiten.

Design Thinking

Design Thinking wurde vor allem durch die Designagentur IDEO und die d.school an der Stanford University bekannt. Die d.school beschreibt fünf Phasen: Empathize (Verstehen), Define (Definieren), Ideate (Ideen finden), Prototype (Prototypen bauen) und Test (Testen). Die Nielsen Norman Group, ein bekanntes UX-Beratungs- und Forschungsunternehmen, ergänzt eine sechste Phase, Implement (Umsetzen), und fasst die Phasen zu drei Abschnitten zusammen: verstehen, erkunden und umsetzen. Inhaltlich entspricht das sehr genau den fünf Schritten aus diesem Artikel.

Menschzentrierte Gestaltung nach ISO 9241-210

Etwas nüchterner, aber nicht weniger wichtig ist die internationale Norm ISO 9241-210. Sie beschreibt Human-Centered Design, also menschzentrierte Gestaltung für interaktive Systeme. Die aktuelle Fassung stammt von 2019 und wurde laut ISO 2025 bestätigt. Die Norm nennt vier Aktivitäten, die sich wiederholen:

1. den Nutzungskontext verstehen und beschreiben, also wer ein System wofür, wo und unter welchen Bedingungen nutzt,
2. die Anforderungen der Nutzenden festlegen,
3. Gestaltungslösungen entwickeln,
4. die Gestaltung evaluieren, also mit Nutzenden prüfen.

Dazu kommen Grundsätze wie: Nutzende werden während der gesamten Entwicklung einbezogen, die Gestaltung wird durch Evaluation vorangetrieben, und der Prozess ist iterativ, also in Wiederholungsschleifen angelegt. Wenn in einem Projekt von „normgerechter“ oder „menschzentrierter“ Entwicklung die Rede ist, ist meist diese Norm gemeint.

Lean UX

Lean UX wurde von Jeff Gothelf und Josh Seiden bekannt gemacht und richtet sich vor allem an Teams, die agil arbeiten, also in kurzen, regelmäßigen Entwicklungszyklen. Lean UX verdichtet den Prozess auf einen kleinen Kreislauf, der oft als „Think, Make, Check“ beschrieben wird: Annahmen als Hypothesen formulieren, eine kleine Version bauen, mit echten Menschen prüfen. Statt umfangreicher Dokumente zählt, was das Team gemeinsam lernt. Mehr zur Einordnung findest du im Artikel Lean UX: Trend oder handfeste Verbesserung?.

Lean UX zeigt auch, dass die Landkarte nicht immer in Wochen oder Monaten gemessen wird. Ein Durchlauf kann auch innerhalb eines einzigen Sprints passieren, wenn die Frage klein genug ist.

Eine Schleife, kein Fließband

Alle Modelle werden meist als Abfolge von links nach rechts gezeichnet. Das ist praktisch für die Erklärung, aber irreführend für die Praxis. Der Design Council betont ausdrücklich, dass der Double Diamond kein linearer Prozess ist. Die Nielsen Norman Group beschreibt Design Thinking ebenso als Kreislauf, in dem Teams nach dem Testen oft zum Verstehen zurückkehren.

Im Beispiel der Volkshochschule passiert genau das. Beim Usability-Test fällt auf, dass mehrere Testpersonen gar nicht über die Kurssuche kommen, sondern über die Suchmaschine direkt auf einer Kursseite landen. Das war in Phase 1 nicht aufgefallen. Das Team springt kurz zurück, schaut sich die Einstiegsseiten in der Statistik an und passt die Problemstellung an: Die Einschätzung, ob ein Kurs passt, muss auf jeder einzelnen Kursseite möglich sein, nicht nur in der Übersicht.

Solche Rücksprünge sind kein Zeichen dafür, dass etwas schiefgelaufen ist. Sie sind das eigentliche Ziel des Prozesses: früh lernen, solange Änderungen noch günstig sind. Eine Kursbeschreibung im Prototyp umzustellen, kostet ein paar Minuten. Dieselbe Änderung nach dem Relaunch kostet Abstimmungen, Entwicklungszeit und oft auch Geduld.

Wie groß muss der Prozess sein?

Ein häufiges Missverständnis bei Einsteigenden: Ein UX-Prozess klingt nach großen Teams, langen Projekten und viel Budget. Das muss er nicht sein. Die Landkarte bleibt gleich, nur der Maßstab ändert sich.

Ein Beispiel für zwei sehr unterschiedliche Größen:

• Großes Projekt: Ein Team aus Research, Design und Entwicklung arbeitet mehrere Monate am Relaunch eines Kundenportals, mit Dutzenden Interviews, mehreren Testrunden und einer schrittweisen Einführung.
• Kleine Frage: Eine Person aus dem Designteam will herausfinden, ob ein neuer Button-Text im Checkout verständlicher ist. Sie schaut sich eine Stunde lang Supportanfragen an (verstehen), formuliert das Problem in einem Satz (definieren), schreibt drei Varianten (Ideen), zeigt sie fünf Menschen (testen) und beobachtet nach dem Live-Gang die Abbruchrate (messen).

Beide folgen derselben Logik. Gerade für kleine Teams ist das eine gute Nachricht: Du brauchst nicht jede Methode, sondern für jede Phase eine, die zu eurer Situation passt. Wie das mit wenig Zeit und Budget aussehen kann, beschreibt das Buch Lean UX für kleine Teams, das Methoden entlang des Double Diamond sortiert. Wie sich UX-Arbeit in agile Abläufe einfügt, zeigt der Artikel Agile UX einfach im Projekt einsetzen.

Typische Fehler am Anfang

Wer den UX-Prozess zum ersten Mal anwendet, stolpert oft über dieselben Stellen. Die gute Nachricht: Wenn du sie kennst, kannst du sie meist vermeiden.

Mit der Lösung starten. Der Klassiker. Im Kick-off steht schon fest, was gebaut wird, und die Recherche soll das nur noch bestätigen. Frag in solchen Momenten freundlich nach: Welches Problem soll die Lösung lösen, und woher wissen wir, dass es dieses Problem gibt?

Research als Pflichtübung. Interviews werden geführt, landen in einem Bericht und spielen danach keine Rolle mehr. Recherche ist nur dann wertvoll, wenn sie Entscheidungen verändert. Ein einfacher Test: Kannst du benennen, welche Entscheidung aufgrund der Ergebnisse anders ausgefallen ist?

Endlos in der ersten Raute bleiben. Das Gegenteil ist auch ein Problem. Manche Teams recherchieren monatelang, weil sie Angst haben, etwas zu übersehen. Es reicht, genug zu wissen, um eine gute erste Problemstellung zu formulieren. Den Rest lernst du beim Testen.

Das Testen auslassen. Unter Zeitdruck fällt der Usability-Test oft als Erstes weg. Dabei ist er häufig der günstigste Weg, teure Fehler zu vermeiden. Schon ein kurzer Test mit wenigen Menschen zeigt die gröbsten Probleme.

Artefakte mit Ergebnissen verwechseln. Eine schöne Persona, eine farbige Journey Map, ein ausführlicher Bericht: Das alles sind Hilfsmittel. Das eigentliche Ergebnis ist, dass sich für die Menschen, die das Produkt nutzen, etwas verbessert.

So nutzt du die Landkarte im nächsten Projekt

Du musst in deinem nächsten Projekt nicht gleich ein komplettes Prozessmodell einführen. Oft reicht es, die Landkarte im Kopf zu haben und an den richtigen Stellen die richtigen Fragen zu stellen.

1. Bestimme, wo ihr steht. Bevor du loslegst, frag dich: Kennen wir das Problem schon, oder vermuten wir es nur? Je nach Antwort beginnst du in der ersten oder in der zweiten Raute.
2. Schreib die Problemstellung auf. Ein Satz reicht: Wer will was erreichen und woran scheitert es? Teile diesen Satz mit dem Team und lass ihn bestätigen oder korrigieren.
3. Lege fest, woran ihr Erfolg erkennt. Eine Zahl, ein Verhalten, eine Beobachtung. Ohne dieses Kriterium weißt du später nicht, ob die Lösung gewirkt hat.
4. Sammle mehr als eine Idee. Zwing dich, mindestens drei Lösungsansätze zu skizzieren, bevor du einen auswählst.
5. Teste früh und klein. Eine Skizze, die du fünf Menschen zeigst, verrät mehr als ein perfekter Entwurf, den niemand gesehen hat.
6. Plane den Rücksprung ein. Rechne damit, dass ein Test neue Fragen aufwirft, und lass dafür etwas Zeit im Plan.

Fazit

Der UX-Prozess ist weniger eine feste Abfolge von Methoden als eine Denkweise: erst verstehen, dann entscheiden, dann ausprobieren, dann lernen. Ob ein Modell Double Diamond, Design Thinking, ISO 9241-210 oder Lean UX heißt, ändert an diesem Kern wenig.

Für die Volkshochschule bedeutet das am Ende keine neue App, sondern verständlichere Kursseiten mit einem klaren Abschnitt „Für wen ist dieser Kurs?“ und erklärten Niveaustufen. Ob das reicht, zeigen die nächsten Wochen. Und falls nicht, weiß das Team diesmal genau, wo es weitermachen muss.

Wenn du gerade erst mit UX anfängst, nimm diese Landkarte als Orientierung. Die einzelnen Methoden, von Interviews über Personas bis zum Usability-Test, kannst du nach und nach dazulernen. Wichtig ist, dass du in jedem Projekt weißt, in welcher Phase du gerade bist und welche Frage du dort beantworten willst.

Checkliste

• Das Problem ist durch Gespräche, Beobachtungen oder Daten belegt, nicht nur vermutet.
• Es gibt eine schriftliche Problemstellung ohne vorweggenommene Lösung.
• Ein Erfolgskriterium ist festgelegt, bevor die Lösung entsteht.
• Mehrere Lösungsideen wurden gesammelt, bevor eine ausgewählt wurde.
• Die gewählte Lösung wurde als Prototyp mit echten Menschen getestet.
• Erkenntnisse aus Tests fließen zurück, auch wenn das einen Rücksprung bedeutet.
• Nach dem Launch wird geprüft, ob sich das Erfolgskriterium verändert hat.

Quellen

• Design Council: The Double Diamond
• Design Council: History of the Double Diamond
• Design Council: Framework for Innovation
• Stanford d.school: Design Thinking Bootleg, 2018
• Sarah Gibbons: Design Thinking 101. Nielsen Norman Group, 2016
• ISO 9241-210:2019: Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems
• NIST: Human Factors and Human-Centered Design
• Jeff Gothelf, Josh Seiden: Lean UX, 3. Auflage. O’Reilly Media, 2021
• Jonathan Follett: What Is Lean UX? O’Reilly Radar, 2017