pjt222 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-Scaffoldingsetup-tailwind-typescript— Tailwind CSS fuer Design-System-Implementierung