ux-patterns
UX Patterns
How an interface should behave, for whoever is writing it. Scoped to interaction: states, feedback, forms, and the cognitive-load laws behind layout decisions.
| File | Read it for |
|---|---|
| This file | Web-first behavior rules |
references/accessibility.md |
The conformance wiring every state needs. Read it alongside any state you build |
references/mobile.md |
What changes on a phone |
For a CLI or a terminal UI, load the terminal-ux skill if it is installed. Exit codes, stream discipline, TTY detection, and terminal screen-reader behavior have their own canon and are not covered here.
Not covered here: type scales, color palettes, visual style, brand. Your design-system skill owns those. A rule that needs a specific palette or type scale is out of scope, so point at that skill rather than inventing values. Contrast appears in the accessibility reference as a conformance floor, never as a palette.
Treat these as directional. A repo's established pattern wins over a rule here; match the surrounding code. Two markers override that:
- WCAG x.x.x (Level) means a published conformance criterion. Not a preference, and not something a repo convention overrides.
- A named law here is a label, and what sits under each one differs. Jakob's was coined by Nielsen as a summary of his own heuristics. Tesler's traces to an interview and carries a published counter-argument. Hick's is real experimental work, measuring something narrower than its usual application. Each section states what its law actually rests on; naming one settles nothing.