markhougaard/ux-laws

Gesetze der UX – Index und Protokoll

Diese Datei wählt den Modus aus, wählt aus, welche der 30 Gesetze gelten, und definiert, wie sie zusammen verwendet werden und wie berichtet wird. Jedes Gesetz lebt in einer eigenen Datei unter references/, benannt wie in den Tabellen unten (fitts-law → references/fitts-law.md). Öffne nur die, die du auswählst.

Wenn der Benutzer ein Gesetz benennt („Überprüfen Sie dieses Formular nach dem Postelschen Gesetz“), öffne nur diese Referenz und verwende sie in dem von ihm gewünschten Modus. Überprüfungen folgen dennoch Abschnitt 5 hier.

0. Dateien und Umgebung

Dieses Skill funktioniert in jedem Agenten, der Dateien lesen kann. Es ist nicht von bestimmten Werkzeugen abhängig.

• Pfade in jeder Datei dieses Skills, einschließlich der Referenzen, sind relativ zu dem Verzeichnis, das diese SKILL.md enthält. references/fitts-law.md bedeutet immer <Skill-Verzeichnis>/references/fitts-law.md, auch wenn es in einer anderen Referenzdatei vorkommt.
• Wenn du die Referenzdateien nicht öffnen kannst (z. B. weil dieser Text ohne den zugehörigen Ordner in einen Prompt eingefügt wurde), sage das und frage nach den benötigten Gesetzesdateien. Führe keine Prüfungen aus dem Gedächtnis durch: Die Prüf-IDs, Schweregrade und Beweisarten sind nur in diesen Dateien definiert.
• Die Beweislage hängt davon ab, was du überprüfen kannst. Wenn du keine Bilder, Screenshots und Mockups sehen kannst, zählen diese für dich nicht als static Beweise; überprüfe den verfügbaren Text oder Code und weise auf der Umfangszeile darauf hin. Wenn du das Artefakt nicht ausführen kannst, sind interactive und runtime außerhalb des Rahmens, es sei denn, der Benutzer liefert Aufzeichnungen oder Messungen.

1. Modus auswählen

Modus	Verwendung	Ergebnis
Beraten	Es existieren nur ein Ziel, eine Kurzbeschreibung, eine Problemstellung, ein Roadmap-Item oder ein frühes Konzept.	Eine kurze Steuerungsanleitung: die wichtigsten Gesetze hier, vorhergesagte Risiken, Fragen, die das Team beantworten muss, und jetzt zu treffende Entscheidungen.
Bauen	Ein Design oder eine Implementierung ist in Arbeit und benötigt eine Referenz.	Gezielte Anleitung für die betreffende Komponente oder den Bildschirm, abgeleitet aus Modus 2 der relevanten Gesetze, mit konkreten Werten, sofern vorhanden.
Überprüfen	Ein fertiges Design, ein Prototyp, ein Satz von Screenshots, eine URL oder ein Code-Diff steht vor dem Commit.	Ein strenger Ergebnisbericht mit Schweregraden, Beweisen, Korrekturen und einem Urteil.

Wenn die Anfrage dies nicht angibt, leite es aus der Eingabe ab: ein Ziel → Beraten; laufende Arbeit → Bauen; ein fertiges Artefakt → Überprüfen. Falls immer noch unklar, stelle eine Frage.

2. Gesetze auswählen

Öffne nicht alle 30 für jede Aufgabe. Wähle nach Situation aus und füge dann diejenigen hinzu, deren Auslöser mit dem übereinstimmen, was du siehst.

Grundlage für jede UI-Überprüfung (immer ausführen): fitts-law, jakobs-law, cognitive-load, law-of-proximity, law-of-similarity, selective-attention, cognitive-bias. Füge doherty-threshold hinzu, wenn das Artefakt interaktiv ist.

Nach Situation:

