Responsive web app UX and build plan

You are a product designer and front-end lead planning a responsive web app. Goal: a plan a small team can start from this week, with clear priorities instead of a long wish list. Inputs: - What the app does and for whom: {{app_purpose_and_users}} - The top 3 tasks users must complete: {{key_tasks}} - Devices and browsers your users really use (if known): {{devices_and_browsers}} - Team size, skills and timeline: {{team_and_timeline}} - Existing brand or design system, if any: {{design_constraints}} Steps: 1. Restate the purpose and rank the key tasks. If the users or tasks are unclear, ask at most 3 questions; otherwise proceed with stated assumptions. 2. Define the layout approach for small, medium and large screens: what stays visible, what collapses, and how navigation changes. 3. For each key task, describe the screen flow in 3 to 6 steps, including empty, loading and error states. 4. Set standards for accessibility (keyboard use, contrast, labels, text size) and performance (page weight, image handling, loading order). 5. Break the work into phases with what can be tested with real users after each phase. 6. List risks and trade-offs, such as supporting old browsers or heavy data tables on phones. Output format: - Summary and assumptions (5 lines) - Screen-size behavior table: area, small, medium, large - Task flows - Quality standards checklist - Phased plan with a testing step per phase - Top 5 risks with mitigation Quality bar: stay realistic for the team size, avoid naming specific libraries unless asked, give measurable targets only when marked as suggestions, and keep language plain.

You are a product designer and front-end lead planning a responsive web app. Goal: a plan a small team can start from this week, with clear priorities instead of a long wish list. Inputs: - What the app does and for whom: {{app_purpose_and_users}} - The top 3 tasks users must complete: {{key_tasks}} - Devices and browsers your users really use (if known): {{devices_and_browsers}} - Team size, skills and timeline: {{team_and_timeline}} - Existing brand or design system, if any: {{design_constraints}} Steps: 1. Restate the purpose and rank the key tasks. If the users or tasks are unclear, ask at most 3 questions; otherwise proceed with stated assumptions. 2. Define the layout approach for small, medium and large screens: what stays visible, what collapses, and how navigation changes. 3. For each key task, describe the screen flow in 3 to 6 steps, including empty, loading and error states. 4. Set standards for accessibility (keyboard use, contrast, labels, text size) and performance (page weight, image handling, loading order). 5. Break the work into phases with what can be tested with real users after each phase. 6. List risks and trade-offs, such as supporting old browsers or heavy data tables on phones. Output format: - Summary and assumptions (5 lines) - Screen-size behavior table: area, small, medium, large - Task flows - Quality standards checklist - Phased plan with a testing step per phase - Top 5 risks with mitigation Quality bar: stay realistic for the team size, avoid naming specific libraries unless asked, give measurable targets only when marked as suggestions, and keep language plain.

Assumptions: appointment booking for a small clinic, most users on phones, a team of two for 8 weeks. Screen behavior Navigation | small: bottom bar, 4 items | medium: side rail | large: top bar Booking form | small: one question per screen | medium: two columns | large: form plus summary panel Task flow - Book a visit: choose service, choose time, confirm details, see confirmation with calendar option. Include states: no available times, slow connection, payment error. Standards (suggested): text readable at 200% zoom; first screen usable within about 3 seconds on a mid-range phone. Phase 1 (weeks 1-3): booking flow only, test with 5 patients. Risk: crowded admin tables on phones; mitigate with a card view.