---

name: review-ux-ui description: > Bewertet User Experience und Interface-Design anhand von Nielsens Heuristiken, WCAG-2.1-Zugaenglichkeitsrichtlinien, Tastatur- und Screenreader-Audit, Nutzerfluss-Analyse, Kognitive-Last-Bewertung und Formular-Usability-Pruefung. Verwenden bei einem Usability-Review vor dem Release, bei der Bewertung der WCAG-2.1-Zugaenglichkeitskonformitaet, bei der Bewertung von Nutzerfluessen auf Effizienz, beim Review von Formulardesign oder bei einer heuristischen Evaluation einer bestehenden Oberflaeche. locale: de source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Grep Glob WebFetch metadata: author: Philipp Thoss version: "1.0" domain: review complexity: advanced language: multi tags: ux, ui, accessibility, wcag, heuristics, usability, user-flows, cognitive-load

UX/UI reviewen

User Experience und Interface-Design auf Usability, Zugaenglichkeit und Wirksamkeit bewerten.

Wann verwenden

• Durchfuehrung eines Usability-Reviews einer Anwendung vor dem Release
• Bewertung der Zugaenglichkeitskonformitaet (WCAG 2.1 AA oder AAA)
• Bewertung von Nutzerfluessen auf Effizienz und Fehlervermeidung
• Review von Formulardesign auf Usability und Konversionsoptimierung
• Heuristische Evaluation einer bestehenden Benutzeroberflaeche
• Bewertung kognitiver Last und Informationsarchitektur

Eingaben

• Erforderlich: Zu reviewende Anwendung (URL, Prototyp oder Quellcode)
• Erforderlich: Beschreibung der Zielnutzer (Rollen, technische Kompetenz, Nutzungskontext)
• Optional: Nutzerforschungsergebnisse (Interviews, Umfragen, Analytics)
• Optional: WCAG-Konformitaetsziel (A, AA oder AAA)
• Optional: Spezifische Nutzerflüsse oder Aufgaben zur Bewertung
• Optional: Zu testende assistive Technologie (Screenreader, Switch-Access)

Vorgehensweise

Schritt 1: Heuristische Evaluation (Nielsens 10 Heuristiken)

Die Oberflaeche gegen jede Heuristik bewerten:

#	Heuristik	Schluesselfrage	Bewertung
1	Sichtbarkeit des Systemstatus	Informiert das System die Nutzer stets darueber, was passiert?
2	Uebereinstimmung mit der realen Welt	Verwendet das System vertraute Sprache und Konzepte?
3	Nutzerkontrolle und -freiheit	Koennen Nutzer einfach rueckgaengig machen, wiederherstellen oder unerwuenschte Zustaende verlassen?
4	Konsistenz und Standards	Verhalten sich aehnliche Elemente durchgehend gleich?
5	Fehlervermeidung	Verhindert das Design Fehler, bevor sie auftreten?
6	Erkennen statt Erinnern	Sind Optionen, Aktionen und Informationen sichtbar oder leicht abrufbar?
7	Flexibilitaet und Effizienz der Nutzung	Gibt es Abkuerzungen fuer erfahrene Nutzer, ohne Neulinge zu verwirren?
8	Aesthetisches und minimalistisches Design	Hat jedes Element einen Zweck? Gibt es unnoetige Unordnung?
9	Nutzer beim Erkennen, Diagnostizieren und Beheben von Fehlern unterstuetzen	Sind Fehlermeldungen klar, spezifisch und konstruktiv?
10	Hilfe und Dokumentation	Ist Hilfe verfuegbar und leicht zu finden, wenn noetig?

Fuer jede Heuristik den Schweregrad von Verstoessen bewerten:

Schweregrad	Beschreibung
0	Kein Usability-Problem
1	Kosmetisch — beheben, wenn Zeit vorhanden
2	Geringfuegig — Behebung mit niedriger Prioritaet
3	Wesentlich — wichtig zu beheben, hohe Prioritaet
4	Katastrophal — muss vor Release behoben werden

## Befunde der heuristischen Evaluation
| # | Heuristik | Schweregrad | Befund | Stelle |
|---|-----------|----------|---------|----------|
| 1 | Systemstatus | 3 | Kein Ladeindikator waehrend Datenabruf — Nutzer klicken wiederholt | Dashboard-Seite |
| 3 | Nutzerkontrolle | 2 | Kein Rueckgaengig fuer das Loeschen von Eintraegen — nur ein Bestaetigungsdialog | Eintrags-Liste |
| 5 | Fehlervermeidung | 3 | Datumsfeld akzeptiert ungueltige Daten (30. Feb.) | Buchungsformular |
| 9 | Fehlerbehebung | 4 | Formularuebertragungsfehler loescht alle Felder | Registrierung |

