How this course works
Six sessions, 45 minutes each, and one real screen you take from a complaint in a support ticket to a handoff a developer can build. The screen belongs to Daybreak, the coffee-subscription brand from the SQL and system-design courses.
★ What you walk out with tonight. A one-paragraph problem statement with a person in it, one metric with a number against it, an opportunity size you worked out on paper, and a list of the things you are deliberately not solving.
LiveThe screen, and why it is worth six sessions2 min▶
Daybreak sells coffee on subscription. The screen is "Manage your subscription": the place a subscriber goes to pause, skip a box, change their grind, change how often it arrives, or cancel.
It is the highest-stakes surface in the company, for a reason that has nothing to do with design and everything to do with money: it is the only screen where the customer is actively deciding whether to keep paying you. Every other screen is about coffee. This one is about the relationship.
And right now, on Daybreak's version, "Cancel subscription" is one tap away and "Pause deliveries" is two taps deeper, inside a menu called Options. Nobody decided that. It is just where things ended up.
Self-studyThe artifact: one screen, in six passes2 min▶
| Session | What the work gains |
|---|---|
| 1 · tonight | A problem statement with a person in it, and one metric |
| 2 | Five interviews, and at least one belief you had to give up |
| 3 | The flow and a deliberately ugly wireframe of the structure |
| 4 | Type scale, spacing scale, hierarchy and colour that passes on measurement |
| 5 | States, feedback, and every word on the screen written on purpose |
| 6 | A critique survived, a handoff pack, and the debt written down |
If you only do three, do 1, 4 and 6. Session 1 is whether it was worth building, session 4 is whether it is usable, session 6 is whether it survives you.
A feature request is a solution with the problem removed
6 min live"Can we add a pause button" is not a problem statement. It is somebody's guess, and it may well be right, but you cannot tell yet - and if you build it without knowing, you also cannot tell afterwards whether it worked.
LiveThe problem statement that is worth writing4 min▶
One paragraph, four things in it, and no product words at all:
- A person, specifically. Not "users". "A subscriber going travelling for three weeks."
- A moment. When does this happen? "Three days before the next box ships, usually from a phone, usually in the evening."
- What they do instead. This is the part everyone skips and it is the most useful. People always do something. What they do instead of the thing you wish they did tells you where the design failed.
- What would be different. Not "a better experience". Something you could count.
"A subscriber going away for three weeks wants to stop the next box. Three days before it ships, on a phone, in the evening, they open Manage subscription. They see Cancel. They do not see Pause, because it is inside Options. They cancel, and about half of them never come back. If we solved it, cancellations that begin with a pause attempt would fall, and reactivations would not have to carry the difference."
Notice that this paragraph contains no design ideas at all. That is deliberate: the moment a solution enters the problem statement, everybody starts discussing the solution and the problem is never examined again.
"Can we add a pause button to the subscription page? Competitors have one. Also it should feel friendlier, the page is quite cold."
Two solutions and an aesthetic opinion. If you build exactly this you will ship a pause button in a friendlier colour, and you will have no way of telling whether it did anything, because nobody wrote down what "did anything" means.
"Subscribers who want a three-week break cancel instead, because cancel is one tap and pause is three. About half never return. Target: cancellations that started as a pause attempt, down by a third this quarter."
Now "friendlier" is testable rather than arguable, the pause button is a hypothesis with a number on it, and you will know in six weeks whether you were right.
One metric, one guardrail, and the arithmetic that says whether to bother
6 min liveA design with no metric cannot be wrong, which sounds comfortable until you notice it also cannot be right. And a design with only one metric is how you accidentally make something worse.
LiveWhy you need a guardrail metric as well4 min▶
Optimise one number hard enough and you will find a way to move it that nobody wanted. If the only metric is "fewer cancellations", the fastest design is to hide the cancel button entirely, and that design will win on the dashboard while your support queue fills up and someone writes a thread about dark patterns.
- Primary: cancellations that began as a pause attempt, down by a third.
- Guardrail: time to complete an intentional cancellation, unchanged. Plus support tickets containing the word "cancel", unchanged.
The guardrail is also an ethics mechanism with a number on it, which is much more durable than an ethics conversation. "We agreed cancelling would not get slower, and it got 40 seconds slower" is a fact. "This feels a bit dark-pattern-ish" is a feeling somebody can talk you out of on a Thursday.
Self-studyOutput, outcome, and the sentence that separates them3 min▶
| Output (what you did) | Outcome (what changed) |
|---|---|
| Redesigned the subscription page | Pause attempts that succeed, up from 44% to 81% |
| Added a pause button | Cancellations that began as a pause attempt, down a third |
| Improved the copy | Support tickets asking "how do I pause", down by half |
The test: could this be true while nothing improved for anybody? If yes, it is an output. Outputs are fine to plan with and dangerous to celebrate with, because a team that celebrates outputs eventually optimises for shipping rather than for working.
The seeded sentence has 21 words, no person, no moment, no number and no thing anybody does instead. It could be about any product ever made. Run your own brief through it and look for the same four absences - they are usually all four at once.
Frame it, size it, and write down what you are not solving
★ 22 min · everyone buildsFive blocks, and none of them contain a screen. If you find yourself sketching, you have skipped ahead, and session 3 is where the sketching lives.
Person. One specific person, named by their situation rather than a demographic. "A subscriber going away for three weeks" tells you something. "Millennials" tells you nothing you can design with.
Moment. When, where, on what, in what mood. Three days before shipping, on a phone, in the evening, mildly irritated. Every one of those changes the design.
Instead. What do they currently do? People are never passive. They cancel, they email support, they let the box arrive and give it away, they change their card. Each of those is a clue about which door they could find.
Metric. One primary, one guardrail. The guardrail is the promise that you will not win by making something else worse, and it needs a number so it can be checked.
Not this. The list of adjacent problems you are deliberately leaving alone this time. Writing them down is what stops them arriving in week three as "quick additions".
Write the person block for Daybreak. Then read it and ask whether it describes a real evening. If it sounds like a persona document, it is too smooth - real situations have annoying specifics in them.
Write the "instead" block. This is the hardest one and the highest value. For Daybreak: they cancel. Ask yourself why cancel and not email support, and the answer is usually that cancel was simply the door they could see.
Do the sizing arithmetic. 410 cancellations a month, 31 percent began as a pause attempt, save half, $34 a month, 11 months. Get to the annual number yourself. It should take three minutes and it is the entire business case.
Now write your guardrail. Ask: what is the cheapest, ugliest way to move my primary metric? Whatever that is, the guardrail is the thing it would damage. For "fewer cancellations", the cheap ugly way is hiding cancel, so the guardrail is cancellation time.
Write three things you are not solving. Daybreak's real list: the checkout flow, the gift-subscription mess, and the fact that grind options are described in words nobody outside coffee understands. All real, all out of scope, all written down.
Now do it for something of your own. A screen, a form, a flow you are responsible for or annoyed by. That is your parallel project for the whole course, and it is what makes session 6 useful rather than theoretical.
Read the brief out loud to somebody who is not in your team. If they can restate the problem back to you, it is a problem statement. If they say "so you are redesigning the page", you have written a solution.
Note what the trap does. Hiding cancel is the one change on that list that makes the number go up here, because the tickets, the chargebacks and the people who cancel twice all come back as churn with a worse mood attached. A guardrail metric is how you catch that in week two instead of in a screenshot on social media.
Before session 2
25 min- Write the five blocks for your own screen. Person, moment, instead, metric, not-this. One page maximum.
- Find the "instead" for real. Look at support tickets, a funnel, or ask one person. What do people actually do when your thing does not work for them?
- Size it. Volume, rate, value. Even rough. If the annual number is small, that is a finding worth having before the work rather than after it.
- Write your guardrail by finding the cheap ugly way. How would a cynical person move your primary metric? Guard that.
- Line up five people to talk to. Session 2 is interviews, and having the names already is the difference between doing it and intending to.
Three questions
Clear all three and session 1 gets stamped in your passport.
1 · Which part of a problem statement is most often missing and most useful?
People are never passive. They cancel, they email support, they work around it, they leave. What they do instead points straight at which door they could find, which is usually the actual design failure - and it is evidence rather than opinion.
2 · Your primary metric is "fewer cancellations". Why does that need a guardrail?
Find the cheap ugly way to move your primary metric, and guard exactly that. "Cancellation time, unchanged" is an ethics commitment with a number on it, which survives a Thursday afternoon in a way that a feeling about dark patterns does not.
3 · Which of these is an outcome rather than an output?
The test is whether it could be true while nothing improved for anybody. You can ship a redesign and add a button with nothing changing for a single person. A success rate that moved is a statement about people, and it is the one worth celebrating.
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map.
Session 1 cheat sheet · pin this
Tonight's brief is built on what you believe. Session 2 is five conversations that will take at least one of those beliefs away from you, and the discipline that makes that possible: write down what you expect to find before you go and find it. The gap between the guess and the transcript is the entire value of research.