Situation	Öffnen
Formulare, Dateneingabe, Anmeldung	postels-law, working-memory, chunking, law-of-proximity, parkinsons-law, goal-gradient-effect
Navigation, Menüs, Informationsarchitektur	hicks-law, serial-position-effect, mental-model, jakobs-law, chunking, pareto-principle
Dashboards, datendichte und Expertenwerkzeuge	cognitive-load, chunking, law-of-common-region, law-of-pragnanz, flow, pareto-principle
Datenvisualisierung und Diagramme	law-of-pragnanz, law-of-uniform-connectedness, law-of-similarity, von-restorff-effect
Onboarding, erste Schritte, Hilfe	paradox-of-the-active-user, goal-gradient-effect, zeigarnik-effect, cognitive-load, mental-model
Preise, Tarife, Kataloge, Checkout	choice-overload, hicks-law, cognitive-bias, von-restorff-effect, serial-position-effect, peak-end-rule
Benachrichtigungen, Warnungen, Status	selective-attention, von-restorff-effect, flow, zeigarnik-effect
Mobil und Touch	fitts-law, law-of-proximity, serial-position-effect, doherty-threshold
Leistung, Laden, asynchrone Arbeit	doherty-threshold, goal-gradient-effect, peak-end-rule, flow
Redesigns und Migrationen	jakobs-law, mental-model, serial-position-effect, aesthetic-usability-effect
Automatisierung, KI und intelligente Funktionen	teslers-law, mental-model, cognitive-bias, doherty-threshold
Umfang, Priorisierung, Roadmap	pareto-principle, occams-razor, teslers-law, hicks-law
Visuelles Design und Designsystem-Arbeit	aesthetic-usability-effect, law-of-similarity, law-of-proximity, law-of-common-region, law-of-pragnanz, von-restorff-effect
Fehler, Misserfolge und Enden	peak-end-rule, postels-law, selective-attention, mental-model

Folge den Verwandten Gesetzen jedes geöffneten Gesetzes nur, wenn ein Befund oder eine Frage dieses Gesetz tatsächlich berührt.

3. Beratungsprotokoll

1. Fasse das Ziel, die Benutzer und den Kontext in zwei oder drei Zeilen zusammen. Wenn Benutzer oder Kontext unbekannt sind, sage dies – das ist das erste Risiko.
2. Wähle 3–6 Gesetze aus der Tabelle. Mehr als sechs verwässern die Beratung.
3. Gib für jedes die ein oder zwei Risiken an, die es für dieses Projekt vorhersagt, und die Frage, die das Team beantworten muss. Verwende Modus 1 des Gesetzes als Quelle, aber mache es spezifisch.
4. Liste die jetzt zu treffenden Entscheidungen auf (Budgets, Standardwerte, Konventionen, Betonungsregeln, Messung) und wer sie übernehmen sollte.
5. Markiere Spannungen zwischen Gesetzen, die eine bewusste Wahl erfordern werden (siehe Abschnitt 6).

Halte es auf etwa eine Seite. Ziel ist es, zu lenken, nicht vorzuentwerfen.

4. Bauprotokoll

1. Identifiziere die Komponente, den Bildschirm oder den Ablauf, an dem gearbeitet wird.
2. Öffne die passenden Gesetze und verwende ihre Modus-2-Listen als Referenz, wobei du konkrete Werte zitierst (Zielgrößen, Timings, Kontrastverhältnisse, WCAG-Kriterien).
3. Wenn Anleitungen in Konflikt stehen, sage dies und empfehle eine Lösung für diesen Fall.
4. Führe während des Bauens keine vollständige Überprüfung durch; erwähne ein Problem auf Überprüfungsebene nur, wenn es wahrscheinlich ein Blocker ist.

5. Überprüfungsprotokoll (streng)

Überprüfungen dienen dazu, Probleme vor dem Commit zu stoppen. Strenge Regeln:

• Beweis oder nicht bestanden. Ein Check besteht nur bei positivem Nachweis im Artefakt. Gehe niemals von einem Zustand, einer Größe, einem Timing oder einem Verhalten aus, das du nicht sehen kannst.
• Nicht verifizierbar bedeutet NICHT VERIFIZIERT, nicht bestanden. Nenne, was du bräuchtest (einen Fehlerzustand, eine Messung, reale Daten, ein Gerät, den Code).
• Der Umfang wird angegeben, nicht impliziert. Ein Urteil deckt nur die Beweise ab, die du erhalten hast. Checks, die eine Art von Beweis benötigen, die du nicht erhalten hast, werden als außerhalb des Rahmens aufgeführt, damit eine Screenshot-Überprüfung nicht als vollständig bestanden gelesen werden kann.
• Mache keine Zugeständnisse. Kein Lob als Füllstoff, kein „insgesamt sieht gut aus“, keine Herabstufung des Schweregrads aufgrund von Fristen oder bereits aufgewendetem Aufwand.
• Sei spezifisch. Jeder Befund nennt den Ort (Bildschirm, Komponente, Element oder Datei:Zeile), was du beobachtet hast und eine konkrete Korrektur.
• Ein Problem, ein Befund. Wenn mehrere Gesetze dasselbe Problem anzeigen, melde es einmal, liste alle Check-IDs auf und verwende den höchsten Schweregrad.
• Melde saubere Gesetze explizit. Liste auf, welche Gesetze ohne Befunde angewendet wurden, damit die Abdeckung sichtbar ist.

Schritte:

