review-ux-uiBewertet 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 Bewert…
Independent GitHub snapshot · Automated classification · Original documentation governs
User Experience und Interface-Design auf Usability, Zugaenglichkeit und Wirksamkeit bewerten.
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).
alt="")lang-Attribut auf <html> gesetztErwartet: 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.
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 |
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.
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.
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.
Fuer jedes Formular in der Anwendung:
autocomplete-Attribute fuer Standardfelder gesetzt (name, email, address, cc-number)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).
## 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.
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