🎯 Learning Objectives
By the end of this lesson, you will:
- Explain why "sad path" screens are chronically missing from designs
- Map every user action to its required design states
- Apply the "API-to-Screen" technique for finding missing screens
- Write a request for a missing design screen that the designer will actually want to fulfill
😢 The Sad Path Problem
Designers are optimists. They imagine a user who:
- Always fills out the form correctly
- Always has a fast internet connection
- Never loses their session
- Always finds what they're looking for
So they design the happy path. A beautiful, smooth flow where everything works.
But users are not optimists. They're just people. And people:
- Enter wrong data
- Lose their connection mid-upload
- Forget their password
- Get their session timed out
- Search for something that doesn't exist
If there's no design for these moments — the developer decides what the UI looks like. Often, that means a raw error message, a blank screen, or a generic "something went wrong" page.
Your job: find every missing sad-path screen before a developer has to invent one.
🗺️ The State Matrix
For every screen or feature, there are predictable states to design:
| State type | Description | Example |
|---|---|---|
| Happy path | Everything works as expected | Form submitted successfully |
| Empty state | No data to show yet | "You have no orders yet" |
| Loading state | Data is being fetched | Spinner / skeleton screen |
| Error state | Something went wrong | "Failed to load. Try again." |
| Partial state | Some data, some errors | Partially filled list |
| Permission state | User doesn't have access | "You need admin rights to view this" |
| Offline state | No internet connection | "You appear to be offline" |
| Timeout state | Server didn't respond in time | "Request timed out. Retry?" |
For any significant feature, all 8 states should have a design answer. Not all need a full screen — but there must be some defined behavior.
🛠️ The API-to-Screen Technique
This is the most systematic method for finding missing design states.
Step 1: List every API call the feature makes (get this from the Tech Spec or from a conversation with the developer).
Step 2: For each API call, there are always at least 3 outcomes:
- ✅ Success
- ❌ Error (4xx or 5xx)
- ⏳ Loading (the call is in progress)
Step 3: Verify that there is a design screen for all 3.
Example:
Feature: User Profile Page
| API call | Success design | Loading design | Error design |
|---|---|---|---|
GET /user/profile |
Profile page with data | Skeleton screen | "Failed to load profile. Retry?" |
PUT /user/profile (save) |
Success toast | Button loading state | Error message under form |
DELETE /user/avatar |
Avatar removed, placeholder shown | Button disabled | Toast: "Failed to remove. Try again." |
Go through this exercise with the Figma file open. For every row where a design is missing — that's your comment.
🌍 Real-World Scenario
Feature: Image upload in user profile
What the designer provided:
- Default state (no avatar)
- Uploaded state (avatar shown)
- Image preview before confirm
What's missing (apply the technique):
- ❓ Loading state during upload?
- ❓ Error state if file is too large?
- ❓ Error state if file type is wrong (PDF instead of JPG)?
- ❓ Error state if server rejects the upload?
- ❓ Progress indicator for large files?
- ❓ What happens on mobile with camera access denied?
📝 Requesting a Missing Screen
How you ask matters. Designers are busy. Make it easy for them to say yes.
Weak: "Missing error states on the profile page."
Strong:
"The profile image upload doesn't have a design for the file-too-large error case. The spec says the limit is 5MB. Could we add an error state with a message like 'File too large — max 5MB'? I can write the error copy if that helps."
Why this works:
- Specific: names the exact missing screen
- Grounded: references the spec
- Concrete: suggests a solution
- Collaborative: offers to write the copy
💡 Pro Tips
💡 Tip 1: When you see a "Submit" button, always ask: what does that button look like while the request is processing? Loading spinner? Disabled? This is one of the most commonly forgotten states.
💡 Tip 2: The empty state is often the most impactful design — it's what new users see first. Yet it's almost always designed last, or forgotten entirely.
💡 Tip 3: Offline/network error states are especially important on mobile apps. If you're working on a mobile product, always ask about the offline experience.
📋 Summary
- Designers naturally focus on happy paths — sad paths are chronically underdesigned
- 8 states to check: happy, empty, loading, error, partial, permission, offline, timeout
- API-to-Screen technique: list every API call → verify success/loading/error designs exist
- Requesting missing screens: be specific, reference the spec, offer a solution
Up next: the third dimension of visual review — the words in the interface.