ist-h-i/ui-ux-design

UI/UX Design Werkzeugkasten

Ziel

Schränke die UI-Gestaltung, -Implementierung und -Überprüfung auf das nachgewiesene Benutzerziel, die visuelle Hierarchie und Endbearbeitung, die Aufgabenbenutzbarkeit, die Interaktionssemantik, das Bewusstsein für Konsequenzen und den wiederherstellbaren Zustand ein. Dies ist eine Ausführungsergänzung, kein Lifecycle-Ersatz und kein visuelles Designsystem.

Verwende die kleinste anwendbare Teilmenge. Erfinde keine Personas, Geschäftsprioritäten, Geräteannahmen, Wiederherstellungsgarantien oder Interaktionsverhalten, die die Aufgabe nicht nachweist.

Verwende, wenn

Verwende diese Kompetenz erst, nachdem der generische Auslieferungs-Workflow ausgewählt wurde und die Aufgabe eine benutzersichtbare Schnittstelle ändert oder überprüft, die eines oder mehrere dieser Signale aufweist:

• ein Bildschirm, ein Formular, ein Navigationsfluss, eine Auswahl oder eine primäre Aktion;
• Fokus, ausgewählt, deaktiviert, lädt, Erfolg, Fehler, abgeschlossen oder ein anderer Interaktionszustand;
• folgenreiche oder umkehrbare Benutzeraktionen;
• teilweiser Daten-/Render-Fehler, veraltete oder fehlende Daten, Wiederholung oder Wiederherstellungsverhalten;
• UI-Sprache, deren Wortlaut die Aufgabenerfüllung oder Fehlerbehebung beeinflusst.

Verwende es nicht für Nicht-UI-Arbeiten, rein maschinell verarbeitete Ausgaben oder als Grund, um jedes UX-Problem zu laden. Projektspezifische Marken, Benutzer, Terminologie, kritische Abläufe und Geschäftsregeln bleiben Projektkontext.

Prozess

1. An Nachweisen verankern. Identifiziere das bekannte Benutzerziel, den Nutzungskontext, die erste zu beachtende Information, Aktionsprioritäten, den Abschluss/die nächste Aktion und Einschränkungen. Wähle Dichte und Komposition für diesen Zweck: Ein Vergleichsarbeitsbereich und eine Produkteinführung benötigen unterschiedliche Behandlungen. Bestehende Verträge sind Eingaben, keine Qualitätsobergrenze; überprüfe beobachtete Schwächen im Rahmen. Stoppe nur Entscheidungen, die von folgenreichen fehlenden Fakten abhängen, ohne eine Persona oder einen Workflow zu erfinden.
2. Anwendbare Prinzipien und Muster auswählen. Lese nur die relevanten Abschnitte von references/principles.md, references/decision-patterns.md und references/anti-patterns.md. Zeichne auf, warum sie zutreffen. Behandle Beispiele als Nachweishinweise, nicht als globale Verbote.
3. Komposition konkretisieren. Verbinde Gruppierung, Reihenfolge, Texthierarchie und -umbruch, Ausrichtungsanker, Abstände, Bildmaterial und Steuerungsbeziehungen mit der Aufgabe. Bevorzuge klare Struktur/Status vor dem Hinzufügen von Erklärungen; behalte erforderliche Bedeutung und zugängliche Bezeichnungen bei. Für Japanisch bewerte Bezeichnungen, Ziel-/Ergebnisformulierungen und Feedback in ihrer angezeigten Position und ihrem Zustand, nicht nur anhand der Grammatik; verwende eine verfügbare japanese-expression-Fähigkeit unter den unten stehenden Ermittlungsregeln.
4. Verhalten spezifizieren. Definiere anwendbare Aufforderungen/Bezeichner, Zustandssemantik, sofortiges Feedback, Übergänge, Fokus/aktuellen Zustand, Fortsetzung und äquivalente Interaktionspfade. Markiere nicht anwendbare Belange explizit; erfinde kein Hover-, Drag-, Gesten- oder Bewegungsverhalten.
5. Konsequenzklassen trennen. Unterscheide zwischen Abbruch vor Verpflichtung, Rückgängig nach einer abgeschlossenen umkehrbaren Änderung und Ausgleichsaktion nach einer festgeschriebenen Änderung. Für irreversible oder materiell folgenreiche Aktionen zeige Ziel, Umfang, Konsequenz und Wiederherstellungsgrenze vor der Verpflichtung. Füge keine pauschale Bestätigung für risikoarme, umkehrbare Aktionen hinzu.
6. Fehler eingrenzen. Halte gesunde, autorisierte, semantisch gültige Bereiche und Benutzereingaben nutzbar, wenn ein unabhängiger Bereich ausfällt. Halte ungelöste Fehler im betroffenen Bereich sichtbar, mache Wiederholungen bereichsspezifisch und überprüfe das Ergebnis der Wiederholung. Unterscheide zwischen den Zuständen Laden, legitim leer, fehlend, veraltet, teilweise und vollständig. Ersetze fehlende Daten nicht durch Nullen und lege keine abgeleiteten Aktionen offen, deren Voraussetzungswahrheit unvollständig ist. Erweitere den Block nur, wenn Autorisierungs-, Sicherheits-, Konsistenz- oder Abhängigkeitssemantik dies erfordern.
7. Verfeinern und tatsächliche Darstellung überprüfen. Überprüfe während der Implementierung einen repräsentativen vollständigen Bildschirm, bevor du Steuerelemente polierst, verfeinere dann relevante Komponentendetails, schmale Layouts und Zustände vor der unabhängigen Überprüfung. Beurteile visuelle Endbearbeitung, Aufgabenbenutzbarkeit und funktionales Verhalten getrennt; funktionierende Klicks, gleiche CSS-Werte und kein Überlauf stellen keine Endbearbeitung dar. Übe anwendbare Übergänge, Tastatur/Fokus, tatsächliches Rückgängig, Abbruch vor Verpflichtung, beibehaltene Eingabe und bereichsspezifische Wiederholung. Ein Screenshot unterstützt das statische Erscheinungsbild, nicht die Wiederherstellung oder Zustandswiederherstellung. Verwende die Beobachtungs- und Übergaberegeln in references/ui-capability-contract.md.
8. Verfügbare UI-Fähigkeiten anbinden. Folge references/ui-capability-contract.md für vertragsbezogene, bestehende Vertragsbau- oder direkte UI-Anfragen. Behalte die Prinzipienverantwortung hier, löse externe Fähigkeitsverantwortliche aus der aktiven Umgebung und bewahre die Verbindungen zwischen Vertrag, Implementierung und Nachweisen. Fähigkeits- oder Laufzeitlücken stoppen nur betroffene abhängige Arbeiten und zählen niemals als abgeschlossene Überprüfung.
9. Einschränkungen an den ausgewählten Workflow zurückgeben. requirement-grill, grill-design, controlled-implementation, test-first-verification, Überprüfungs-Gates und finale Merge-Gates behalten ihre Verantwortlichkeiten. Diese Ergänzung schränkt UI-Entscheidungen ein; sie autorisiert keine Implementierung oder Genehmigung von sich aus.

