From Use Cases to Mockups

The Use Case to Screen Pipeline

A use case is a behavioral specification. A mockup is a visual specification. The gap between them is where most design mistakes happen — designers create happy-path screens and miss the error states, loading states, confirmation dialogs, and edge cases that the use case documents.

The systematic pipeline is: Use Case → Screen Inventory → Wireframe → Mockup → Code

Step 1: Walk Through Each Use Case Step

For every numbered step in your use case, ask: "What does the user see when this step happens?" Every step that involves a state change, user input, or system response implies at least one screen or screen state.

Take the "Customer Completes Purchase" use case from the previous lesson:

• Step 1 (Click Proceed to Checkout) → Cart screen with checkout button
• Step 2 (Display order summary) → Checkout screen: order summary panel
• Step 3 (Select shipping address) → Checkout screen: address selection step
• Step 4 (Select payment method) → Checkout screen: payment method step
• Step 5 (Select shipping speed) → Checkout screen: shipping step with delivery estimate
• Step 6 (Click Place Order) → Loading state during payment processing
• Step 7-10 (Payment + order creation) → No new screen, but a loading/processing state
• Step 11 (Confirmation page) → Order confirmation screen

From extensions:

• 3a. No saved addresses → Address entry form modal or inline
• 7a. Payment declined → Error state on payment step
• 7b. Network error → Retry modal
• 9a. Item out of stock → Cart screen with availability warning

Step 2: Create a Screen Inventory

List every unique screen and state implied by the use case. Group related states under their screen:

Checkout Screen:

• Address step (saved addresses)
• Address step (no saved addresses / entry form)
• Payment step (saved cards)
• Payment step (new card entry)
• Shipping step
• Review step
• Processing state (loading)
• Payment declined error state
• Network error state

Order Confirmation Screen:

• Success state
• (No error state — if we get here, it worked)

Cart Screen:

• Items available state
• Item out of stock warning state

Step 3: Identify Transition Triggers

For each screen, identify what moves the user to the next screen:

• Cart → Checkout: Click "Proceed to Checkout"
• Checkout (address) → Checkout (payment): Click "Continue" after valid address
• Checkout (payment) → Checkout (shipping): Click "Continue" after valid payment
• Checkout (review) → Processing: Click "Place Order"
• Processing → Confirmation: Payment success
• Processing → Error state: Payment failure

Step 4: Annotate Wireframes with Use Case References

When you create wireframes, annotate each element with the use case step number it satisfies. This creates a traceable link between requirements and design:

• Address form → satisfies steps 3, 3a
• Payment form → satisfies steps 4, 4a, extension 7a
• "Place Order" button → triggers step 6 → 7 transition
• Error message area → satisfies extensions 7a, 7b

This annotation prevents the question "why is this on screen?" — every element traces back to a specified behavior.

Why This Prevents Missing Screens

When designers work from user stories alone ("As a shopper I want to check out"), they naturally visualize the happy path. The use case's extensions force you to account for every alternative. The screen inventory makes the full scope visible before any design work begins.

Key Takeaways

• Every use case step that involves input, output, or state change implies a screen or screen state
• The screen inventory is a complete list of screens and states before wireframing begins
• Transition triggers document what causes navigation between screens
• Annotating wireframes with use case step references creates traceable requirements-to-design links
• The systematic process prevents missing error states, loading states, and confirmation screens