learn-product-design-with-phoebe / Session 3 of 6
Learn Product Design with Phoebe · Session 3 of 6

Structure and flow

Most screens that feel confusing are not badly styled, they are badly shaped. Tonight you build the shape: what the person is doing step by step, what has to be visible at each step, and how much you lose every time you put something one level deeper. You will draw it badly on purpose, because a polished mock gets you feedback on the polish and a grey box gets you feedback on the thinking. There is a halfway scorecard at the end.

🟡 Medium Anyone who has been told a screen is "cluttered" Halfway scorecard tonight 45 min
0-3 · Welcome 3-18 · Nesting cost, flows, and the states trio 18-40 · Build-along: the ugly wireframe 40-45 · Q&A
Part 0

Where we are

Session 2 said this is at least two problems: people who want a break, and people who want less coffee permanently. Tonight the screen has to serve both without becoming a control panel.

🎫 Clear all three quiz questions to stamp your passport Live = presented in the 45 minutes Self-study = the full depth, after class

★ What you walk out with tonight. A task flow drawn as steps a person takes, a deliberately ugly wireframe of the screen, the three non-happy states written out, and an honest halfway grade on the work so far.

Part 1 · covers nesting

Every level down costs you people

6 min live

Information architecture sounds like a filing exercise. It is not. It is the decision about who gets to complete their task and who gives up, and it is made mostly by accident.

What Daybreak has now Manage subscription └ Cancel subscription 1 tap └ Options └ Delivery preferences └ Pause deliveries 3 taps The action that saves the customer is two levels below the one that loses them. Nobody chose this. What session 2 says it should be Manage subscription └ Pause deliveries └ Skip next box └ Change how often it arrives └ Cancel subscription Four actions, one level, ordered by what people actually came to do. Cancel is still there. Note what did not happen: cancel was not hidden, moved or made harder. It was simply no longer the only door anybody could find. That distinction is the whole ethics of this screen.
🔍 Click to zoom - flattening is not the same as hiding, and a reviewer will check which one you did
LiveThree rules for a structure that holds4 min▶
  • Name by task, never by container. "Options", "More", "Settings", "Preferences" and "Account" are all words that describe your filing system. Session 2's participant did not just fail to find pause inside Options - they actively ruled it out, because Options told them it was about notifications. A wrong label is worse than no label.
  • Depth is a budget, and the primary task spends none of it. Whatever the person came to do should be visible without a tap. Everything else can be one level down. If you have three levels, at least one of them is a filing decision that leaked into the interface.
  • Order by frequency of intent, not by your data model. Daybreak's menu was ordered by how the backend groups these operations. The new order is how often somebody arrives wanting each one.

Progressive disclosure is a real and useful idea - hide complexity until it is needed. It becomes an excuse the moment it is used to hide the primary task. The test: is the thing behind the disclosure the reason most people opened this screen? If yes, that is not disclosure, that is a menu problem wearing a design word.

Part 2 · covers flows and states

Draw the steps a person takes, then draw the three states nobody draws

7 min live

A flow is not a sitemap. It is one person, one intention, and everything that happens between deciding and being done - including the parts that happen after they close the tab.

Trigger booking a trip, 3 days before Arrive account page, on a phone Choose pause, and for how long Confirm what happens to price and place Resume a reminder, 3 weeks later The last box is the one everybody forgets to design Session 2, participant 4: "I paused it once. I never got told when it was starting again, so I forgot and then a box turned up." A successful pause that still produced an unhappy person. A flow that ends at the confirmation screen ends before the part where trust is actually won or lost.
🔍 Click to zoom - the flow ends when the person's goal is met, not when your screen is dismissed
LiveThe trio: empty, loading, error5 min▶

On a screen like this one, these are not edge cases. This is a page people visit when something is already not going to plan, so the non-happy states carry more of the relationship than the happy one does.

StateBad versionWhat it should do
Empty"No paused deliveries."Explain what pausing does and what it protects: "Pausing keeps your price and your place in the roast queue."
LoadingA spinner in the middleSkeleton rows in the shape of the content, so the layout does not jump and the wait feels shorter
Error"Something went wrong."What happened, whether anything changed, and what to do: "We could not reach your subscription. Nothing has changed. Try again."
The sentence that fixes most error messages

"Nothing has changed." On a screen about money and deliveries, the person's first fear is that they half-did something. Telling them the state of the world is more valuable than apologising, and it takes three words.

Self-studyWhy the wireframe should be ugly3 min▶

Fidelity is a signal about what kind of feedback you want, and people read it accurately.

  • A grey-box wireframe says "the structure is the question". You get "why is cancel next to pause" and "where does the date go".
  • A polished mock says "this is nearly done". You get "can the button be blue" and "I am not sure about that font", from the same people, about the same screen.

This is not a criticism of the reviewers. They are responding correctly to the artifact you handed them. If you want structural feedback, hand over something that visibly has no styling opinions yet - and say out loud "ignore how it looks, tell me if the order is wrong".

The corollary matters just as much: when you do want visual feedback, do not bring a wireframe. Session 4 is where fidelity earns its place.

Build-along

The ugly wireframe, and the three states

★ 22 min · everyone builds

Paper, or grey boxes in any tool. No colour, no type choices, no icons. If you catch yourself picking a font you have left the exercise.