Ausgabe

Gib eine begrenzte Ergänzung im Entscheidungsprotokoll der aktuellen Aufgabe aus. Für eine lokale Anpassung zeichne nur die geänderten Entscheidungen und betroffenen Nachweise auf; erfordere keinen neuen JSON-Vertrag oder eine ausgefüllte Vorlage. Lasse irrelevante Felder weg oder verwende not_applicable: <grund>; fülle sie niemals spekulativ aus.

UX supplement:
  user_context:
    user_goal:
    usage_context:
    known_constraints:
    capability_or_environment_considerations:
  task_model:
    page_or_flow_goal:
    primary_action:
    completion_state:
    next_action:
  information_model:
    required_information:
    secondary_information:
    omit:
    language_required_for_clarity:
  interaction_model:
    affordances_and_signifiers:
    state_semantics:
    action_feedback:
    transition_behavior:
    consistency_expectations:
    direct_manipulation:
    equivalent_interaction_paths:
  inclusion_constraints:
    single_cue_dependencies_to_avoid:
    error_prevention:
    recovery_paths:
    input_and_effort_constraints:
  resilience_and_consequences:
    action_reversibility_and_limits:
    pre_commit_consequences:
    failure_boundaries_and_dependencies:
    safe_remaining_content_and_actions:
    partial_failure_and_freshness_feedback:
    scoped_retry_and_recovery_refs:
    blocking_conditions:
  applicable_patterns:
  anti_patterns:
  implementation_constraints:
  verification_scenarios:
  stop_conditions:

Jedes Verifikationsszenario benennt den inspizierten Zustand und die beobachtbare Beziehung. Füge für Interaktionen Aktion/Eingabe, erwarteten sichtbaren und zugrunde liegenden Zustand und anwendbares Wiederherstellungs-/Fortsetzungsergebnis hinzu. Behalte Designentscheidungen im bestehenden Informationsmodell und Implementierungseinschränkungen bei, anstatt ein weiteres Schema zu erstellen.

Austrittskriterien

• Die Ergänzung ist nur verbunden, weil der aktuelle Nachweis ein UI-Signal enthält.
• Benutzer-, Produkt-, Marken- und Geschäftsannahmen sind hergeleitet oder als unbekannt markiert.
• Die primäre Aufgabe und die nächste Aktion sind klarer, ohne erforderliche Semantik zu entfernen.
• Für bewertete UI-Darstellungen haben Komposition und Komponentenendbearbeitung gerenderte Nachweise, die sich von funktionalen Prüfungen unterscheiden; reine Vertragsarbeit spezifiziert Beobachtungskriterien, ohne die Genehmigung des tatsächlichen Bildschirms zu beanspruchen. Ein bestandener Vertrag entlässt nicht von beobachteter Rauheit.
• Dynamische Behauptungen haben interaktive/statusbezogene Nachweisanforderungen, keine Screenshot-Beweise.
• Umkehrbares, irreversibles, teilweises Fehler- und grundlegendes Blockierungsverhalten werden unterschieden, wenn zutreffend.
• Gesunder Zustand und Benutzereingabe bleiben über unabhängigen Fehler und Wiederholung hinweg erhalten.
• Der generische Workflow und die endgültige Überprüfungsbefugnis bleiben unverändert.