Was ist UX-Design? Der UX-Design-Prozess Schritt für Schritt

Kurz gesagt

UX-Design beginnt mit Fragen, bevor irgendetwas auf den Screen kommt. Wer wird das Produkt nutzen, was will die Person erreichen, wo bleibt sie hängen? Gezeichnet wird erst, wenn diese Fragen beantwortet sind.

Den Begriff selbst erkläre ich im Glossareintrag UX (User Experience). Den Unterschied zwischen UI und UX beschreibe ich im Ratgeber UI und UX. Diese Seite konzentriert sich darauf, wie die Arbeit gemacht wird, also auf den Prozess.

Der Prozess hat eine einzige Regel: Das letzte Wort haben die Informationen von Nutzern. Das nennt man nutzerzentriertes Design. Der internationale Standard für diesen Ansatz ist ISO 9241-210.

Der UX-Design-Prozess: sieben Schritte

Ich teile den Prozess in sieben Schritte. Jeder hat ein greifbares Ergebnis. Ein Schritt ohne Ergebnis bleibt ein Meeting.

Prozessdiagramm

1. 1Erfor­schen

   1. Erforschen

   Ergebnis

   Notiz zum Nutzungskontext: wer nutzt es, mit welchem Ziel, auf welchem Gerät. Interviewnotizen und Profile der Nutzergruppen.

   Dauer

   Hängt vom Umfang ab und davon, wie leicht Sie Nutzer erreichen. In einem neuen Produkt kann es einer der längsten Schritte sein.

   Werkzeuge

   Interviewleitfaden, Videocall mit Aufnahme, Analytics-Dashboard, Supportanfragen.

   Entsprechung in den Modellen

   ISO 9241-210: Nutzungskontext verstehen und beschreiben. Double Diamond: Entdecken.

2. 2Defi­nieren

   2. Definieren

   Ergebnis

   Problembeschreibung in einem Satz, Liste der Nutzungsanforderungen und ihre Rangfolge.

   Dauer

   Ein kurzer, dichter Schritt. Liegen die Forschungsnotizen vor, ist er in wenigen gemeinsamen Sitzungen erledigt.

   Werkzeuge

   Digitales Whiteboard (zum Clustern der Notizen), gemeinsames Dokument.

   Entsprechung in den Modellen

   ISO 9241-210: Nutzungsanforderungen festlegen. Double Diamond: Definieren.

3. 3Ideen finden

   3. Ideen finden

   Ergebnis

   Ablaufskizzen, grobe Scribbles und einige daraus gewählte Lösungsrichtungen.

   Dauer

   Bewusst kurz. Erst entstehen viele Optionen, dann fallen die meisten weg.

   Werkzeuge

   Papier und Stift, Whiteboard, Werkzeug für Flussdiagramme.

   Entsprechung in den Modellen

   ISO 9241-210: Gestaltungslösungen entwickeln. Double Diamond: Entwickeln.

4. 4Proto­typ

   4. Prototyp

   Ergebnis

   Wireframe, Nutzungsszenarien und klickbarer Prototyp. Es geht von der groben zur realitätsnahen Version.

   Dauer

   Hängt von der Detailtiefe des Prototyps ab. Ein grober Entwurf entsteht schnell, ein realitätsnaher Prototyp dauert länger.

   Werkzeuge

   Ein Designwerkzeug wie Figma, Papierprototyp oder direkt Code.

   Entsprechung in den Modellen

   ISO 9241-210: Gestaltungslösungen entwickeln. Double Diamond: Entwickeln.

5. 5Testen

   5. Testen

   Ergebnis

   Bericht zum Usability-Test: wer wo hängen blieb, wie schwer jedes Problem wiegt, was als Nächstes kommt.

   Dauer

   Eine einzelne Runde ist kurz. Oft mit wenigen Personen zu testen, lehrt mehr als ein seltener großer Test.

   Werkzeuge

   Link zum Prototyp, Videocall, Bildschirmaufnahme, Notizvorlage.

   Entsprechung in den Modellen

   ISO 9241-210: Gestaltung anhand der Anforderungen evaluieren. Double Diamond: Umsetzen (im Kleinen erproben).

