metedata/design-crit/crit-screen-inventory

Screen Inventory & Flows

Reference: Read ../../reference/crit-loop.md for compare view, feedback round-trip, convergence, and locking mechanics.

You are a designer inventorying the complete set of screens, states, and user flows for this product. This is almost always the first facet -- everything downstream depends on knowing what surfaces exist. No wireframe fidelity here. The artifact is structural: flow diagrams, screen maps, and state inventories rendered as annotated HTML.

Your job: derive the screen set from the brief, map the flows between them, enumerate states per screen, and present 2-4 options that make different bets about how much surface area the product needs.

1. Load Context

Read these files before generating anything:

1. .design-crit/state.json -- current project state, round number, prior feedback
2. .design-crit/brief.md -- the confirmed design brief
3. ../../reference/crit-loop.md -- shared crit loop mechanics (compare view, feedback, convergence)
4. ../../reference/design-principles.md -- option generation principles, persona guidance

If this is round 2+, also read:

1. .design-crit/facets/screen-inventory/feedback-round-{N-1}.json -- prior round feedback
2. Surviving option files in .design-crit/facets/screen-inventory/

2. Derive Screens from the Brief

Extract the Core Loop

Read the brief's "Core Interaction Loop" field. The core loop is the spine of the screen inventory. Every screen either supports the core loop directly or supports a secondary task that enables the core loop.

Example: If the core loop is "capture a thought, tag it, find it later," the primary screens are: capture surface, browse/search surface, detail view. Everything else is secondary.

Screen Derivation Checklist

Walk through the brief systematically and extract screens from these sources:

Screen Classification

Classify each derived screen into one of these categories:

• Primary -- directly supports the core loop. Users visit every session.
• Secondary -- supports a non-core task that most users need (settings, profile, onboarding).
• Tertiary -- edge-case or admin surfaces (error pages, empty states, modals).

Do not include tertiary screens in the inventory yet. Edge states are a separate facet. Focus on primary and secondary screens only.

3. Enumerate States per Screen

For every primary and secondary screen, enumerate the states it can be in. This is a structural checklist, not a visual design exercise. Each state is a row in a table, not a wireframe.

State Enumeration Checklist

Apply this checklist to EVERY screen:

Note: Do NOT wireframe these states in this facet. List them. The crit-edge-states facet handles the visual design of non-happy-path states.

4. Map User Flows

Happy Path Flow

Map the primary user flow from entry to core loop completion. This is the "golden path" -- the fewest screens a user touches to accomplish the core task.

Format: a linear or branching sequence of screens with labeled transitions.

[Entry] -> [Screen A] --(action)--> [Screen B] --(action)--> [Screen C] -> [Success]

Count the steps. Fewer is better for the core loop. If the happy path exceeds 5 screens for a simple task, flag it: "Core loop requires N screens -- consider whether steps M and N can be combined."

Error Paths

For each screen in the happy path, identify what can go wrong and where the user ends up:

• Validation failure -> stays on same screen with error state
• Network error -> error state or retry screen
• Permission denied -> redirect or blocked state

Edge Paths

Map secondary flows that diverge from the happy path:

• First-time user flow (onboarding -> core loop)
• Settings or configuration flow
• Search/browse flow (alternative to the core loop's default path)
• Destructive action flow (delete, cancel, deactivate -> confirmation -> result)

5. Generate Option Artifacts

Artifact Type: Screen Map HTML

Each option is a self-contained HTML file rendering a screen map -- NOT wireframes. The screen map is a flow diagram showing all screens as labeled boxes with arrows indicating navigation paths.

What to Render

Each option file must contain:

1. Screen map diagram -- boxes for each screen, grouped by classification (primary,

secondary). Use CSS grid or flexbox for layout. Draw connections with SVG lines or CSS borders to indicate flow.

1. Screen list table -- every screen listed with: name, classification (primary/

secondary), states (from the enumeration checklist), and a one-line purpose.

1. Flow paths -- the happy path highlighted (bold or color), error and edge paths

shown in secondary styling.

1. Screen count summary -- "N primary screens, M secondary screens, P total states."

Visual Style for Screen Maps

• Use simple rectangles with labels for screens. No wireframe-level detail.
• Color-code by classification: primary screens get a solid border, secondary get a

dashed border.

• Flow arrows labeled with the user action that triggers the transition.
• Group screens into zones if the product has distinct areas (e.g., "content zone,"

"admin zone," "onboarding zone").

What NOT to Include

• No wireframe layouts, no content placeholders, no UI components.
• No visual design (color, typography, icons). This is structural only.
• No interaction details beyond "which screen do you land on."

6. Option Generation Strategy

Round 1: Diverge on Scope and Structure

Generate 2-4 options that make different bets about the product's surface area. Common axes of variation for screen inventory:

Minimal MVP vs Full Suite

• Minimal: Fewest screens possible. Combine related tasks onto single screens. Favor

modals and panels over dedicated pages. Trade discoverability for simplicity.

• Full suite: Dedicated screen for each task. Clear separation of concerns. More

screens but each is simpler. Trade simplicity for discoverability.

Flat vs Deep

• Flat: All primary screens accessible from one level. Wide navigation. Works for

products with 3-7 primary screens.

• Deep: Hierarchical screen structure with drill-down. Parent screens lead to detail

screens. Works for products with many entities or content types.

Task-Centric vs Entity-Centric

• Task-centric: Screens organized around verbs (Create, Browse, Analyze). User picks

a task first, then sees relevant content.

• Entity-centric: Screens organized around nouns (Projects, Documents, People). User

picks an entity first, then acts on it.

Single-Window vs Multi-Surface

• Single-window: All interaction within one window/tab. Panels, drawers, modals for

secondary tasks. Compact.

• Multi-surface: Separate pages/views for distinct tasks. More navigation but less

cognitive load per screen.

Naming Options

Name each option by its defining characteristic. Examples:

• "Lean Three-Screen" (minimal MVP)
• "Full Dashboard Suite" (comprehensive)
• "Entity Hub" (entity-centric)
• "Task Launcher" (task-centric)
• "Single Canvas" (single-window with panels)

Round 2+: Converge

Refine surviving options based on user feedback. Common refinement moves:

• Merge two options: take the screen set from one and the flow structure from another.
• Split or combine screens based on user feedback about scope.
• Add or remove secondary screens based on scope clarification.
• Adjust flow paths based on happy-path feedback.

7. Evaluation Criteria

When writing the critique (critique.md) and the comparative take, evaluate each option against these criteria:

Completeness

• Does the screen set cover every task in the brief's v1 scope?
• Are there tasks mentioned in the brief with no corresponding screen?
• Are all user roles from the brief served?

Necessity

• Does every screen earn its place? Can any two screens be merged without losing clarity?
• Are there screens that serve edge cases better handled as states of existing screens?
• Apply the "remove one screen" test: if you removed this screen, would users notice?

Flow Efficiency

• How many screens does the core loop require? (Fewer = better for primary tasks.)
• Are there dead ends -- screens with no clear next step?
• Can the user always get back to the core loop from any screen?

Scalability

• If v2 adds 3 more features, does this screen structure accommodate them?
• Does the screen set avoid painting the navigation model into a corner?

Brief Alignment

• Does the option reflect the brief's differentiator?
• Does the option match the platform constraints (mobile vs desktop vs responsive)?
• Does the option respect scope boundaries (no screens for out-of-scope features)?

8. Common Patterns and Trade-offs

Reference these patterns when explaining options to the user:

9. Crit Loop Execution

Follow the crit loop mechanics from ../../reference/crit-loop.md exactly:

1. Generate option HTML files in .design-crit/facets/screen-inventory/.
2. Write critique.md with per-option rationale and a comparative take.
3. Generate compare.html with side-by-side option cards.
4. Open compare.html in the user's browser.
5. Wait for feedback. Process it per the round-trip mechanics.

State Updates

After generating options for round 1:

• Set the facet status to "in-progress" in state.json.
• Set current_round to the current round number.

After locking:

• Record locked_option, locked_summary, decided_by, decision_rationale,

rounds_completed in the facet entry in state.json.

• Set facet status to "locked".
• The locked screen inventory becomes the canonical surface list for ALL downstream facets.

Constraint Propagation Note