casoon UX Patterns
Patterns für Interaktionsverhalten und UI-Zustände — nicht für Aussehen (dafür [[ui-design]]/[[frontend-design]]) oder Bewegung (dafür [[motion-design]]).
Progressive Disclosure
- Warum: Reduziert kognitive Last, indem Komplexität erst bei Bedarf sichtbar wird.
- Wann: komplexe Formulare, Settings mit Advanced-Optionen, Erstnutzer-Flows.
- Typische Fehler: alles hinter einem "Mehr anzeigen" verstecken, das nie geöffnet wird; wichtige Pflichtfelder verstecken.
- Umsetzung: Standardansicht zeigt die 80%-Fälle, "Erweitert"/"Mehr Optionen" klappt den Rest auf, State bleibt nach Interaktion erhalten (kein Re-Collapse beim nächsten Render).
Empty States
- Warum: Ein leerer Bildschirm ohne Erklärung wirkt wie ein Fehler, nicht wie ein Ausgangspunkt.
- Wann: erster Login, leere Listen/Suchergebnisse, nach Filterung ohne Treffer.
- Typische Fehler: nur "Keine Daten vorhanden" ohne Handlungsaufforderung; derselbe Empty State für "noch nie befüllt" und "gefiltert, 0 Treffer" — das sind unterschiedliche Situationen mit unterschiedlicher CTA.
- Umsetzung: kurzer Erklärtext + primäre Handlung (z. B. "Ersten Eintrag anlegen"), bei Filterung: "Filter zurücksetzen" statt Anlege-CTA.
Onboarding-Flows
- Warum: Erste Minuten entscheiden über Aktivierung.
- Wann: neue Nutzer, neues Feature mit Erklärungsbedarf.
- Typische Fehler: Tour mit 8+ Tooltip-Schritten, die niemand zu Ende klickt; Onboarding blockiert die eigentliche Nutzung (Modal-Zwang).
- Umsetzung: aufgabenbasiert statt Tour-basiert — zeigen, was als Nächstes zu tun ist, nicht alles auf einmal erklären. Überspringen muss immer möglich sein.
Microcopy
- Warum: Button-/Fehler-/Leerzustand-Texte sind die am häufigsten gelesenen Wörter im Produkt.
- Wann: überall — Buttons, Tooltips, Fehlermeldungen, Bestätigungen.
- Typische Fehler: generisches "Error occurred" / "Erfolgreich"; Button-Label beschreibt nicht die Handlung ("OK" statt "Löschen bestätigen").
- Umsetzung: Verb + Objekt im Button ("Änderungen speichern", nicht "Speichern"), Fehlermeldungen sagen was schiefging UND was zu tun ist.
Ladezustände
- Warum: Wahrgenommene Geschwindigkeit ≠ tatsächliche Geschwindigkeit.
- Wann: jede asynchrone Operation über ~300ms.
- Typische Fehler: Spinner für Inhalte mit bekannter Struktur (Skeleton wäre passender); Layout-Sprung wenn Content nachlädt.
- Umsetzung: < 300ms kein Indikator nötig, 300ms–2s Skeleton/Spinner, > 2s zusätzlich Fortschritt/Kontext ("Wird generiert…"). Skeleton reserviert den finalen Platz, keine Layout-Shifts.
Error States
- Warum: Fehler sind der Moment mit dem höchsten Frustrationspotenzial — hier entscheidet sich Vertrauen.
- Wann: Formularvalidierung, fehlgeschlagene Requests, 404/500.
- Typische Fehler: technische Fehlermeldung 1:1 durchreichen (Stacktrace/HTTP-Code an Endnutzer); Fehler ohne Recovery-Pfad.
- Umsetzung: menschliche Sprache, konkrete nächste Handlung ("Erneut versuchen", "Support kontaktieren"), Formularfehler inline am Feld, nicht nur als Sammel-Banner oben.
Navigation vereinfachen
- Warum: Jede zusätzliche Ebene/Option erhöht Entscheidungsaufwand.
- Wann: IA-Entscheidungen, Hauptnavigation, Filter-/Kategorie-Strukturen.
- Typische Fehler: mehr als 7±2 Hauptpunkte; Navigation, die Systemstruktur statt Nutzerintention abbildet.
- Umsetzung: nach Nutzerzielen benennen, nicht nach internen Modulnamen; aktueller Standort immer erkennbar (Breadcrumb/aktiver State).
User Flows optimieren
- Warum: Jeder zusätzliche Schritt kostet Konversion.
- Wann: Checkout, Signup, mehrstufige Formulare.
- Typische Fehler: Schritte addieren ohne zu prüfen ob sie zusammenlegbar sind; Fortschrittsanzeige fehlt bei mehr als zwei Schritten.
- Umsetzung: Schritte zählen und jeden rechtfertigen, Fortschrittsindikator bei Mehrschritt-Flows, Zurück-Navigation ohne Datenverlust.
Gotchas
- Diese Patterns beschreiben Verhalten und Zustände, nicht Look — die visuelle Umsetzung folgt [[ui-design]] und [[frontend-design]], Übergänge zwischen Zuständen folgen [[motion-design]].
- Empty State und "0 Suchergebnisse" sind unterschiedliche States mit unterschiedlicher CTA — nicht zusammenlegen.
- Onboarding-Erfolg misst sich an Aktivierung, nicht an Tour-Abschluss-Rate.