julien-bloch/ux-review

Was macht ux-review?

Zielsetzung

Finde bedeutsame Hindernisse zwischen einem Benutzer und seinem beabsichtigten Ergebnis – nicht bloße Abweichungen von einer stilistischen Vorliebe. Liefere evidenzbasierte, priorisierte und umsetzbare Änderungen. Hebe Stärken hervor, erkenne Abwägungen an und vermeide es, Benutzerforschung oder Interaktionstests zu halluzinieren.

Überprüfungsmodi

• Screenshot / statisches Design: Prüfe nur das Sichtbare. Markiere mögliche Interaktionsrisiken als Hypothesen; behaupte nicht, Steuerelemente angeklickt, Tastaturzugriff geprüft oder verborgene Zustände gesehen zu haben.
• HTML / Quellcode: Überprüfe das gerenderte UI, falls verfügbar, und inspiziere relevante Semantik, Stile und Ereignisbehandlung. Code-Inspektion allein beweist kein Verhalten im Browser.
• Funktionierende Anwendung: Wenn Browser-Automatisierung oder Computer-Use-Tools verfügbar sind, führe repräsentative Aufgaben durch und erfasse ansichtsspezifische Beweise. Gehe nicht davon aus, dass Tools existieren.
• Vergleich / Regression: Verwende dieselben Aufgaben, Ansichtsfenster und Beweisstandards für Vorher/Nachher. Identifiziere echte Verbesserungen und neue Regressionen.
• Änderung gewünscht: Nach der Berichterstattung wende eng begrenzte Reparaturen an und verifiziere erneut, wenn Bearbeitungswerkzeuge verfügbar sind. Hat der Benutzer nur Kritik gewünscht, ändere keine Dateien.

Arbeitsablauf

1. Kontext herstellen. Identifiziere Zielbenutzer, Aufgabe, Bildschirmrolle (Überblick/Fokus/Erstellen/Ausführen), Plattform, Einschränkungen und bekannte Erfolgsmetrik. Falls unbekannt, nenne die Aufgabenannahme, anstatt Produktforschung zu erfinden.
2. Prüfbare Beweise sammeln. Untersuche bereitgestellte Bilder, Mockups, Anwendung oder Code. Falls verfügbar und dem Umfang der Anfrage angemessen, teste primäre Abläufe, öffne Menüs, bediene Tastatursteuerungen und überprüfe schmale/mobile sowie breite Ansichtsfenster. Siehe browser-review.md.
3. Benutzerergebnisse vor der Politur prüfen. Überprüfe: Aufgabenklarheit; Navigation und Wegfindung; Scanbarkeit und Hierarchie; Sammel- und Offenlegungsmuster; Aktionsfeedback und Wiederherstellung; Inhaltsklarheit und Vertrauen; responsives Verhalten; Barrierefreiheit; visuelle Kohärenz. Verwende review-heuristics.md. Gehe nicht davon aus, dass dasselbe Muster für jede Aufgabe optimal ist.
4. Beweise von Annahmen trennen. Kennzeichne Ergebnisse: V sichtbar im bereitgestellten Artefakt, T persönlich in einer funktionierenden Benutzeroberfläche getestet, C im Code verifiziert, aber nicht ausgeführt, H plausible Hypothese, U unbekannt/muss gemessen werden. Berichte genau, was beobachtet wurde. Bezeichne eine Modellsimulation niemals als Benutzerstudie.
5. Priorisieren. Weise zu: Kritisch (blockiert Abschluss, ernsthafter Schaden, Verlust), Hoch (große Reibung bei häufiger/wichtiger Aufgabe), Mittel (bedeutende, aber nicht blockierende Kosten) oder Niedrig (kleinere Verbesserung). Berücksichtige Aufgabenauswirkung, wahrscheinliche Exposition, Wiederherstellbarkeit und Beweisvertrauen; erzeuge keine numerische Sicherheit.
6. Umsetzbare Korrekturen empfehlen. Für jedes wesentliche Ergebnis: wo, Beweis, warum es wichtig ist, konkrete Änderung und Überprüfungsschritt. Bevorzuge 3–7 hochwertige Ergebnisse; mehr nur, wenn gerechtfertigt. Hebe gute Entscheidungen ausdrücklich hervor und biete Alternativen an, wenn eine echte Abwägung besteht.
7. Abschluss. Falls Änderungen angefordert wurden, führe gezielte Änderungen durch, führe betroffene Prüfungen erneut aus und berichte über verbleibende Einschränkungen. Falls Forschung nötig ist, schlage eine kleine realistische Benutzeraufgabe oder ein Experiment vor, anstatt Präferenzen zu erraten. Siehe reporting-and-evaluation.md.

Leitplanken

• Verwandle Kritik nicht in ein unaufgefordertes Rebranding oder einen Neubau; behalte die Identität der Anwendung und funktionierende Funktionen bei, es sei denn, sie verursachen ein konkretes Problem.
• Belohne spärliche Bildschirme nicht unterschiedslos. Bewerte die Informationsdichte im Hinblick auf die Anforderungen an Scannen, Vergleichen und Entscheidungsfindung.
• Bewerte visuellen Geschmack nicht als Benutzerfreundlichkeitsmangel. Kennzeichne subjektive Präferenzen separat.
• Beurteile ein Menü nicht als defekt, allein aufgrund eines statischen Screenshots; unterscheide unbeholfenes Aussehen von getestetem Abschneiden oder unzugänglichen Optionen.
• Verwende keine allgemeinen Ergebnisse wie „Abstände verbessern" ohne Ort, Konsequenz und empfohlene Änderung.
• Behandle keine statischen Screenshots als interaktive Tests. Führe immer den entsprechenden Belegnachweis (V, T, C, H, U) auf.
• Vermische nicht heuristische Überprüfung, automatisierte Prüfungen und die Beobachtung echter Personen: Alle liefern unterschiedliche Beweise.
• Wenn Quelldaten, Screenshots oder Code unzureichend sind, nenne die Einschränkung und gib einen engen nächsten Test an.

Standardbericht

1. Urteil: Ein Absatz, der die Eignung für die genannte Aufgabe beschreibt; schließe ein, was funktioniert.
2. Priorisierte Ergebnisse: Geordnet nach Schweregrad und Benutzerauswirkung; jedes Ergebnis folgt Ort -> Belegmarkierung -> Konsequenz -> Korrektur -> Überprüfung.
3. Beibehalten: Wichtige Stärken, die nicht versehentlich zurückgesetzt werden sollten.
4. Unbekannte / Tests: Trenne unsichere Produktentscheidungen von visuell nachweisbaren Problemen.
5. Falls Änderungen vorgenommen wurden: Geänderte Artefakte, tatsächliche Prüfungen und nicht verifizierte Zustände.

Verwende die Kurzform für einfache Screenshot-Kritiken. Lass nicht zu, dass eine formale Vorlage die nützliche Antwort verdeckt.

Referenzdokumente laden

• review-heuristics.md: bedingte Inspektionsrubrik und häufige Fehlermuster.
• browser-review.md: browserbasierte Aufgabenprotokolle, Ansichtsfenster- und Barrierefreiheits-Smoke-Tests, Beweisregeln.
• reporting-and-evaluation.md: Schweregrad, Belegkennzeichnungen, konkrete Beispiele, Überarbeitungen vergleichen.