ui-ux-design-principleslisted

# ui-ux-design-principles Canon for decisions about the USER's experience. The third of the design-principles trio: - `software-design-principles` – how a unit of code is written (SOLID, DRY, clean code). - `architectural-design-principles` – how the system is shaped (layers, twelve-factor, fitness functions). - **`ui-ux-design-principles`** – how the product looks, behaves, and is navigated, kept testable. The project's `design-guide.{md,json}` and `ia.md` are the per-project *instantiation* of this canon, the way `architecture.json` instantiates the layering rules. Markdown only, no scripts: consulted, not invoked. Like the architecture canon, it points each rule at how it's enforced (the E2E/Playwright layer, the design-adherence check against `design-guide.json`, a11y checks). A rule no test defends is advisory; one a check defends is part of the build. ## When to use - The `consort` UX Designer imports it to author `design-guide.{md,json}` + `ia.md` and define the adherence gate. - The Driver imports it when building UI that must adhere to the design guide. - You're reviewing a user-facing change and need a shared vocabulary (heuristics, hierarchy, accessibility) rather than taste. - You're choosing how the UI is built and need the testability rules (framework choice, stable seams). ## UX review checklist (mandatory before promote/merge) Confirm each row before declaring the design done. A blank row is fine when scope justifies it; an unconsidered row is a smell.