design-ui-uxlisted

# Design UI/UX 1. Establish the product purpose, primary users, core task, platform, content, brand, constraints, and measurable success. For an existing product, inspect its rendered screens, tokens, components, assets, copy, states, interactions, and accessibility before proposing changes. Preserve a coherent local design language unless the task explicitly requires replacing it. 2. Gather evidence before choosing a direction. Prefer supplied references, real content, user research, analytics, the repository's design system, and current platform guidance. Separate observed facts from assumptions. If an unresolved assumption can change information architecture, navigation, a form, or a critical flow, name it and choose the smallest realistic way to test it. Read [design standards](references/design-standards.md), and use [scenario examples](references/scenario-examples.md) when the surface or complexity needs a concrete pattern. Use [source notes](references/sources.md) for provenance or deeper guidance. 3. Scale the process to the work. For a simple view, define one primary task, its main action, representative content, and material feedback states. For multi-screen, form-heavy, data-dense, collaborative, role-based, or safety-critical work, define information architecture, journeys, states and events, roles and permissions, data responsibilities, and recovery before visual refinement. Never substitute polished static screens for a working flow. 4. Resolve the experience b