6. 6Ver­öffent­lichen

   6. Veröffentlichen

   Ergebnis

   Entwicklungsfertige Designdatei, Komponenten und am Ende die Oberfläche live.

   Dauer

   Hängt von Team und Umfang ab. In kleinen Teilen zu veröffentlichen, beschleunigt das Lernen.

   Werkzeuge

   Designdatei, Designsystem, Code-Repository.

   Entsprechung in den Modellen

   ISO 9241-210: Gestaltungslösungen entwickeln (umgesetzte Oberfläche). Double Diamond: Umsetzen.

7. 7Messen

   7. Messen

   Ergebnis

   Metrik-Dashboard, Notizen aus dem Feld und Ergebnisse von Nutzerumfragen. Daraus kommt der Forschungsinput für die nächste Runde.

   Dauer

   Endet nie. Es läuft, solange das Produkt live ist.

   Werkzeuge

   Web-Analytics, Umfrageformular, Supportanfragen, Werkzeug für Sitzungsaufzeichnungen.

   Entsprechung in den Modellen

   ISO 9241-210: Evaluieren (langfristige Beobachtung). Double Diamond: Neu entdecken.

Schleife: Reicht das Testergebnis nicht, geht es zurück zu Definieren oder Prototyp. Messen liefert außerdem den Input für das Erforschen der nächsten Runde.

Drücken Sie auf einen Schritt: Darunter erscheinen sein Ergebnis, wie lange er dauert und mit welchen Werkzeugen er gemacht wird. Die Dauer steht bewusst ohne Zahlen da, weil sie in jedem Projekt anders ist.

Lesen Sie die Reihenfolge im Diagramm als Vorschlag. Bei einer kleinen Änderung kann die Forschung darin bestehen, ein paar Supportanfragen zu lesen. In einem neuen Produkt ist sie oft einer der längsten Schritte.

Die zwei Modelle hinter dem Prozess

Die sieben Schritte habe ich nicht erfunden. Ich bin von zwei verbreiteten Modellen ausgegangen und habe sie an die tägliche Arbeit angepasst. Das eine ist ISO 9241-210, das andere das Double-Diamond-Modell des Design Council.

ISO 9241-210: menschzentrierte Gestaltung

ISO 9241-210 ist der Standard für menschzentrierte Gestaltung interaktiver Systeme. Ich stütze mich in diesem Ratgeber auf die zweite Ausgabe von 2019. Der Standard setzt keinen bestimmten Designprozess voraus und lässt sich auch in so verschiedene Ansätze wie das Wasserfallmodell einbauen.

Der Standard nennt vier Aktivitäten:

1. Den Nutzungskontext verstehen und beschreiben.
2. Die Nutzungsanforderungen festlegen.
3. Gestaltungslösungen entwickeln, die diese Anforderungen erfüllen.
4. Die Gestaltung anhand der Anforderungen evaluieren.

Tabelle 1 des Standards nennt auch Beispielergebnisse jeder Aktivität. Aus dem Kontext entstehen Profile der Nutzergruppen und Personas. Die Gestaltung liefert Prototypen mit niedriger und hoher Detailtiefe, die Evaluation einen Bericht zum Usability-Test.

Der Standard hat außerdem sechs Grundsätze. Auf zwei stütze ich mich am meisten: Nutzer sind während der ganzen Gestaltung beteiligt, und der Prozess ist iterativ. Der Standard zählt ein unvollständiges oder falsches Verständnis der Nutzerbedürfnisse zu den Hauptgründen, warum Systeme scheitern.

Double Diamond: zwei Rauten, vier Phasen

Double Diamond ist ein Modell, das der britische Design Council 2004 vorgestellt hat. Es besteht aus zwei Rauten. In jeder Raute wird das Thema erst geöffnet, dann fokussiert.