1. Erfasse, was dir zur Verfügung gestellt wurde (Bildschirme, Zustände, Haltepunkte, Code) und was fehlt, und lege den Nachweisumfang fest: welche der folgenden Beweisarten du hast.
2. Wähle die Grundlage plus situative Gesetze aus.
3. Führe jeden Check in der Modus-3-Tabelle jedes ausgewählten Gesetzes durch. Sortiere jeden Check in eine der folgenden Kategorien ein:
   • geprüft – bestanden oder mit einem Befund versehen;
   • nicht verifiziert – seine Beweisart ist im Umfang, aber der Zustand, das Element oder die Messung, die es benötigt, fehlt (z. B. static Umfang, aber kein Fehlerzustandsbildschirm);
   • außerhalb des Rahmens – keine seiner Beweisarten ist im Umfang;
   • nicht anwendbar – das Artefakt enthält nichts, worum es bei dem Check geht (z. B. FIT-1 bei einem reinen Maus-Desktop-Tool). Gib den Grund in wenigen Worten an.
4. Führe Duplikate zusammen, weise Schweregrade zu, schreibe Korrekturen.
5. Gib das Urteil ab, mit seinem Umfang.

Beweisarten

Jeder Modus-3-Check hat eine Beweis-Spalte, die die Arten von Eingaben benennt, die ihn klären können. Wenn mehr als eine aufgeführt ist, reicht eine davon aus.

Art	Was es ist	Typische Eingaben
static	Was in Standbildern der relevanten Bildschirme und Zustände zu sehen ist.	Screenshots, statische Mockups, Designdateien mit Maßen, Ablaufdiagramme
interactive	Was sich erst zeigt, wenn du das Ding bedienst: Tastatur, Fokus, Übergänge, erlebtes Timing, was nach einer Aktion passiert.	Ein klickbarer Prototyp, eine laufende Version, eine URL, eine Bildschirmaufzeichnung
code	Was im Quelltext oder Markup steht: Semantik, ARIA, autocomplete, Trefferflächen, Tokens und eindeutig durch den Quelltext festgelegtes Verhalten (was ein Handler bei einem Fehler tut, ob die Eingabe erhalten bleibt, wohin der Fokus geht).	Ein Diff, Komponentenquelltext, gerendertes DOM
runtime	Messungen auf realistischer Hardware, Netzwerken und Daten.	Leistungsablaufverfolgungen, RUM- oder Laborzahlen
context	Fakten außerhalb des Artefakts: Nutzungsdaten, Forschung, Entscheidungsprotokolle, Geschäftsregeln.	Analysen, Forschungsergebnisse, ein PRD oder ADR, eine Aussage des Teams

Zähle eine Beweisart nur dann als im Umfang befindlich, wenn du sie tatsächlich hast. Die Information, dass der Code existiert, bringt code nicht in den Umfang.

Schweregrad

Schweregrad	Bedeutung
Blocker	Verhindert oder führt in einer Kernaufgabe in die Irre; birgt das Risiko von Datenverlust, finanziellen, Sicherheits- oder Schutzschäden; erfüllt ein WCAG 2.2 AA-Kriterium nicht; oder ist ein täuschendes Muster. MUSS vor dem Commit behoben werden.
Major	Erhebliche Reibung, fehleranfälliges Design oder klare Inkonsistenz mit Konventionen oder dem Designsystem. Vor dem Commit beheben oder explizite Zustimmung durch einen benannten Verantwortlichen mit Nachverfolgung dokumentieren.
Minor	Verfeinerung und Konsistenz. Beheben, wenn der Bereich das nächste Mal bearbeitet wird.

Urteil

Wende die erste Regel an, die zutrifft:

1. Irgendein Blocker → Nicht committen.
2. Ein im Umfang befindlicher Blocker-Check ist NICHT VERIFIZIERT → Blockiert, bis Beweise vorliegen. Nenne den fehlenden Zustand oder die fehlende Messung, die das Team mit den bereits gelieferten Beweisen hätte liefern können.
3. Irgendein Major → Nur committen, wenn jeder Major behoben oder von einem benannten Verantwortlichen akzeptiert wurde.
4. Nur Minor oder keine → Bestanden.

Jedes Urteil trägt seinen Umfang, z. B. Bestanden (static Umfang). Wenn Blocker-Checks außerhalb des Rahmens sind, liste sie in der Urteilszeile mit der jeweiligen benötigten Beweisart auf, z. B. außerhalb des Rahmens: JAK-1 (interactive), SA-2 (interactive), DOH-1 (interactive). Ein Urteil kann nur dann uneingeschränkt sein (nur „Bestanden“), wenn kein Blocker-Check der ausgewählten Gesetze außerhalb des Rahmens oder nicht verifiziert ist. Checks außerhalb des Rahmens ändern nie das Urteil. Sie teilen dem Team mit, was noch nicht überprüft wurde und ob vor der Veröffentlichung eine zweite Prüfung mit mehr Beweisen erforderlich ist.

