---
name: Screen Flow Definition
slug: screen-flow-definition
category: Frontend
description: Screen Flow Definition turns user journeys into a screen inventory, navigation paths, and shared UI components. Use it when defining screens, information architecture, or wireframe structure from PRD journeys and feature plans.
github: "https://github.com/mattgierhart/PRD-driven-context-engineering/tree/main/.claude/skills/prd-v04-screen-flow-definition"
language: HTML
stars: 182
forks: 10
install: "npx degit https://github.com/mattgierhart/PRD-driven-context-engineering/tree/main/.claude/skills/prd-v04-screen-flow-definition ~/.claude/skills/prd-v04-screen-flow-definition"
installs_to: ~/.claude/skills/prd-v04-screen-flow-definition
source_path: .claude/skills/prd-v04-screen-flow-definition/SKILL.md
collection_size: 25
category_size: 705
collection_url: "https://dirskills.com/collections/mattgierhart/PRD-driven-context-engineering"
added: 2026-09-07T05:20:13.715Z
last_synced: 2026-09-07T05:20:13.715Z
canonical_url: "https://dirskills.com/skills/screen-flow-definition"
---

# Screen Flow Definition

Screen Flow Definition turns user journeys into a screen inventory, navigation paths, and shared UI components. Use it when defining screens, information architecture, or wireframe structure from PRD journeys and feature plans.

**Install:**

```bash
npx degit https://github.com/mattgierhart/PRD-driven-context-engineering/tree/main/.claude/skills/prd-v04-screen-flow-definition ~/.claude/skills/prd-v04-screen-flow-definition
```

## README

# 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:
```markdown
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:
```markdown
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

| Type | Definition | Design Priority | Example |
|------|------------|-----------------|---------|
| **Page** | Full viewport, primary navigation target | High | Dashboard, Settings |
| **Modal** | Overlay, blocks underlying page | Medium | Confirmation, Quick Edit |
| **Panel** | Slide-out, contextual detail | Medium | Detail View, Filters |
| **Component** | Reusable UI element | Varies | Header, Data Table |

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

## Navigation Patterns

Choose a pattern based on product type:

| Pattern | When to Use | Example Products |
|---------|-------------|------------------|
| **Hub & Spoke** | Dashboard-centric apps | Analytics, CRM |
| **Linear Flow** | Wizard/checkout processes | Onboarding, E-commerce |
| **Hierarchical** | Content-heavy apps | Documentation, CMS |
| **Flat** | Simple single-purpose apps | Timer, Calculator |

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:

| Category | Examples | Design Priority |
|----------|----------|-----------------|
| **Entry Points** | Login, Landing, Signup | High (first impressions) |
| **Core Workflow** | Main task screens | High (value delivery) |
| **Settings/Admin** | Preferences, Account, Billing | Medium (necessary) |
| **Support/Help** | Docs, Contact, FAQ | Low (failure recovery) |

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

## Feature-to-Screen Matrix

Create a mapping matrix:

| Feature | SCR-001 | SCR-002 | SCR-003 | SCR-004 |
|---------|---------|---------|---------|---------|
| FEA-001 (auto-sync) | | ✓ | | |
| FEA-003 (reports) | Preview | Full | | |
| FEA-007 (dashboard) | ✓ | | | |
| FEA-010 (auth) | | | | ✓ |

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

## Anti-Patterns to Avoid

| Anti-Pattern | Signal | Fix |
|--------------|--------|-----|
| **Screen explosion** | >20 unique screens for MVP | Consolidate; use modals/panels instead |
| **Feature-per-screen** | 1:1 FEA to SCR mapping | Group related features on screens |
| **No shared components** | Every screen is unique | Extract DES- patterns |
| **Navigation dead-ends** | Can't get back from a screen | Ensure bidirectional paths |
| **Journey disconnect** | SCR- not tied to UJ- | Every screen serves a journey |
| **Modal abuse** | Everything is a modal | Modals for confirmations/quick edits only |

## 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:

| Consumer | What It Uses | Example |
|----------|--------------|---------|
| **v0.5 Technical Stack Selection** | Screen complexity informs frontend needs | "20 screens → need component library" |
| **v0.6 Technical Specification** | Screens inform API data needs | SCR-001 → API-001 (dashboard data) |
| **v0.7 Build Execution** | Screens become implementation tasks | EPIC-03 builds SCR-001–005 |
| **Design** | SCR- entries become wireframes/mockups | SCR-001 → Figma design |

## 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`