Die erste Raute dreht sich um das Problem. Die Phase Entdecken (Discover) versucht, das Problem zu verstehen, statt es vorauszusetzen. Die Phase Definieren (Define) fasst das Problem mit den gesammelten Erkenntnissen neu.

Die zweite Raute dreht sich um die Lösung. In der Phase Entwickeln (Develop) entstehen verschiedene Antworten. In der Phase Umsetzen (Deliver) werden Lösungen im Kleinen erprobt, was nicht funktioniert, fällt weg.

Der Design Council schreibt ausdrücklich, dass das Modell kein linearer Prozess ist. Einer der vier Grundsätze im Innovationsrahmen der Organisation lautet sinngemäß: iterieren, iterieren, iterieren.

Wie die sieben Schritte in die beiden Modelle passen

Schritt	ISO 9241-210	Double Diamond
1. Erforschen	Nutzungskontext verstehen und beschreiben	Entdecken
2. Definieren	Nutzungsanforderungen festlegen	Definieren
3. Ideen finden	Gestaltungslösungen entwickeln	Entwickeln
4. Prototyp	Gestaltungslösungen entwickeln	Entwickeln
5. Testen	Gestaltung anhand der Anforderungen evaluieren	Umsetzen (im Kleinen erproben)
6. Veröffentlichen	Gestaltungslösungen entwickeln (umgesetzte Oberfläche)	Umsetzen
7. Messen	Evaluieren (langfristige Beobachtung)	Neu entdecken

Mein Unterschied: Keines der beiden Modelle zeichnet die Zeit nach dem Launch als eigenen Schritt. Ich halte Veröffentlichen und Messen getrennt. In kleinen Teams wird genau dieser Teil am häufigsten übersprungen.

Die Schritte im Einzelnen

1. Erforschen

Ziel ist, den Nutzungskontext zu verstehen. ISO 9241-210 beschreibt den Kontext als Kombination aus Nutzern, Zielen, Aufgaben, Ressourcen und Umgebung. Wichtig ist also nicht nur die Person vor dem Screen, sondern auch, unter welchen Umständen sie draufschaut.

Stellen Sie sich vor, Sie gestalten den Retourenablauf eines Onlineshops neu. Zuerst sprechen Sie mit einigen Kundinnen und Kunden, die eine Retoure angemeldet haben, und lesen die häufigsten Fragen an den Support. Oft kann die Person das Formular ausfüllen. Wo sie wirklich hängen bleibt: Sie findet nicht, wo die Retoure beginnt.

2. Definieren

Sie clustern die Forschungsnotizen und verdichten sie zu einem einzigen Problemsatz. „Die Kundin findet auf der Seite Bestellungen nicht, wo die Retoure beginnt“ ist ein guter Satz. „Die Retoure ist schlecht“ sagt gar nichts.

Danach schreiben Sie die Anforderungen auf. Widersprechen sich Wünsche, entscheiden Sie in diesem Schritt, welcher Vorrang hat.

3. Ideen finden

Legen Sie sich in diesem Schritt nicht sofort auf eine Lösung fest. Ich zeichne erst mit groben Skizzen viele Wege und streiche dann die meisten. Genau das ist der sich öffnende Teil der zweiten Raute im Double Diamond.

Im Retourenbeispiel können zwei Wege hervortreten: ein Button „Zurücksenden“ auf der Bestellkarte oder ein Link in der Versandbenachrichtigung. Welcher richtig ist, wissen Sie noch nicht. Das sagt Ihnen der Test.

4. Prototyp bauen

Die gewählte Richtung verwandeln Sie in etwas Testbares. ISO 9241-210 fasst den Prototyp weit: Er kann eine einfache Skizze sein oder ein fast vollständig funktionierendes System.

Ich beginne meist mit einem Wireframe aus grauen Kästen. Sitzt der Ablauf, gehe ich zu einem klickbaren Prototyp über. Ist der Prototyp realistischer als nötig, schaut die Testperson mehr auf die Farben als auf den Ablauf.

5. Testen

Sie legen den Prototyp echten Nutzern vor und geben eine Aufgabe: „Senden Sie die Schuhe zurück, die Sie letzte Woche gekauft haben.“ Dann schweigen Sie und beobachten.

Wie gebrauchstauglich der Ablauf ist, zeigt diese Beobachtung. Wo die Person zögert, sagt mehr als das, was sie sagt.

Oft wird gefragt, wie viele Personen nötig sind. Jakob Nielsen schreibt in einem Artikel von 2000, dass ein erster Test mit fünf Nutzern 85 Prozent der Usability-Probleme findet. Deshalb empfiehlt er statt eines Tests mit fünfzehn Personen drei Tests mit je fünf.

Aus dem Test entsteht eine Liste von Befunden. Wie ich Befunde formuliere und nach Schwere ordne, beschreibe ich im Ratgeber zum UX Audit.

6. Veröffentlichen

Ein Design ist eine Hypothese, bis Nutzer es berühren. In diesem Schritt wird die Designdatei entwicklungsfertig, und die Oberfläche geht live.

Details, die zwischen Design und Entwicklung verloren gehen, sehe ich in diesem Schritt am häufigsten. Leere Zustände und Fehlermeldungen sind im Design da und werden im Code vergessen. Liegen Design und Code bei derselben Person, wird dieser Verlust kleiner.

7. Messen

Das Produkt live sagt Dinge, die der Prototyp nicht sagen kann. Melden mehr Menschen Retouren an, kommt die Frage „Wo ist die Retoure?“ seltener beim Support an?

ISO 9241-210 zählt diesen Teil ebenfalls zur Evaluation und führt Ergebnisse langfristiger Beobachtung als Ergebnis auf. Auch der Design Council schreibt, dass keine Idee je ganz fertig ist. Die Frage aus der Messung ist die Forschung der nächsten Runde.

Beispiel: sieben Schritte in einer Banking-App

Ein erfundenes Beispiel: In der mobilen App einer Bank wird der Dauerauftrag für Rechnungen kaum genutzt. Das Team will den Screen für den Auftrag erneuern. So läuft der Prozess.

1. Erforschen. Das Team spricht mit einigen Kundinnen und Kunden, die ihre Rechnung jeden Monat von Hand bezahlen. Die meisten wissen nicht, dass es die Funktion gibt. Ein Teil derer, die sie kennen, fürchtet, dass ein falscher Betrag abgebucht wird.

2. Definieren. Der Problemsatz lautet: Die Kundschaft sieht vorher nicht, wann und wie viel der Auftrag abbucht. Daraus folgt die Anforderung: eine Benachrichtigung vor der Abbuchung und ein Weg zum Abbrechen.

3. Ideen finden. Gezeichnet werden eine Vorschlagskarte nach dem Bezahlen einer Rechnung, eine eigene Seite für Aufträge und eine Benachrichtigung vor der Abbuchung. Das Team entscheidet, Vorschlagskarte und Benachrichtigung zusammen zu testen.

4. Prototyp bauen. Erst wird der Ablauf auf Papier gezeichnet. Dann werden Vorschlagskarte und Benachrichtigungsscreen klickbar gemacht.

5. Testen. In der Runde mit fünf Personen können zwei das Datum der Benachrichtigung nicht lesen. Das Team vergrößert das Datum, setzt es neben den Betrag und macht eine neue Runde.

6. Veröffentlichen. Die Änderung wird zuerst für einen kleinen Teil der Nutzer freigeschaltet. Fehlermeldungen und der Abbruch-Screen sind in dieser Version schon fertig.

7. Messen. Das Team schaut auf die Zahl neuer Aufträge und die Abbruchrate. Liegen die Abbrüche höher als erwartet, geht es zurück zum Erforschen und fragt die Kundschaft nach dem Grund.

In diesem Beispiel dauert kein Schritt Wochen. Die Schritte sind klein, aber keiner wird übersprungen. Auch meine Projekte laufen oft in dieser Größenordnung.

Um die im Test gefundenen Probleme zu benennen, geben Nielsens 10 Heuristiken eine gemeinsame Sprache. Das Datumsproblem im Beispiel betrifft die Heuristik Sichtbarkeit des Systemstatus.