Berichtsvorlage

## UX-Gesetze-Überprüfung — <Artefaktname>

Überprüft: <was überprüft wurde: Bildschirme, Zustände, Haltepunkte, Dateien>
Nachweisumfang: <static | interactive | code | runtime | context — tatsächlich gelieferte>
Nicht bereitgestellt: <fehlende Zustände oder Beweise>
Angewandte Gesetze: <Codes>
Urteil: <Nicht committen | Blockiert bis Beweise vorliegen | Mit akzeptierten Majors committen | Bestanden> (<Umfang> Umfang)
         außerhalb des Rahmens: <Blocker-Check-IDs mit der jeweils benötigten Beweisart, oder „keine“>

### Blocker
- [BLOCKER] FIT-1, JAK-1 · <Ort> — <Beobachtung> → <Korrektur>

### Majors
- [MAJOR] CL-2 · <Ort> — <Beobachtung> → <Korrektur>

### Minors
- [MINOR] SIM-6 · <Ort> — <Beobachtung> → <Korrektur>

### Nicht verifiziert (im Umfang, Beweise fehlen)
- POS-2 · <was nicht geprüft werden konnte> — benötigt <den spezifischen Zustand oder die Messung>

### Außerhalb des Rahmens
- interactive: JAK-1, SA-2, DOH-1, …
- code: CH-3, PKL-3, …

### Nicht anwendbar
- FIT-1 — <Grund>

### Angewandt ohne Befunde
<Codes>

6. Häufige Spannungen

Spannung	Standardlösung
Hick / Occam (weniger Optionen) vs. Pareto-Long-Tail und Expertenbedürfnisse	Halte kritische, aber seltene Funktionen durch progressive Offenlegung auffindbar; entferne sie niemals allein aufgrund der Nutzung.
Occam (entfernen) vs. Tesler (unreduzierbare Komplexität)	Entferne beiläufige Komplexität; verlagere inhärente Komplexität in das System, mit Sichtbarkeit und Rückgängigmachung.
Jakob (Konvention) vs. Differenzierung	Innovation am Problem, nicht an den Kernsteuerelementen. Abweichungen benötigen einen genannten, getesteten Nutzen.
Von Restorff (Betonung) vs. Ähnlichkeit (Konsistenz)	Ein hervorgehobenes Element pro Ansicht; alles andere konsistent.
Fitts (große, bequeme Ziele) vs. versehentliche Aktivierung	Trenne destruktive Aktionen; füge Rückgängigmachung oder Bestätigung für folgenreiche Aktionen hinzu.
Flow (keine Unterbrechungen) vs. Sicherheitsbestätigungen	Unterbreche nur für folgenreiche, irreversible Aktionen.
Kognitive Belastung (weniger zeigen) vs. Arbeitsgedächtnis (Kontext zeigen)	Zeige den für den aktuellen Schritt benötigten Kontext; verstecke den Rest.
Postel (großzügig akzeptieren) vs. Korrektheit	Großzügig im Format, streng in der Bedeutung; bestätige mehrdeutige folgenreiche Werte.
Goal-Gradient, Zeigarnik, Serial-Position, Von-Restorff als Hebel vs. Benutzerinteresse	Verwende nur für Ergebnisse, die der Benutzer wünscht; siehe cognitive-bias.

7. Alle Gesetze

Wahrnehmung und Aufmerksamkeit

Gesetz	Code	Verwende es für
aesthetic-usability-effect	AUE	visuelle Verfeinerung, erste Eindrücke, Markenausdruck, Interpretation von Usability-Tests und die Kluft zwischen dem Aussehen eines Produkts und seiner Funktionsweise
law-of-common-region	CR	Karten, Panels, Abschnitte, Rahmen, Hintergrundfüllungen, Tabellenzeilen, Formulargruppen und jeden Container, der signalisiert, dass Elemente zusammengehören
law-of-proximity	PRX	Abstände, Layoutdichte, Beschriftungs-Feld-Zuordnung, Gruppierung von Steuerelementen und Inhalten und Abstandsskalen
law-of-pragnanz	PRG	Symbole, Illustrationen, Datenvisualisierungen, Layout-Silhouetten, Logos und alle visuellen Elemente, die auf einen Blick verstanden werden müssen
selective-attention	SA	Benachrichtigungen, Warnungen, Statusänderungen, Banner, Onboarding-Hinweise, Systemmeldungen und das Platzieren von Informationen, die Benutzer nicht übersehen dürfen
law-of-similarity	SIM	visuelle Konsistenz, Stile für Links und Schaltflächen, Komponentenvarianten, Statusfarben, Symbolfamilien und Designsystem-Nutzung