ui-designlisted

# UI Design ## Iron Law `START FROM THE USER TASK AND HIERARCHY; EVERY ELEMENT EARNS ITS PLACE.` ## When to Use - Building or changing any user-facing UI surface: layout, components, design systems, typography, color, motion, responsive behavior, or frontend structure. Simple forms, single-page apps, and "just basic styling" all qualify; the polished-product threshold is too high a bar. ## When NOT to Use - Backend API shape; use `api`. - Accessibility-specific implementation or review; use `accessibility`. - Frontend runtime debugging or tests only; pair with `proof` and browser tooling. - Performance profiling beyond UI design choices; use `performance`. ## Core Ideas 1. One screen has one primary action and a clear information order. 2. Use a small token system for spacing, type, color, radius, and motion. Apply tokens consistently; avoid stray one-off values. 3. Accessibility is a design input, not a later review pass. Design keyboard, focus, contrast, reduced motion, touch targets, and screen-reader flow up front. 4. Component APIs express intent and state, not implementation convenience. 5. Modern CSS should reduce JavaScript and layout hacks when browser support allows it. ## Workflow 1. Identify the user, task, device constraints, and primary action. Choose existing framework/design-system patterns before inventing new ones. 2. Define hierarchy, layout, states, empty/error/loading behavior, and responsive rules. 3. Apply tokens cons