Prd V04 Screen Flow Definition

Screen Flow Definition

Position in workflow: v0.4 User Journey Mapping → v0.4 Screen Flow Definition → v0.5 Red Team Review

Screens are where journeys become tangible. This skill transforms user journeys into a screen inventory with navigation paths and feature mappings.

Consumes

This skill requires prior work from v0.3-v0.4:

• UJ-* user journey entries (from v0.4 User Journey Mapping) — Journey steps become screens; each step asks "What screen enables this action?"
• FEA-* feature entries (from v0.3 Features Value Planning) — Features map to screens showing which features appear on which screens
• PER-* persona entries (from v0.4 Persona Definition) — Persona context (technical level, role) shapes screen design choices and complexity
• MVP-SCOPE artifact (from v0.3 Features Value Planning) — Explicit feature boundary; screens must render only MVP-scoped features, backlog features deferred
• BR-* business rules (from v0.3 Commercial Model) — Constraints affecting screen layout (pricing tier rules affect which settings appear, role-based visibility, data refresh rates, etc.)

This skill assumes v0.4 User Journey Mapping is complete.

Produces

This skill creates/updates:

• SCR-* entries (screens, confidence 2-3/5) — Screen inventory with journey/feature/persona mappings showing purpose, actions, navigation, and constraints
• DES-* entries (design system components, confidence 2-3/5) — Reusable UI elements and patterns identified across screens
• Feature-to-Screen matrix — Validation artifact showing every FEA- and every UJ- step mapped to SCR-
• Screen count and complexity assessment — Critical for v0.5 technical stack selection (number of screens informs frontend framework needs)

All SCR- entries should include:

• confidence: 2-3/5 (based on journey validation and feature implementation status)
• Evidence source citations (UJ-ID, FEA-ID, PER-ID references)
• Forward target: "Would move to 4/5 if validated in wireframe review or prototype testing"

Example SCR- entry with confidence:

SCR-001: Main Dashboard
Type: Page
Purpose: Central hub showing key metrics and quick actions
Journeys: UJ-001 (Step 4), UJ-002 (Step 5), UJ-003 (Step 1)
Features: FEA-007 (dashboard), FEA-003 (reports preview), FEA-012 (notifications) — all in MVP-SCOPE
Confidence: 2/5 (source: journey-mapping + design-validation; not yet wireframed)

Primary Actions: Create Report, View Data Sources, Access Settings
Secondary Actions: Invite Team, View Help

Navigation:
  From: SCR-000 (Login), any screen via nav bar
  To: SCR-002 (Report Builder), SCR-003 (Data Sources), SCR-010 (Settings)

Content:
  - Key metrics summary (3-5 cards) → DES-001 (Data Card)
  - Recent reports list → DES-002 (Report List)
  - Data source health status → DES-003 (Status Badge)
  - Notification bell → FEA-012

Constraints: BR-015 (data refresh rate), BR-020 (role-based visibility)
Design Notes: PER-001 needs "busy dashboard" - show progress at a glance without overwhelming

Next Target: "Would move to 4/5 if wireframe validated with 3+ target personas"

Example DES- entry with confidence:

DES-001: Data Card
Type: Component
Used In: SCR-001 (Dashboard), SCR-005 (Analytics)
Purpose: Display single metric with trend indicator
Confidence: 2/5 (source: design-pattern-research; component not yet coded)

States:
  - Default: Shows value + trend arrow
  - Loading: Skeleton placeholder
  - Empty: "No data yet" message
  - Error: "Failed to load" with retry

Variants: Small (dashboard, 120px width), Large (detail view, 240px width)
Accessibility: ARIA labels for trend direction, keyboard navigation support

Next Target: "Would move to 4/5 if implemented and tested across both use cases"

Screen Types

Rule: Start with Pages, then identify where Modals/Panels reduce navigation friction.

Navigation Patterns

Choose a pattern based on product type:

Most SaaS products use Hub & Spoke with occasional Linear Flows for onboarding/purchase.

Mapping Process

