Back to list
mattgierhart

prd-v04-screen-flow-definition

by mattgierhart

PRD-driven Context Engineering: A systematic approach to building AI-powered products using progressive documentation and context-aware development workflows

9🍴 2📅 Jan 24, 2026

SKILL.md


name: prd-v04-screen-flow-definition description: Connect user journeys to screens, defining the UI structure and navigation paths during PRD v0.4 User Journeys. Triggers on requests to define screens, design screen flows, map UI structure, plan navigation, or when user asks "what screens do we need?", "define screens", "screen flow", "UI structure", "information architecture", "navigation design", "wireframe planning". Consumes UJ- (User Journey Mapping), FEA- (Feature Value Planning), BR- (constraints). Outputs SCR- entries for screens and DES- entries for design system elements. Feeds v0.5 Red Team Review.

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.

Screen Types

TypeDefinitionDesign PriorityExample
PageFull viewport, primary navigation targetHighDashboard, Settings
ModalOverlay, blocks underlying pageMediumConfirmation, Quick Edit
PanelSlide-out, contextual detailMediumDetail View, Filters
ComponentReusable UI elementVariesHeader, Data Table

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

Choose a pattern based on product type:

PatternWhen to UseExample Products
Hub & SpokeDashboard-centric appsAnalytics, CRM
Linear FlowWizard/checkout processesOnboarding, E-commerce
HierarchicalContent-heavy appsDocumentation, CMS
FlatSimple single-purpose appsTimer, 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:

CategoryExamplesDesign Priority
Entry PointsLogin, Landing, SignupHigh (first impressions)
Core WorkflowMain task screensHigh (value delivery)
Settings/AdminPreferences, Account, BillingMedium (necessary)
Support/HelpDocs, Contact, FAQLow (failure recovery)

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

Feature-to-Screen Matrix

Create a mapping matrix:

FeatureSCR-001SCR-002SCR-003SCR-004
FEA-001 (auto-sync)
FEA-003 (reports)PreviewFull
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-PatternSignalFix
Screen explosion>20 unique screens for MVPConsolidate; use modals/panels instead
Feature-per-screen1:1 FEA to SCR mappingGroup related features on screens
No shared componentsEvery screen is uniqueExtract DES- patterns
Navigation dead-endsCan't get back from a screenEnsure bidirectional paths
Journey disconnectSCR- not tied to UJ-Every screen serves a journey
Modal abuseEverything is a modalModals 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:

ConsumerWhat It UsesExample
v0.5 Technical Stack SelectionScreen complexity informs frontend needs"20 screens → need component library"
v0.6 Technical SpecificationScreens inform API data needsSCR-001 → API-001 (dashboard data)
v0.7 Build ExecutionScreens become implementation tasksEPIC-03 builds SCR-001–005
DesignSCR- entries become wireframes/mockupsSCR-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

Score

Total Score

75/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

+10
人気

GitHub Stars 100以上

0/15
最近の活動

1ヶ月以内に更新

+10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

+5

Reviews

💬

Reviews coming soon