Erwartet: Alle 10 Heuristiken mit spezifischen Befunden und Schweregradebewertungen ausgewertet. Bei Fehler: Bei Zeitdruck auf Heuristiken 1, 3, 5 und 9 konzentrieren (groesste Auswirkung auf User Experience).

Schritt 2: Zugaenglichkeits-Audit (WCAG 2.1)

Wahrnehmbar

• 1.1.1 Nichttextlicher Inhalt: Alle Bilder haben Alt-Text (dekorative Bilder haben alt="")
• 1.3.1 Information und Beziehungen: Semantisches HTML verwendet (Ueberschriften, Listen, Tabellen, Landmarks)
• 1.3.2 Bedeutungsvolle Reihenfolge: DOM-Reihenfolge stimmt mit visueller Reihenfolge ueberein
• 1.4.1 Verwendung von Farbe: Farbe ist nicht das einzige Mittel zur Informationsuebermittlung
• 1.4.3 Kontrast: Textkontrastverhältnis ≥ 4,5:1 (normal), ≥ 3:1 (grosser Text)
• 1.4.4 Textgroessenveraenderung: Text kann ohne Funktionsverlust auf 200% skaliert werden
• 1.4.11 Nicht-Text-Kontrast: UI-Komponenten und Grafiken haben ≥ 3:1 Kontrast
• 1.4.12 Textabstand: Inhalt funktioniert mit erhoehtem Textabstand (Zeilenhoehe 1,5x, Zeichenabstand 0,12em, Wortabstand 0,16em)

Bedienbar

• 2.1.1 Tastatur: Alle Funktionen sind per Tastatur bedienbar
• 2.1.2 Keine Tastaturfalle: Fokus wird niemals in einer Komponente gefangen
• 2.4.1 Bloecke ueberspringen: Skip-Navigation-Link fuer Tastaturnutzer verfuegbar
• 2.4.3 Fokusreihenfolge: Tab-Reihenfolge folgt einer logischen, vorhersehbaren Sequenz
• 2.4.7 Fokus sichtbar: Tastaturfokus-Indikator ist klar sichtbar
• 2.4.11 Fokus nicht verdeckt: Fokussiertes Element verbirgt sich nicht hinter fixierten Headern/Overlays
• 2.5.5 Zielgroesse: Interaktive Ziele sind mindestens 24x24px (44x44px auf Touch empfohlen)

Verstaendlich

• 3.1.1 Sprache der Seite: lang-Attribut auf <html> gesetzt
• 3.2.1 Beim Fokus: Fokus loest keine unerwarteten Aenderungen aus
• 3.2.2 Bei Eingabe: Eingabe loest ohne Warnung keine unerwarteten Aenderungen aus
• 3.3.1 Fehleridentifikation: Fehler werden in Text klar beschrieben
• 3.3.2 Beschriftungen oder Anweisungen: Formulareingaben haben sichtbare Beschriftungen
• 3.3.3 Fehlerkorrekturhinweis: Fehlermeldungen schlagen Korrekturen vor

Robust

• 4.1.1 Parsen: HTML ist valide (keine doppelten IDs, korrekte Verschachtelung)
• 4.1.2 Name, Rolle, Wert: Benutzerdefinierte Komponenten haben ARIA-Rollen und -Eigenschaften
• 4.1.3 Statusmeldungen: Dynamische Inhaltaenderungen werden Screenreadern angezeigt

Erwartet: WCAG-2.1-AA-Kriterien systematisch mit Bestanden/Nicht-bestanden geprueft. Bei Fehler: Automatisierte Tools (axe-core, Lighthouse) fuer initialen Scan verwenden, dann manuelles Testen fuer Kriterien, die menschliches Urteilsvermoegen erfordern.

Schritt 3: Tastatur- und Screenreader-Audit

Tastaturnavigations-Test

Nur Tab, Umschalt+Tab, Eingabe, Leertaste, Pfeiltasten und Escape verwenden:

## Tastaturnavigations-Audit
| Aufgabe | Erfuellbar? | Probleme |
|------|-------------|--------|
| Zum Hauptinhalt navigieren | Ja — Skip-Link funktioniert | Keine |
| Dropdown-Menu oeffnen | Ja | Pfeiltasten funktionieren nicht innerhalb des Menus |
| Formular absenden | Ja | Tab-Reihenfolge ueberspringt den Absenden-Button |
| Modal schliessen | Nein | Escape schliesst nicht, kein sichtbarer Schliessen-Button in Tab-Reihenfolge |
| Datumsauswahl verwenden | Nein | Benutzerdefinierte Datumsauswahl nicht per Tastatur zugaenglich |

