Where we are
Five sessions of work, and it currently exists in your head and in a file. Tonight it becomes something an organisation can build and measure - which is the only version of it that ever helps anybody.
★ What you walk out with tonight. A critique format you can run on Monday, a handoff pack with the five things developers always have to guess at, two metrics to watch after ship, and a written list of the debt you chose to take on.
Ask for problems, not solutions
6 min liveA bad critique is six people redesigning your screen out loud. A good one is six people telling you what they noticed, and you deciding what it means. The difference is entirely in how you open it.
LiveReceiving critique without defending, in two questions5 min▶
Defending is the natural response and it destroys the meeting, because everyone in the room quietly learns that feedback costs them an argument and stops giving it. Two questions replace defence entirely:
- "What made you notice that?" Turns a preference into an observation you can use. "The button is the wrong colour" becomes "I could not tell which one to press first", which is a real finding about hierarchy.
- "What would you expect to happen instead?" Turns a solution back into the problem it came from. Somebody proposing a redesign is usually describing something that confused them, one step removed.
"I think Pause should be at the bottom." → "What made you notice that?" → "Well, cancel is the serious one, it feels odd for pause to be so prominent." → and now you have a real disagreement about hierarchy that you can settle with session 1's metric, rather than a fight about vertical order.
The other half of not defending: write everything down, decide nothing in the room. "Good catch, I will look at that" is a complete sentence, and it buys you the twenty minutes of thinking that a live answer never has.
"I think the pause button should be at the bottom."
"So the research showed people cannot find pause, that is the whole point of the change, and it tested well in session 2, so putting it at the bottom would undo that."
You are right, and you have just taught the room that giving you feedback costs them an argument. Next time they will say "looks good", and you will lose the one thing a critique is for.
"I think the pause button should be at the bottom."
"What made you notice that?" → "Cancel is the serious action, it feels strange for pause to be louder." → "What would you expect instead?" → "I suppose I expected the serious one to be more prominent."
Now you know they are reading emphasis as importance rather than as frequency. That is a real finding, it applies to other screens, and you did not have to lose an argument to get it.
Everything a developer would otherwise have to guess
6 min liveEvery gap in a handoff is filled by somebody, usually at 5pm, usually by the person with the least context about why any of it exists. That is not their failure. It is an unfinished design.
LiveWhat to measure after it ships4 min▶
Session 1 chose these, which is the point of choosing them in session 1. Now you actually look.
- Primary: cancellations that began as a pause attempt, down by a third. Read it at four weeks and at twelve, because subscription effects are slow and the four-week number will tempt somebody into declaring victory.
- Guardrail: time to complete an intentional cancellation, unchanged. If this got slower, you made something worse on purpose or by accident, and either way you need to know before somebody else notices.
- The honest third number: how many people paused and then resumed. If pause succeeds and nobody comes back, you did not save the relationship, you deferred the cancellation - and that is a finding worth having rather than hiding.
Write down, before launch, what result would make you undo this. It takes a sentence and it is the only reliable defence against a team looking at a flat metric and deciding it needs more time.
Self-studyDesign debt, written down on purpose3 min▶
You will ship things you know are not right. That is not a failure, it is scope. The failure is not writing them down, because six months later nobody can tell the difference between a deliberate compromise and a mistake, and the next person either re-litigates it or preserves it forever out of caution.
| What we shipped | Why | What would change it |
|---|---|---|
| Maximum pause is 8 weeks | Billing system cannot hold a longer suspension | Billing work already scheduled for Q1 |
| No pause offer inside the cancel flow | Cancel flow is owned by another team, out of scope | Research says this is where a third of the loss is |
| Grind options still use coffee jargon | Named as out of scope in session 1 | A rewrite of the product vocabulary, separately |
Three columns, and the third one is the one that makes it useful: it turns a list of regrets into a list of triggers.
Run the critique, then pack it up
★ 22 min · everyone buildsFifteen minutes of critique on your own screen, then the pack. The final scorecard at the end is a ship-or-not gate, not a progress check.
Open with the goal and the constraint. "The goal is that a pause attempt succeeds. Cancel stays one tap. Tell me what you notice, not what to change." Thirty seconds, and it sets the whole meeting.
Five minutes of silence. Everyone reads and writes before anyone speaks. This stops the loudest first opinion becoming the frame that everybody else responds to.
Fifteen minutes of noticing. Observations only. When somebody offers a solution, ask the two questions. Write everything, defend nothing, decide nothing.
Five minutes of deciding. You, out loud: what you will change, what you will not, and what you need to go and check. The room hears the reasoning, which is what stops the same point coming back next week.
Pack it. Screen, tokens, every state, copy deck, behaviours and open questions. Plus the debt table and the two metrics.
Write your opening sentence now. Goal, constraint, stage. If you cannot say the goal in one clause, sessions 1 and 2 have a gap in them and this is a cheap moment to discover it.
Practise the two questions out loud. "What made you notice that?" and "What would you expect instead?" They feel stiff for about a week and then they become the way you listen.
Assemble the five-part pack. Screen, tokens, states, copy deck, behaviours. You have all five from sessions 3 to 5 - this is mostly collection, which is why it is worth having done the work in that order.
Write the behaviours nobody asked about. Slow network. Double tap. Maximum pause length. Pausing during a billing run. Each of these is a decision that will otherwise be made by whoever hits it first.
Write your open questions as questions. The things you genuinely have not decided. Silence in a handoff reads as "not important"; a written question reads as "decide this with me".
Fill in the debt table. Three columns, and do not skip the third. A regret with a trigger is a plan; a regret without one is a complaint.
Write the undo sentence. "If cancellation time rises by more than 10 percent, we revert." One line, before launch, while you are still honest.
Now grade it below. Five rows, ship or not. Any zero is a thing somebody will find in the first week.
If you take one thing from the whole course. Every design decision should trace to something you can point at - a quote, a number, a constraint. Not because taste does not matter, but because taste that can explain itself survives a reorganisation and taste that cannot does not.
Where to go from here
ongoing- Run one critique with the four-part shape this week. Especially the silent five minutes. It is the part people cut and the part that does the work.
- Write one copy deck for something already shipped. You will find at least one string that nobody chose.
- Do a contrast pass on your faint states. Helper text, placeholders, disabled buttons. Twenty minutes, and it is usually the highest-value accessibility work available.
- Start a debt table for your product. Three columns. It becomes the most useful document you own within about two months.
- Then go and build it. learn-html-with-phoebe for the front end, learn-experimentation-with-phoebe to test whether it worked, and learn-system-design-with-phoebe for the platform underneath it. You now know what to ask them for.
Three questions
Clear all three and session 6 gets stamped in your passport - six of six.
1 · Why start a critique with five minutes of silent reading?
Whoever speaks first sets the topic, and everyone after them is agreeing or disagreeing rather than noticing. Silent reading collects independent observations, which is the whole reason you invited more than one person.
2 · A colleague says "the pause button should be at the bottom". What is the most useful reply?
B and C are both correct and both teach the room that feedback costs an argument, so next time you get "looks good". The question turns a proposed solution back into the observation behind it - here, that they read emphasis as importance rather than frequency, which is a real finding about more than this screen.
3 · Why write down the design debt you knowingly shipped, with a third column?
Without the record, the next person either re-litigates a settled decision or preserves a workaround forever out of caution. The third column - what would change this - is what converts a list of regrets into a plan.
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. Daybreak is a teaching scenario throughout.
Session 6 cheat sheet · pin this
Six sessions and one screen, from a complaint in a support ticket to a pack somebody can build. The thing you can do now that you could not do in session 1 is not draw better rectangles - it is to say, out loud, why every part of a screen is the way it is, with a quote or a number behind each answer. That is what makes design work survive other people. Next: learn-html-with-phoebe to build it, learn-experimentation-with-phoebe to find out if it worked, learn-system-design-with-phoebe for what sits underneath.