1. Pull UJ- (journeys) and FEA- (features) from prior steps

   • Journeys define the paths; features define the capabilities

2. Inventory unique screens needed across all journeys

   • Walk through each journey step and ask: "What screen does this happen on?"

3. Map features to screens (many:many relationship)

   • One feature may appear on multiple screens
   • One screen may contain multiple features

4. Define navigation structure

   • How do users get from screen to screen?
   • What's the hierarchy? What's always accessible?

5. Identify shared components

   • Headers, footers, navigation bars
   • Common patterns: data tables, forms, cards

6. Create SCR- entries with journey and feature traceability

7. Create DES- entries for design system elements

SCR- Output Template

SCR-XXX: [Screen Name]
Type: [Page | Modal | Panel | Component]
Purpose: [What user accomplishes on this screen]
Journeys: [UJ-XXX, UJ-YYY that use this screen]
Features: [FEA-XXX, FEA-YYY rendered on this screen]

Primary Actions: [Key user actions available]
Secondary Actions: [Less common but available actions]

Navigation:
  From: [SCR-XXX, SCR-YYY — how users arrive]
  To: [SCR-XXX, SCR-YYY — where users can go next]

Content:
  - [Data/element 1]
  - [Data/element 2]

Constraints: [BR-XXX rules affecting this screen]
Design Notes: [Persona-specific considerations from PER-]

Example SCR- entry:

SCR-001: Main Dashboard
Type: Page
Purpose: Central hub showing key metrics and quick actions
Journeys: UJ-001 (Step 4), UJ-002 (Step 5), UJ-003 (Step 1)
Features: FEA-007 (dashboard), FEA-003 (reports preview), FEA-012 (notifications)

Primary Actions: Create Report, View Data Sources, Access Settings
Secondary Actions: Invite Team, View Help

Navigation:
  From: SCR-000 (Login), any screen via nav bar
  To: SCR-002 (Report Builder), SCR-003 (Data Sources), SCR-010 (Settings)

Content:
  - Key metrics summary (3-5 cards)
  - Recent reports list
  - Data source health status
  - Notification bell

Constraints: BR-015 (data refresh rate), BR-020 (role-based visibility)
Design Notes: PER-001 needs "busy dashboard" - show progress at a glance

DES- Output Template

DES-XXX: [Component/Pattern Name]
Type: [Component | Pattern | Layout]
Used In: [SCR-XXX, SCR-YYY]
Purpose: [What this element does]

States:
  - Default: [Normal state]
  - Loading: [When fetching data]
  - Empty: [No data state]
  - Error: [Error state]
  - Disabled: [When not interactive]

Variants: [If multiple versions exist]
Accessibility: [A11y considerations]

Example DES- entry:

DES-001: Data Card
Type: Component
Used In: SCR-001 (Dashboard), SCR-005 (Analytics)
Purpose: Display single metric with trend indicator

States:
  - Default: Shows value + trend arrow
  - Loading: Skeleton placeholder
  - Empty: "No data yet" message
  - Error: "Failed to load" with retry

Variants: Small (dashboard), Large (detail view)
Accessibility: ARIA labels for trend direction

Screen Categories

Organize screens by function:

Rule: Invest design effort proportional to priority. Don't over-design settings screens.

Feature-to-Screen Matrix

Create a mapping matrix:

This reveals:

• Features spread across multiple screens (normal)
• Features on no screens (problem: orphaned)
• Screens with no features (problem: unnecessary)

Anti-Patterns to Avoid

Quality Gates

Before proceeding to v0.5 Red Team Review:

• All UJ- steps mapped to screens
• All FEA- features appear on at least one screen
• Navigation paths are bidirectional (no dead-ends)
• Shared components identified as DES- entries
• Screen count reasonable for MVP (<15 pages)
• Entry points and core workflow prioritized

Downstream Connections

SCR- and DES- entries feed into:

Detailed References

• Screen flow examples: See references/examples.md
• SCR- entry template: See assets/scr.md
• DES- entry template: See assets/des.md
• Navigation patterns guide: See references/navigation-patterns.md