Screenreader-Test

Mit NVDA (Windows), VoiceOver (macOS/iOS) oder TalkBack (Android) testen:

## Screenreader-Audit
| Element | Angezeigt als | Erwartet | Problem |
|---------|-------------|----------|-------|
| Logo-Link | "Link, Bild" | "Home, Link" | Fehlender Alt-Text beim Logo |
| Sucheingabe | "Bearbeiten, Suchen" | "Produkte suchen, Bearbeiten" | Fehlende Label-Verknuepfung |
| Navigations-Menu | "Navigation, Haupt" | Korrekt | Keine |
| Fehlermeldung | (nicht angezeigt) | "Fehler: E-Mail ist erforderlich" | Fehlende Live-Region |
| Ladeanzeige | (nicht angezeigt) | "Wird geladen, bitte warten" | Fehlende aria-live oder role="status" |

Erwartet: Vollstaendige Aufgabenfluesse mit Nur-Tastatur und Screenreader getestet. Bei Fehler: Wenn kein Screenreader verfuegbar ist, ARIA-Attribute und semantisches HTML als Ersatz pruefen.

Schritt 4: Nutzerfluesse analysieren

Wichtige Nutzerfluesse kartieren und bewerten:

## Nutzerfluss: Kauf abschliessen

### Schritte
1. Produkte durchsuchen → 2. Produkt ansehen → 3. In den Warenkorb → 4. Warenkorb ansehen →
5. Versand angeben → 6. Zahlung angeben → 7. Bestellung pruefen → 8. Bestaetigen

### Bewertung
| Schritt | Reibung | Schweregrad | Anmerkungen |
|------|---------|----------|-------|
| 1→2 | Niedrig | - | Klare Produktkarten |
| 2→3 | Mittel | 2 | "In den Warenkorb"-Schaltflaeche unterhalb des sichtbaren Bereichs auf Mobil |
| 3→4 | Niedrig | - | Warenkorb-Icon aktualisiert sich mit Anzahl |
| 4→5 | Hoch | 3 | Konto erforderlich — kein Gaeste-Checkout |
| 5→6 | Niedrig | - | Adress-Autovervollstaendigung funktioniert gut |
| 6→7 | Mittel | 2 | Kartennummernfeld formatiert sich nicht automatisch |
| 7→8 | Niedrig | - | Klare Bestelluebersicht |

### Fluss-Effizienz
- **Schritte**: 8 (akzeptabel fuer E-Commerce)
- **Pflichtfelder**: 14 (koennte mit Adress-Autovervollstaendigung + gespeicherter Zahlung reduziert werden)
- **Entscheidungspunkte**: 2 (Groessenauswahl, Versandart)
- **Potenzielle Abbruchpunkte**: Schritt 4→5 (erzwungene Kontoerstellung)

Erwartet: Kritische Nutzerfluesse mit identifizierten und bewerteten Reibungspunkten kartiert. Bei Fehler: Wenn keine Nutzer-Analytics verfuegbar sind, Fluesse anhand von Aufgabenkomplexitaet und Anzahl der Schritte bewerten.

Schritt 5: Kognitive Last bewerten