Flow. One person, one intention, drawn as steps including the trigger before your product and the follow-up after it. Five boxes is usually right.

Inventory. Everything the screen must show or do. Write it as a flat list first. Daybreak's is eleven items, and four of them turn out to be the same item described differently.

Order. Sort the list by how often somebody arrives wanting it. Not by importance, not by your data model. Frequency of intent.

Wireframe. Grey boxes, real words. Real words matter - lorem ipsum hides exactly the problem you are looking for, which is that your label is four words too long.

States. Write the empty, loading and error copy now, in the wireframe, at the same fidelity as everything else. Not later. Later means never.

Draw the pause flow, five boxes. Include the trigger before the screen and the resume reminder three weeks after it. Most flows in the wild start at "user lands on page", which is why so many products have nothing to say at the end.

Write the inventory as a flat list. For Daybreak: current coffee, next delivery date, pause, skip, change grind, change frequency, cancel, billing, address, order history, help. Eleven items.

Now cut it. Which of those eleven does someone arrive wanting on this screen? Billing, address and order history belong elsewhere and are on the screen only because somebody once needed a place to put them.

Order what is left by frequency of intent. Pause, skip, change frequency, change grind, cancel. Notice that this order came out of session 2, not out of taste.

Draw it in grey boxes with real words. Then read the labels out loud. "Change how often it arrives" is long and it is still better than "Frequency", which is a database column wearing a coat.

Write the three states. Empty, loading, error, in real sentences. Include "Nothing has changed" in the error. Time yourself: this takes about six minutes and it is the six minutes most often skipped.

Show it to somebody and say the magic sentence. "Ignore how it looks, tell me if the order is wrong." Then write down what they say without defending anything. Session 6 is entirely about that skill.

Your problem statement names a person and a moment, with no product words in it From session 1. If a feature name appears in the problem, it is a solution wearing a problem's clothes.
At least one belief died in research Something you predicted turned out wrong and you wrote it down. If nothing did, the questions were probably leading.
Every structural decision traces to a quote or a number The order of the menu came from frequency of intent, not from taste. You can point at where it came from.
Nothing on the screen is named after a container No Options, no More, no Settings, no Preferences. Every label names a task a person came to do.
The empty, loading and error states exist as real sentences At the same fidelity as the happy path, written now rather than promised for later.

If you take one thing from tonight. Real words in the wireframe. Lorem ipsum hides the single most common structural problem there is, which is that the label you need is longer than the space you drew for it.

Homework

Before session 4

30 min
  1. Wireframe your own screen in grey boxes with real words. No colour. Bring it to session 4, because session 4 is where it gets a visual system and a score.
  2. Count your levels. How deep is the primary task on the thing you own? If the answer is more than zero taps from arrival, work out why.
  3. Find a container label. Every product has an "Options" or a "More". Write down what a new person would assume is inside it, then check what actually is.
  4. Write your three states as sentences. Include "nothing has changed" in the error if it is true.
  5. Ask one person to talk through your wireframe. Say the magic sentence. Write down what they say, defend nothing.
Check yourself

Three questions

Clear all three and session 3 gets stamped in your passport.

1 · A participant said they assumed "Options" was notification settings. What kind of problem is that?

A wrong label is worse than no label. "Options" did not fail to attract them, it actively told them the answer was elsewhere, so no amount of prominence would have helped. Rename before you rearrange, and never name anything after a container.

2 · Why show a grey-box wireframe rather than a polished mock when you want structural feedback?

Reviewers are not being unhelpful when they comment on the font - they are reading the artifact correctly, because a finished-looking thing implies the structure is settled. The corollary holds too: when you want visual feedback, do not bring a wireframe.

3 · What three words fix most error messages on a screen about money and deliveries?

The person's first fear is that they half-did something irreversible. Telling them the state of the world beats apologising, and it beats instructions too - once they know nothing broke, "try again" becomes obvious rather than anxious.

Sources covered

What this session teaches, and where it came from

✓Information architecture as the cost of nestingDaybreak's cancel-at-1-tap against pause-at-3-taps, and the distinction between flattening and hiding
✓Naming by task, never by containerOptions, More, Settings and Preferences as labels that rule an action out rather than fail to advertise it
✓Task flows before screensFive boxes including the trigger before your product and the follow-up after it, which is where trust is won
✓Low-fidelity wireframes and the fidelity signalGrey boxes with real words. Lorem ipsum hides the label that is four words too long
✓The empty, loading and error trioWritten at the same fidelity as the happy path, with "nothing has changed" as the three words that fix most errors
◐Card sorting and tree testingNamed as the methods that validate an IA against real people. Running them is out of scope for a 45-minute session

Every fact on this page, and its verification tier, is recorded in the course's source map. Daybreak is a teaching scenario and its figures are part of the exercise.

Session 3 cheat sheet · pin this

Depth is a budgetThe primary task spends none of it. Three levels means a filing decision leaked into the UI.
Never name a containerOptions, More, Settings. A wrong label rules the action out; it does not just fail to advertise it.
Flatten, do not hideCancel stays exactly where it was. It just stops being the only door anyone can find.
Flows end after the screenThe resume reminder three weeks later is part of the task. Trust is won there.
Real words, grey boxesLorem ipsum hides the label that does not fit. Fidelity signals what feedback you want.
"Nothing has changed"Three words that fix most error messages on any screen about money.