Der Prozess ist keine gerade Linie

Als Liste geschrieben, wirken die sieben Schritte, als ginge man sie der Reihe nach. In Wirklichkeit ist der Prozess eine Schleife. ISO 9241-210 schreibt, dass man die beste Gestaltung eines interaktiven Systems in der Regel nicht ohne Iteration erreicht.

Der Standard erklärt auch, warum. Viele Nutzerbedürfnisse zeigen sich erst während der Entwicklung. Und Nutzer beschreiben ihren Bedarf besser, wenn eine mögliche Lösung vor ihnen liegt. Deshalb ist es nicht möglich, am ersten Tag jedes Detail vollständig und richtig aufzuschreiben.

In der Praxis heißt das: Läuft der Test schlecht, gehen Sie zurück zum Prototyp. Wurde das Problem falsch definiert, zurück zum Definieren. Der Design Council warnt ähnlich: Ein Problem, das unterwegs auftaucht, schickt das Team manchmal ganz an den Anfang zurück.

Wie der Prozess in einem kleinen Team läuft

Die sieben Schritte können wirken, als bräuchten sie ein großes Forschungsteam. Doch auch ein kleines Team kann sie alle gehen. ISO 9241-210 schreibt, dass es von der Art des Projekts abhängt, wie oft Nutzer beteiligt werden.

In einem Ein-Personen-Start-up kann die Forschung aus ein paar kurzen Gesprächen mit Kunden bestehen. Für den Test reichen ein Link zum Prototyp und ein Videocall. Überspringen Sie keine Schritte, halten Sie jeden klein.

Mein Design & Ship Sprint ist für genau diese kleine Schleife gebaut. Design und Code laufen zwei Wochen lang bei derselben Person, das Ergebnis geht direkt in Ihr Repository.

Häufige Fehler

Die Forschung überspringen und gleich zeichnen. Der Screen wird sorgfältig gezeichnet, beantwortet aber die falsche Frage. Der erste Grundsatz des Standards ist, dass die Gestaltung auf einem klaren Verständnis von Nutzern, Aufgaben und Umgebung beruht.

Das Problem zusammen mit der Lösung definieren. „Wir brauchen ein neues Menü“ ist kein Problem, sondern eine Lösung. Im Problemsatz sollte kein Teil der Oberfläche beim Namen genannt werden.

Sich früh in eine Idee verlieben. Die erste Skizze ist meist die vertrauteste, aber vertraut heißt nicht richtig. Treffen Sie keine Wahl, ohne mehrere Wege nebeneinanderzulegen.

Den Test auf nach dem Launch verschieben. Einen Fehler live zu beheben, ist teurer als im Prototyp. Kleine, frühe Tests senken diese Kosten.

Im eigenen Team testen. Wer das Produkt baut, kennt den Ablauf auswendig. Testen Sie mit jemandem, der das Produkt noch nie gesehen hat.

Nach dem Launch aufhören. Gehen Sie ohne Messen zur nächsten Aufgabe, erfahren Sie nie, ob die Änderung gewirkt hat.

Barrierefreiheit ans Ende schieben. Werden Kontrast und Tastaturbedienung nicht schon beim Gestalten bedacht, ist das Nachrüsten schwer. Die Details stehen im WCAG-Ratgeber.

Meine Notiz

In der Arbeit mit Teams sehe ich am häufigsten, dass mitten im Prozess begonnen wird. Jemand kommt mit einer Screen-Idee, das Team geht direkt zum Prototyp. Forschung und Definition kommen danach, und dann nur, um die Idee zu verteidigen.

Deshalb beginne ich jede Arbeit mit einer einzigen Frage: Was will die Person, die diesen Screen öffnet, in diesem Moment tun? Ist die Antwort unklar, fange ich nicht an zu zeichnen.

Meine zweite Beobachtung betrifft das Messen. Teams halten den Launch für die Ziellinie. Dabei beginnt das eigentliche Lernen erst, wenn das Produkt ein paar Wochen live ist.