Extract and generate six sections:
Section 1: Product Context
One paragraph. What this product is, who uses it, and what problem it solves. Written for a designer who has never seen the spec. Pull from the PD's vision section if available, otherwise synthesize from the spec's Purpose/Objectives.
Section 2: User Flows
Every distinct user journey through the product, end to end. Each flow is a numbered sequence of steps with the format:
Flow: {Flow Name}
Actor: {who is doing this}
1. {action} -> {what happens / what they see}
2. {action} -> {what happens / what they see}
...
Extract flows from FRs, use cases, and architecture data flows. Common flows to look for: creation/setup flows, consumption/viewing flows, management/admin flows, authentication flows. Include error and edge case flows where the spec defines them.
Section 3: Screen Inventory
Every distinct screen/page/view the product needs. For each screen:
Screen: {Screen Name}
Route: {URL path if specified in spec}
Actor: {who sees this screen}
Purpose: {what the user does here, one line}
Entry points: {how the user gets here}
Key content: {bullet list of what's displayed}
Key actions: {bullet list of what the user can do}
Derive screens from the spec's deliverables, API routes, and functional requirements. If the spec mentions a "listing page," "detail page," "creation wizard," etc., each is a screen. If a screen has distinct states (empty, loading, populated, error), note them.
Section 4: Component Inventory
Reusable UI components that appear across multiple screens or are complex enough to warrant explicit design. For each:
Component: {Component Name}
Used in: {which screens}
Description: {what it looks like and does}
States: {variants, empty/loading/error states}
Data: {what data it displays or accepts}
Look for: navigation elements, data tables, forms, cards, progress indicators, assessment interfaces, media players, auth flows, status badges, modals/overlays.
Section 5: Data Model Summary
What data is displayed where, written for a designer not a developer. No SQL, no schema. For each major entity:
Entity: {Entity Name}
Displayed as: {how users see this - card, row, detail page, etc.}
Key fields shown to user: {list of visible fields with example values}
Relationships: {what other entities it connects to visually}
Section 6: Interaction Patterns
How the product responds to user actions. Focus on patterns that affect visual design:
- Navigation model: how users move between screens (tabs, sidebar, breadcrumbs, back buttons)
- Creation flows: wizard vs. single page, progressive disclosure, step indicators
- Async operations: what happens during long-running processes, polling indicators, return-to-completed states
- Mobile vs. desktop: which screens are mobile-first, which are desktop-only, responsive breakpoints
- Auth transitions: how the UI changes between manager and learner views
- Bilingual: how language switching works in the UI
- Feedback patterns: success/error states, toast notifications, inline validation
- Data tables: sorting, filtering, pagination
