Was macht UI-Audit – Schnittstellen- und Interaktionsprüfung?
Design-Standard: Minimalismus + Animierte Erzählung + Minimale Textmenge.
Kernprinzip: Wo immer möglich, visuell statt Text; wo immer möglich, Animation statt Hinweis; wenn Text notwendig, so wenig wie möglich.
Zugehörige Skripte
scripts/scan-ui.sh [VERZEICHNIS]– Nur-Lese-Automatische Prüfung auf Textsymbole, vage Button-Beschriftungen, hartcodiertes Chinesisch, statische Ladezustände, undefinierte CSS-Klassen und andere häufige UI-Probleme.
Schritt 0: UI-Basisprüfung (muss vor jeder Prüfung durchgeführt werden)
Navigationsbasis
□ Der Benutzer kann von jeder Seite zur Startseite/Hauptseite zurückkehren
□ Der Benutzer kann von der Detailseite zur Listenseite zurückkehren
□ Der Benutzer kann von der Listenseite zum Erstellungs-/Neuanlagenprozess gelangen
□ Aktuelle Position geht nach Seitenaktualisierung nicht verloren
Statusbehandlungsbasis
□ Jeder Datenladevorgang hat einen Ladezustand (Skeleton/Spinner)
□ Jeder API-Aufruf hat einen Fehlerzustand (für den Benutzer sichtbare Fehlermeldung)
□ Jede Liste hat einen Leerzustand (freundlicher Hinweis bei keinen Daten + Handlungsaufforderung)
□ Formularübermittlung hat einen deaktivierten Zustand (verhindert doppelte Übermittlung)
Authentifizierungsbasis
□ Die Anmeldeseite hat einen Einstiegspunkt für "Registrierung"
□ Die Registrierungsseite hat einen Einstiegspunkt für "Anmeldung"
□ Nach der Anmeldung wird zu einer sinnvollen Seite weitergeleitet (kein weißer Bildschirm)
□ Nach dem Abmelden wird der Status gelöscht
□ Bei Token-Ablauf erfolgt automatische Weiterleitung zur Anmeldeseite
Wenn die Basis nicht bestanden wird, zuerst Basis beheben, keine andere UI-Prüfung durchführen.
Designphilosophie
Minimalismus
□ Jede Seite hat nur einen visuellen Fokus
□ Weißraum ist Teil des Designs
□ Nicht mehr als 2 Primärfarben + 1 Akzentfarbe
□ Nicht mehr als 1 Schriftart
□ Kein Schatten, kein Verlauf, kein Radius über 4px
□ Abstände in Vielfachen von 8px/16px/24px/32px
Animierte Erzählung
□ Jede Zustandsänderung hat einen Übergangsanimation (150–300 ms)
□ Listeneinträge erscheinen mit Stagger-Animation (Intervall 30–50 ms)
□ Button-Klick hat Druckrückmeldung (scale: 0.98)
□ Ladevorgang mit Skeleton, keinem statischen Platzhalter
□ Fehler mit Schüttelanimation oder Farbwechsel, keinem Dialog
□ Erfolg mit kurzer Hervorhebungsanimation, keinem Toast
Minimale Textmenge
□ Button-Text nicht länger als 4 Zeichen
□ Symboltasten ohne Text (Tooltip verwenden)
□ Kein "Bestätigen", "Abbrechen" usw. (durch "Speichern", "Verwerfen" ersetzen)
□ Fehlermeldungen nicht länger als 10 Zeichen
□ Navigationseinträge nicht länger als 2 Zeichen + Symbol
Keine Textzeichen/Symbole
□ Kein → ← ↑ ↓ (Pfeilsymbole verwenden)
□ Kein × (Schließen-Symbol verwenden)
□ Kein + - (Hinzufügen/Entfernen-Symbole verwenden)
□ Kein > < (Chevron-Symbole verwenden)
□ Kein ✓ ! (Check/Alert-Symbole verwenden)
□ Kein ~ (Visuelle Trennlinien verwenden)
□ Kein % (Fortschrittsbalken oder Ring verwenden)
Prüfliste
1. Textzeichen-Prüfung (höchste Priorität)
Führen Sie scripts/scan-ui.sh zur automatischen Prüfung aus, dann bestätigen Sie manuell, ob jedes Element durch ein Symbol ersetzt werden muss.
2. Systemsymbol-Prüfung
□ Häufige Aktionssymbole vollständig: speichern / löschen / bearbeiten / pfeil-links / x (schließen)
□ Navigationssymbole vollständig: suche / plus / herunterladen / hochladen / externer-link
□ Alle Symbole einheitlicher Stil (Linie oder gefüllt, eine der beiden)
□ Symbolgröße einheitlich (16px Aktion, 24px Navigation, 32px Leerzustand)
□ Symbole stammen aus derselben Symbolbibliothek (z. B. Lucide / Heroicons / Phosphor), keine Mischung
3. Animationsprüfung
□ Seitenwechsel hat Übergangsanimation (Überblenden/Schieben)
□ Listeneinträge erscheinen mit Stagger-Animation
□ Button-Klick hat Druckrückmeldung
□ Ladevorgang mit Skeleton-Animation
□ Modal/Dropdown haben Aufklapp-Animation
□ Langlaufende Vorgänge haben Fortschrittsanimation
Verboten: Drehender Spinner länger als 2 Sekunden, blinkende Labels, unendliche Schleifen-Animationen, rechenintensive Animationen.
4. i18n-Vollständigkeit
□ Alle für den Benutzer sichtbaren Texte verwenden die t()-Funktion
□ Keine hartcodierten chinesischen Zeichenfolgen (außer in Übersetzungsdateien)
□ Fehlermeldungen verwenden i18n-Schlüssel
□ aria-label verwendet i18n
5. CSS-Konsistenz
□ Alle im JSX referenzierten CSS-Klassen sind definiert
□ Keine ungenutzten CSS-Klassen
□ z-index-Ebenen konsistent (Modal: 200, Drawer: 100, Hintergrundüberlagerung: 99, Toast: 300)
□ Verwendung von CSS-Variablen oder Designfarben, keine hartcodierten Hex-Werte
□ Kein !important (es sei denn mit klarem Grund)
6. Tote-Code-Prüfung
□ Alle Komponentendateien werden von mindestens einer anderen Datei importiert
□ Keine Dateien mit gleichem Namen (doppelte Komponenten in verschiedenen Verzeichnissen)
□ Keine ungenutzten Importe
7. Zustandsbehandlung
□ Jeder Datenladevorgang hat einen Ladezustand
□ Jeder API-Aufruf hat einen Fehlerzustand
□ Jede Liste hat einen Leerzustand
□ Formularübermittlung hat einen deaktivierten Zustand
□ Langlaufende Vorgänge haben Unterstützung für Abbrechen/Stoppen
8. Navigationsablauf
□ Alle Routen haben entsprechende Seitenkomponenten
□ Geschützte Routen haben Auth-Guard
□ 404 hat einen freundlichen Fallback-Seite
□ Brotkrümelnavigation/Zurück-Button funktionieren korrekt
□ Externe Links werden in neuem Tab geöffnet
9. Responsivität & Barrierefreiheit
□ Mobile Ansicht läuft nicht über
□ Alle interaktiven Elemente haben aria-label
□ Tastaturbedienbar (Tab-Navigation, Escape zum Schließen, Enter zum Bestätigen)
□ Modalfenster/Panels haben Focus Trap
□ Farbkontrast entspricht WCAG AA
Arbeitsablauf
Phase 1: Automatische Prüfung
Führen Sie scripts/scan-ui.sh aus, sammeln Sie die Ergebnisse. Konzentrieren Sie sich auf: Textsymbole, zu lange Button-Texte, fehlende Animationen, hartcodiertes Chinesisch, undefinierte CSS-Klassen.
Phase 2: Manuelle Validierung
Überprüfen Sie Seite für Seite anhand der Designphilosophie und der Prüfliste. Verwenden Sie Playwright, um Bildschirmfotos jeder Seite zu Vergleichszwecken zu erstellen.
Phase 3: Reparatur
Reparieren Sie nach Priorität:
- Ersetzen von Textsymbolen durch Symbole
- Textvereinfachung
- Animationen ergänzen
- CSS-Klassen ergänzen
- i18n ergänzen
- Löschen von totem Code
- Zustandsbehandlung
- Navigationsablauf
Phase 4: Regressionsvalidierung
Führen Sie nach der Reparatur erneut die automatische Prüfung aus, um sicherzustellen, dass keine neuen Probleme aufgetreten sind.
Beziehung zu polish-loop-v2
- polish-loop-v2: Allgemeines Code-Review (Logik, Sicherheit, Leistung, Laufzeit)
- ui-audit: Konzentriert sich auf Frontend-UI und Benutzererfahrung
Parallele Ausführung, gemeinsame Basisprüfung. Probleme aus ui-audit haben höhere Priorität als solche aus polish-loop-v2.