• Informationsdichte: Ist die Informationsmenge pro Bildschirm angemessen?
• Progressive Offenlegung: Werden komplexe Informationen schrittweise aufgedeckt?
• Chunking: Sind verwandte Elemente visuell gruppiert (Gestalt-Prinzipien)?
• Erkennen statt Erinnern: Koennen Nutzer Optionen sehen, anstatt sich an sie erinnern zu muessen?
• Konsistente Muster: Verwenden aehnliche Aufgaben aehnliche Interaktionsmuster?
• Entscheidungsmuedigkeit: Werden Nutzern zu viele Optionen auf einmal praesentiert? (Hick'sches Gesetz)
• Arbeitsgedaechtnis: Muessen Nutzer sich Informationen ueber mehrere Schritte merken?

Erwartet: Kognitive Last mit spezifischen ueberlasteten oder unterlasteten Bereichen bewertet. Bei Fehler: Wenn kognitive Last objektiv schwer zu bewerten ist, den "Squint-Test" verwenden — Augen zusammenkneifen und sehen, ob Struktur und Hierarchie noch erkennbar sind.

Schritt 6: Formular-Usability reviewen

Fuer jedes Formular in der Anwendung:

• Beschriftungen: Jede Eingabe hat eine sichtbare, verknuepfte Beschriftung
• Platzhaltertext: Nur fuer Beispiele verwendet, nicht als Beschriftungen
• Eingabetypen: Korrekte HTML-Eingabetypen (email, tel, number, date) fuer mobile Tastaturen
• Validierungszeitpunkt: Fehler werden bei Verlassen oder Absenden angezeigt (nicht bei jedem Tastendruck)
• Fehlermeldungen: Spezifisch ("E-Mail muss @ enthalten") nicht generisch ("Ungueltige Eingabe")
• Pflichtfelder: Klar markiert (und optionale Felder markiert, wenn die meisten Pflichtfelder sind)
• Feldgruppierung: Verwandte Felder visuell gruppiert (Name, Adresse, Zahlungsabschnitte)
• Autovervollstaendigung: autocomplete-Attribute fuer Standardfelder gesetzt (name, email, address, cc-number)
• Tab-Reihenfolge: Logischer Fluss entsprechend dem visuellen Layout
• Mehrstufige Formulare: Fortschrittsindikator zeigt aktuellen Schritt und Gesamtanzahl
• Persistenz: Formulardaten bleiben erhalten, wenn Nutzer die Seite verlassen und zurueckkehren

Erwartet: Jedes Formular gegen die Checkliste bewertet mit dokumentierten spezifischen Problemen. Bei Fehler: Wenn es viele Formulare gibt, die haeufigst genutzten Formulare priorisieren (Registrierung, Checkout, Kontakt).

Schritt 7: Den UX/UI-Review verfassen

## UX/UI-Review-Bericht

### Zusammenfassung
[2-3 Saetze: Gesamtusability, kritischste Probleme, staerkste Aspekte]

### Zusammenfassung der heuristischen Evaluation
| Heuristik | Schweregrad | Wichtigster Befund |
|-----------|----------|-------------|
[Zusammenfassungstabelle aus Schritt 1]

### Zugaenglichkeitskonformitaet
- **Ziel**: WCAG 2.1 AA
- **Status**: [X von Y Kriterien bestanden]
- **Kritische Fehler**: [Liste]

### Nutzerfluss-Analyse
[Wichtige Reibungspunkte mit Schweregrad und Empfehlungen]

### Top-5-Verbesserungen (Priorisiert)
1. **[Problem]** — Schweregrad: [N] — [Spezifische Empfehlung]
2. ...

### Was gut funktioniert
1. [Spezifische positive Beobachtung]
2. ...

Erwartet: Review liefert priorisierte, umsetzbare Empfehlungen mit Schweregradebewertungen. Bei Fehler: Wenn der Review zu viele Probleme aufdeckt, in "muss behoben werden" (Schweregrad 3-4) und "sollte behoben werden" (Schweregrad 1-2) kategorisieren.

Validierung

• Alle 10 Nielsenschen Heuristiken mit Schweregradebewertungen ausgewertet
• WCAG-2.1-Kriterien geprueft (mindestens: 1.1.1, 1.4.3, 2.1.1, 2.4.7, 3.3.1, 4.1.2)
• Tastaturnavigation fuer wichtige Nutzerfluesse getestet
• Screenreader getestet (oder ARIA/semantisches HTML als Ersatz geprueft)
• Mindestens ein kritischer Nutzerfluss auf Reibung analysiert
• Kognitive Last bewertet
• Formular-Usability ausgewertet
• Befunde nach Schweregrad priorisiert mit umsetzbaren Empfehlungen

Haeufige Stolperfallen

• UX mit visuellem Design verwechseln: UX handelt davon, wie es funktioniert; visuelles Design davon, wie es aussieht. Eine schoene Oberflaeche kann eine schreckliche UX haben. Beides bewerten, aber unterscheiden.
• Nur den gluecklichen Pfad testen: Fehler-, Leer- und Ladezustaende sowie Grenzfaelle verbergen UX-Probleme.
• Echte Geraete ignorieren: Der responsive Modus der Browser-Entwicklertools ist ein Ersatz. Das Testen auf echten Geraeten deckt Touch-, Leistungs- und Viewport-Probleme auf.
• Zugaenglichkeit als Nachgedanke: Spaet gefundene Zugaenglichkeitsprobleme sind teuer zu beheben. Fruehzeitig und kontinuierlich bewerten.
• Persoenliche Praeferenz als UX-Feedback: "Ich wuerde lieber..." ist kein UX-Feedback. Heuristiken, Forschung oder etablierte Muster zitieren.

Verwandte Skills

• review-web-design — visuelles Design-Review (Layout, Typografie, Farbe — ergaenzend zu UX)
• scaffold-nextjs-app — Next.js-Anwendungs-Scaffolding
• setup-tailwind-typescript — Tailwind CSS fuer Design-System-Implementierung