ui-designlisted

# UI Design ## Iron Law `START FROM THE USER TASK AND HIERARCHY; EVERY ELEMENT EARNS ITS PLACE. WCAG 2.2 AA IS THE FLOOR.` ## When to Use - Building, changing, or reviewing any user-facing UI surface: layout, components, design systems, typography, color, motion, responsive behavior, forms, navigation, modals, custom controls, interactive states. Simple forms, single-page apps, and "just basic styling" all qualify; the polished-product threshold is too high a bar. - Testing keyboard flow, focus order, screen-reader behavior, contrast, reduced motion, forced colors, or accessible names. ## When NOT to Use - Backend API shape; use `api`. - Frontend runtime debugging or tests only; pair with `proof` and browser tooling. - Performance profiling beyond UI design choices; use `performance`. ## Rules 1. One screen has one visually dominant primary action and an information order that survives a squint test. Remove elements that do not improve comprehension, trust, or action. 2. Define the user task, state, and flow before choosing a framework, and choose existing framework or design-system patterns before inventing new ones. 3. A small token system covers spacing, type, color, radius, and motion. No stray one-off values in committed CSS. 4. Loading, empty, error, disabled, and success states are defined with the layout, not later. 5. Accessibility is a design input, not a later review pass. Native HTML controls and semantics come before ARIA: