design-product-experiencelisted

# Design Product Experience Validate what users will see and do without prematurely locking the production architecture. ## Confirm the boundary 1. Read project instructions, `THE-FIRST.md`, accepted requirements, existing designs, design-system sources, current UI, and relevant feedback rules. 2. Confirm the requirement phase is accepted before producing implementation-ready experience decisions. For discussion-only exploration, keep proposals explicitly unaccepted. 3. Identify conflicts between requirements, designs, existing behavior, and component-library constraints. Ask the user to resolve material product conflicts. 4. Reuse established visual language and interaction patterns unless the accepted requirement calls for change. ## Define the experience Cover only the surfaces relevant to accepted scope: - Information architecture, navigation, entry points, and hierarchy. - Primary and secondary user flows. - Screen, page, panel, modal, or command states. - Loading, empty, error, success, partial, disabled, permission, cancellation, and recovery behavior. - Desktop, mobile, responsive, native, keyboard, and assistive-technology expectations. - Content hierarchy, density, typography direction, color direction, and brand cues. - Existing design-system or component-library behavior that must remain usable. - Interaction feedback, destructive confirmations, focus management, and accessibility basics. Describe observable behavior rather than inventing production compone