pjt222/review-ux-ui

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