UX Playbook
Erstellen Sie Benutzeroberflächen, die für das Unternehmen korrekt, einfach zu bedienen und konsistent sind. Mantine liefert die Komponenten; dieses Playbook sagt Ihnen, wann Sie welche verwenden, welche Zustände ein Bildschirm benötigt und wie Sie das Ergebnis überprüfen. Lesen Sie nur die Seiten, die Ihre Aufgabe benötigt.
Rangfolge
Wenn Quellen sich widersprechen, hat die höhere Vorrang:
- Geschäftsanforderungen: die Spezifikation, das Ticket oder die Anweisung des Verantwortlichen. Ändern Sie niemals eine stillschweigend.
- Die eigenen Regeln des Produkts:
AGENTS.md/CLAUDE.md, seine UX- und Design-Dokumente, seine bestehenden Komponenten. - Dieses Playbook.
- Mantines Dokumentation und Vorgaben.
Wenn 2 und 3 sich widersprechen, folgen Sie 2. Wenn Sie glauben, dass 2 oder 1 falsch ist, folgen Sie ihm trotzdem und reichen Sie einen UX-Vorschlag ein.
Suchen Sie vor der UI-Arbeit nach den UX-Regeln des Produkts (durchsuchen Sie die Repo-Dokumente nach "UX", "UI", "Design", "Panel"). Wenn es keine gibt, entwerfen Sie sie mit der Produktkurzvorlage und schlagen Sie den Entwurf im Plan oder PR vor, wobei jede Annahme mit [Annahme] gekennzeichnet ist.
Wählen Sie die Stufe
| Stufe | Die Änderung | Was Sie tun |
|---|---|---|
| S | Kleine Änderung auf einem bestehenden Bildschirm: ein Feld, ein Button, eine Nachricht, eine Spalte | Lesen Sie die Seite für die Komponente, die Sie berühren. Führen Sie deren Checkliste aus. Machen Sie Screenshots, wenn sich das Layout geändert hat. |
| M | Ein neuer Bildschirm, Dialog oder ein neues Formular, oder eine große Änderung daran | Schreiben Sie zuerst eine kurze UX-Spezifikation. Bauen Sie es. Führen Sie die visuelle Prüfung durch. Überprüfen Sie es selbst mit der Bewertungsmatrix. |
| L | Ein neuer Ablauf über mehrere Bildschirme, ein neuer Funktionsbereich oder eine Änderung der Navigation | Erstellen Sie eine Recherchenotiz mit 2–3 Optionen. Bauen Sie die sichere Option A. Behandeln Sie dann jeden Bildschirm als Stufe M. |
Details und Ergebnisse für jede Stufe: Workflow.
Finden Sie die Seite
| Sie entscheiden über … | Lesen Sie |
|---|---|
| Seitenstruktur, Hierarchie, Abstände, responsives Layout | decisions/layout |
| Buttons, primär vs. sekundär, Symbol-Buttons, Aktionsmenüs | decisions/actions |
| Modal vs. Drawer vs. Popover vs. inline, Tooltips | decisions/overlays |
| App-Navigation, Tabs, Breadcrumbs, Stepper, Paginierung, Link vs. Button | decisions/navigation |
| Tabellen, Listen, Karten, Status-Label, Daten, langer Text | decisions/data-display |
| Toasts, Alarme, Banner, Inline-Nachrichten | decisions/feedback |
| Welches Eingabeelement für eine Auswahl: Checkbox, Schalter, Radio, Segmentierte Steuerung, Select, Combobox, Chips | decisions/selection |
| Formulare, Label, Validierung, Pflichtfelder | patterns/forms |
| Speichern-Buttons, Auto-Speichern, ungespeicherte Änderungen | patterns/saving |
| Noch nichts anzuzeigen, keine Ergebnisse | patterns/empty-states |
| Warten auf Daten oder auf den Abschluss einer Arbeit | patterns/loading |
| Erweiterte Optionen, "mehr anzeigen", Details bei Bedarf | patterns/progressive-disclosure |
| Einführung einer Funktion, erster Start, Hinweise | patterns/feature-onboarding |
| Backend ausgefallen, offline, teilweiser Fehler, fehlende Berechtigung | patterns/degraded-experiences |
| Löschen, Zurücksetzen, Widerrufen, Überschreiben | flows/destructive-actions |
| Label, Button-Text, Fehlertext, Leerzustands-Text | writing |
| Tastatur, Fokus, Label, Kontrast, ARIA | accessibility |
| Nachschlagen einer Mantine-API, Theme-Tokens, Versionen | mantine |
| Der Grund für eine Regel | principles |
Immer
- Verwenden Sie die vorhandenen Komponenten des Produkts und Mantine, bevor Sie eigene schreiben. Verwenden Sie eine Komponente pro Aufgabe.
- Geben Sie jeder Datenansicht ihre Lade-, Leer- und Fehlerzustände. Geben Sie jeder Aktion einen ausstehenden Zustand und ein Ergebnis.
- Behalten Sie eine primäre Aktion pro Ansicht bei. Sekundäre Aktionen sind dezenter. Seltene Aktionen kommen in ein Menü.
- Eine Aktion, die derzeit nicht verfügbar ist, bleibt sichtbar und erklärt warum, in Text, den der Benutzer per Tastatur und Touch erreichen kann, nicht nur in einem Tooltip. Bevorzugen Sie ein inaktives Aussehen (
data-disabled) gegenüber demdisabled-Attribut, und deaktivieren Sie niemals einen Submit-Button: Aktionen. - Bestätigen Sie oder erlauben Sie das Rückgängigmachen für alles, was Daten zerstört. Verlieren Sie niemals die Eingabe des Benutzers bei einem Fehler.
- Jedes Eingabefeld hat ein sichtbares Label. Bedeutung wird niemals allein durch Farbe vermittelt. Alles ist per Tastatur erreichbar.
- Überprüfen Sie das Ergebnis bei Telefonbreite und Desktop-Breite, in hell und dunkel: visuelle Prüfung.
- Beispiele hier verwenden wörtliche englische Zeichenfolgen. Verwenden Sie stattdessen die i18n des Produkts.
Wenn Sie denken, dass es besser sein könnte
Sie dürfen und sollten bessere Abläufe und Komponenten vorschlagen. Die Regel ist: Bauen Sie die sichere Voreinstellung, hängen Sie den Vorschlag an:
- Bauen Sie das, was die Spezifikation verlangt, unter Verwendung der hier beschriebenen Muster.
- Fügen Sie Ihre Idee als UX-Vorschlag im Plan oder PR im festgelegten Format hinzu.
- Halten Sie inne und fragen Sie vor dem Bauen nur, wenn die Spezifikation Daten verlieren, ein Geheimnis preisgeben, einen Benutzer blockieren würde, der auf eine Tastatur oder einen Screenreader angewiesen ist, oder sich selbst widerspricht.
Bericht
Schließen Sie jede UI-Aufgabe mit einem Abschnitt UX-Notizen im PR oder Bericht ab:
## UX-Notizen
- Stufe: M – neuer Tab "Mods"
- Zustände: Laden ✓ Leer ✓ Fehler ✓ deaktiviert-mit-Grund ✓
- Screenshots: 1280 hell/dunkel, 390 hell/dunkel (angehängt)
- Bewertungsmatrix: alle bestanden; n.v.: destruktiv (keine)
- Annahmen: [Annahme] Mods-Liste ist kurz (< 50), daher keine Paginierung
- UX-Vorschläge: 1 (siehe unten)