Empathy is the job.

• The composite. A persona stitched from twenty interviews, true of none of them.
• The mirror. Designing for yourself and calling it the user. Imagining makes this easy to do, which is why it has to be checked (see “Imagination and evidence”).

• The builder knew the travelers’ phones (one on each of the two major platforms), their landing time (11:37 PM), their first language, their treatments, and that neither had been to the country.
• Each fact became design: safety settings written per phone down to the menu names, a full arrival-night plan, Spanish cards for doctors, a schedule built around recovery.
• They were traveling from the Caribbean, so nights of about 66 °F (19 °C) would feel cold. Warm pants and a jacket went on the packing list.

• Which fact about a real user changed a design decision this month?
• At the moment of highest need, what is my user holding, and what’s the signal?

Pick one real user. In 30 minutes, write next Tuesday for them hour by hour. Mark every hour where your product could help and doesn’t. Take the three biggest gaps to your next planning session.

• The order-taker. Building exactly what was asked, faithfully, and missing the point.
• The hero reframe. Deciding you know the “real” problem without checking, then solving something nobody has.

• The request was roughly “help them plan the trip.” The problem was two nervous first-timers, medical procedures, a midnight arrival and real safety risks in a city they didn’t know.
• That reframing produced the printed emergency card, the decoy-phone plan, the registry checks on the clinic and a “consultation first” decision gate. None of them belongs in an itinerary.
• A traditional spec would have captured the screens, the map and the schedule. The rest came from imagining the trip from inside it, hour by hour.

• If I delivered exactly what was requested, what could still go wrong for this user?
• What does the user not know enough to ask for?

Take the top request in your backlog. Complete this sentence: “They asked for X because they’re trying to Y, and they’re afraid of Z.” If you can’t fill in Y and Z from evidence, go and ask.

• Fluent fiction. Accepting confident AI output because it reads well.
• The citation costume. A source is listed, but it doesn’t say what the sentence claims.

• The research base ran to 38,000 words with 158 sources and was revised 57 times. The app was built from it.
• Claims were checked against primary sources: government health and professional-license registries, the airline’s own rules, the official immigration form site, official consular and travel-advisory pages.
• The Monday of the trip was a public holiday. Research flagged it early, checked which clinics and salons would close, and the plan moved around it.

• Which claims in my product would hurt most if wrong, and when were they last checked?
• What did I look for and fail to find, and did I say so?

List the five claims in your product that would do the most damage if wrong. For each, find the primary source and record the date you checked it. Count the ones you couldn’t verify, and decide what the product should say about those.

• The everything app. Serves all users in general and no user in particular.
• Cutting the small things first. Under time pressure the details go, and the details were the point.

• The scope sentence was two people, one city, one week. That narrowness made it possible to measure every distance from their hotel and write settings for their actual phones.
• The refusals were explicit: no option lists where a recommendation would do, no “New” banners, no jokes in high-stakes sections, no driver details on the public site.
• The app told the travelers what to skip. The tourist sales-tax refund isn’t worth the airport line under about $150 of purchases.

• Can I state who this is not for?
• When I last cut for time, did I cut a feature or a user’s moment?

Write your product’s not-doing list: ten items, one reason each. Then find the thing you’re currently shipping that belongs on it.

• Demo-driven priorities. The work that screenshots well goes first.
• Calendar blindness. The team’s schedule is planned in detail. The user’s isn’t on the wall.

• The flight home left at 3:01 PM. The app worked backwards to the minute: checkout, the drive, the immigration form window, the last possible appointment.
• The pre-trip to-do list carried real deadlines, including the last day to cancel the hotel without paying in full.
• “Save the app for offline in the car to the airport, not earlier.” The product kept improving until departure, and that instruction told the travelers where the last responsible moment was.

• What on my list has a date I don’t control?
• If we shipped today, which missing piece would hurt a user in a way we couldn’t undo?

List everything in flight. Next to each item, write what happens to the user if it’s missing on launch day and whether that can be undone. Re-sort by that column and compare with your current order.

• The menu. Ten options, no pick.
• The unexplained decree. A pick with no reason, which users either ignore or follow blindly.
• Overreach. Deciding something that was the user’s to decide.

• “Book this restaurant Saturday; that one is closed Sunday” replaced a list of restaurants.
• “No stops on the way to the hotel, even if the driver offers” replaced “be careful.”
• The boundary held where it should. When no license record was found for the clinic, the app didn’t decide for the traveler. It changed the recommendation to “consultation first,” laid out the options and left the choice with her. She later chose a different path than the recommendation. Leaving a choice with the user means accepting that.

• Have I decided anything that belongs to the user?

Find one screen that lists options. Rewrite it as one recommendation, a one-sentence reason, and at most one alternative with the condition for choosing it.

• Happy-path design. The demo flow is the only flow.
• The single point of failure. Everything the user needs lives on the one device most likely to be lost.

• The app works with zero signal: on the plane, in the taxi, in dead zones.
• A printed emergency card for each traveler, kept apart from the phone, covers the case where phones and wallets are both gone.
• A “give-up” wallet and a decoy phone were ready to hand over in a robbery, with the real ones hidden.
• One unambiguous rule for the riskiest moment: if the airport car stops anywhere but the hotel, other than for a light, traffic or a police checkpoint, call the emergency number immediately, with the exact Spanish sentence to say.
• The plan included a rehearsal: a drill in which each traveler finds the other’s phone from her own device in under two minutes.

• What is the single device, account or connection my user can’t afford to lose, and what happens when they lose it?
• For my worst case, is there one rule, or a paragraph of advice?

Pick your product’s worst realistic moment and simulate it. Airplane mode, signed out, low battery, wrong language, whichever applies. Try to finish the critical task and write down exactly where it broke.

• The info dump. Everything on day one, nothing retained.
• The late warning. Accurate, and delivered after the mistake.
• The orphaned after. The journey map ends at purchase or at the flight home.

• The departure checklist ran in the order the travelers would hit things at the airport: bags, the liquids rule, security.
• For the immigration desk on arrival: the officer’s likely questions, why they’re asked, and short, true answers in Spanish, readable offline. The builder had pictured a weak airport signal and travel eSIMs not yet connected.
• A lounge-access reminder appeared for the airport. One traveler’s card included access for both, and she didn’t know. They used it on every leg.
• A receipts envelope went in the carry-on before customs. Right after landing came the data-line switch back to the home line, without which the customs app can’t submit. One line, at the last step of the trip.
• After the trip: which records to request from the clinic while it still answers quickly, and a reminder that warranties usually require prompt reporting of problems.

• For each stage of my user’s journey, what’s the one sentence they need in hand?

Draw your user’s journey as seven moments. For each, write one thing that can go wrong and the sentence that prevents it. Then find where that sentence appears in your product and when. Fix the worst mismatch.

• First-name personalization. “Welcome back” and nothing underneath.
• Settings as personalization. The user is handed the controls and told to fit the product to herself.
• Creepy fit. Tailoring based on data the user didn’t knowingly provide.

• Every distance was measured from their hotel: every restaurant, pharmacy, mall, photo spot and clinic.
• Photo days were scheduled around each traveler’s recovery from treatment, with golden hour (5:15–6:00 PM) reserved for the best day.
• The data budget was built on their actual plan: about 11 GB a day, with checkpoints at 1 PM, 6 PM and 10 PM. The checkpoints exist because of a fact someone had to go and find: neither phone can warn on a daily limit.

• Where does my product give advice the user must translate into their own situation?
• Which personalization did we rule out on cost, and when was that cost last estimated?

Find one piece of generic advice in your product (“near downtown,” “check your settings”). Rewrite it for one real user with their actual reference point, device and constraint. Then estimate what it would take to do that for everyone, using today’s tools.

• The invisible companion. The product serves the main user and ignores the person next to her.
• Group as audience. Others can watch, but have no role when something goes wrong.

• Each traveler had her own personal view of the trip, including the companion, who had treatments of her own.
• Phone safety was a 45-minute session to do together, ending in the find-each-other’s-phone drill.
• The arrival-night trick made family part of the safety system: film a cheerful “we made it!” clip that happens to show the driver’s face and the license plate, and send it to the family group chat before the car moves.

• Who is physically next to my user when they use this?
• If one member of the group is cut off, can another restore them?

List every person who touches your product around a single account or purchase. For each, write what they need to see, what they should never see, and what they could do if the main user were unreachable.

• Translation as localization. The words are converted and the context isn’t.
• The phrasebook dump. Two hundred phrases, none of them where they’re needed.

• Ten ”show the doctor” cards in Spanish, one per clinician the travelers might see. Each is a single screen to hand over, saying what she wants, what she’d rather avoid on this trip and what she wants to leave with.
• The exact Spanish sentence for the emergency call on arrival night, a card to hand to a taxi driver, and short answers for the officer at the border.
• The local safety idiom, no dar papaya (“don’t hand them the opportunity”), taught along with the habits behind it.

• At which moments must my user talk to a third party under pressure?
• Are the words for those moments already written, in the right language, on the right screen?

Identify the three moments when your user must speak to a third party under stress: a support call, a professional, an official. Write the exact words for each in the listener’s language, in under 20 words.

• ”Be careful” writing. Concern without instruction.
• Machine voice. Fluent, padded, says nothing wrong and nothing useful.

• The arrival-night rule from chapter 7 is a full specification in one sentence: a trigger, its exceptions, an action and a script.
• “Below this range usually means a cheaper material.” One clause that lets a traveler judge a quote on her own.
• Aftercare for each treatment in plain language: what’s normal, what isn’t, and exactly when to go to the emergency room. The nearest one was a ten-minute walk from the hotel, and the app said so.

• Which sentences in my product require the user to exercise judgment I could have exercised for them?
• If the user could keep only one sentence from this screen, which would it be, and is it first?

Find three sentences in your product containing “may,” “should consider,” “as needed” or “be careful.” Rewrite each with a number, a name or a rule.

• Confetti on the error page. Playfulness at the moment the user is worried.
• The polluted index. A joke entry surfaces in search or gets recommended by the assistant as if real.

• Hidden jokes looked exactly like real entries: a delivery listing for a baby hippo, a “photo spot” that turns out to be an airport fast-food counter. Their ordinary-looking links opened a photo of the builder.
• Allowed only in light-reading places: food, shopping, groceries, photo ideas, packing extras.
• Banned from emergency, safety, arrival night, medical, money, phones, flights and customs.
• Never in search results, never on the map, never in the nightly dinner picks, and never a trigger for an “unread” dot.
• The assistant knew they were jokes. It never recommended one, and if asked about one directly it laughed along, then gave the real answer.

The rules about where a joke may not appear are what make the jokes safe to have. Surprise is a reward for exploring, never a tax on someone who’s stressed.

• Could any playful element in my product be mistaken for real information?
• Do my search, notification and AI systems know the difference?

Write your product’s delight policy as two lists, allowed zones and banned zones. Then check each system that indexes or recommends content and confirm it can tell the difference.

• The alarm for everything. No hierarchy between “your flight leaves” and “we tweaked a label.”
• Engagement bait. Interruptions that serve the product’s numbers and not the user’s day.

• No “New” tags, no “What changed” lists, no banners.
• Small unread dots appeared only on sections whose content had actually changed. After each release the travelers could see where to look.
• Phone alarms were kept for exact times with consequences: check-in opening, leaving for the airport, the form window.

• What did my product interrupt a user for last week, and did it change what they did?

List every interruption your product sent one real user last week. Mark each: did it change a decision? Remove or quiet everything that didn’t.

• The confident error. Stated with the same certainty as everything else.
• The quiet fix. Patched silently, which teaches users that you hide things.
• The blanket disclaimer. “Consult a professional” standing in for doing the work.

• The clinic and its dentists were checked against government health and license registries. When the clinic’s license record wasn’t found, the app said so and the plan changed to ”consultation first, nothing irreversible until a license number checks out.”
• A hard gate sat in front of treatment: the plan in writing, with the final price, before agreeing to anything.
• A 30-second check gave the travelers their own verification before a product was used in a treatment: the brand, the Spanish label, the health-registry number, the lot, a photo.
• The official immigration form is free. Lookalike sites charge $50–100. The app linked only the official one.
• When the app asked a traveler for details she had already sent days earlier, the mistake was noticed and owned, and the request became a short confirmation.

• What did we tell users the last time we were wrong?
• Which irreversible user action currently rests on a claim nobody checked?

Find the last error your product made in front of a user. Write down what you told them, how fast, and which process changed as a result. If the third answer is “none,” expect the same error again.

• Collect now, decide later. Data gathered because it might be useful.
• Privacy by policy. A document says the right thing and the architecture doesn’t.

• Health answers lived only on each phone, in a questionnaire stored there, and filled in the doctor cards there. They never reached a server.
• The driver’s name and plate stayed off the website, on the phones and the printed card only.
• Every release ran an automatic check for names, numbers and codes that must never be published.

• If my server’s contents were published tomorrow, what would users wish I had never collected?

List every data field your product stores about a user. For each, note where it lives, who would see it in a breach, and whether it could live on the device. Move one.

• Prompt and pray. Shipping output nobody read against a source.
• Delegated judgment. Asking the AI what matters instead of telling it.
• Context starvation. Requesting “airport info” when the situation is a midnight arrival with luggage, cash and exhaustion.

• One person held every role: product manager, designer, researcher, developer, tester. AI did the execution in each: the research legwork, the writing, the code, the tests, the releases.
• The builder supplied the questions, the review and the calls. The process was a research report as the single source of truth and an automatic test of every release.
• The AI was wrong more than once. One mistake reached a user: the app asked a traveler for details she had already sent. A person noticed.
• The built-in assistant was taught the house rules, including which entries were jokes.

The cost, stated carefully. The AI cost was about $15–25 of a subscription, not counting the builder’s time. The case study estimates a US agency would have charged $150,000–350,000 for the same scope in five days before AI. That is an estimate, and the small number leaves out the builder’s hours and experience. AI collapsed the cost of execution in this build. It did not supply the knowledge of what good looks like, and that was the expensive part.

• Does my brief carry the user’s situation, or just the feature name?

Pick one feature and write the brief you’d give an AI: the user, the moment, the fear, the conventions, the definition of done and how it will be tested. If you can’t write it, the bottleneck isn’t the tool.

• Rule decay. Standards followed on day one and forgotten by day four.

• 55 releases in one week. Each was tested automatically on phone-sized screens, offline, and for privacy leaks.
• Those three invariants are a description of the users: phone-only, sometimes without signal, with sensitive data in play.
• “Save it in the car to the airport” handled the offline copy: one instruction, at the right moment, for the final version.

• What are my three invariants, and who or what checks them?

Write your three release invariants. Next to each, write whether a person or a machine checks it. Automate one this week.

• Launch and leave. The team’s attention moves on the day the users’ need begins.
• ”I told you so” support. Being right at the user’s expense.

• Before boarding, the driver and plate were confirmed in writing. On arrival, an unneeded second passenger was declined and the ride went straight to the hotel.
• At a store, a price quoted for an untagged bag rose 20% at the register. The traveler walked out and paid less at another branch. The lesson went into the app: no tag, get the price in writing before the register.
• When one traveler chose a different path than the plan advised, the app didn’t argue. Its role shifted to support: calm questions to ask, signs to watch for, and a flight-change plan priced in advance in case an extra day was needed. It wasn’t. The product has to work on the path the user takes, not only on the one you recommended.
• The live support during the trip was part of the product, not an afterthought to it.

• When my users are in their hardest moment, can they reach anyone?
• Do I have a priced plan B for my users’ most likely disruption?

For your last launch, list three things that happened in the field and surprised you. For each, measure the time from the surprise to a shipped change. Set a target for that interval and publish it to the team.

• Sign-off as success. The project closed green and the user was never asked.
• ”Out of scope” as an answer. True, and no help to anyone.
• The ticket that lost its reason. The instruction survived the chain and the purpose didn’t.

• “Done” was never 23 tabs. It was: they land, they get home safe, and the plan held up.
• Here the person who imagined a dark, unplanned stop on the airport road also wrote the rule, chose the words in Spanish, placed them on the arrival screen and tested them offline. A team can’t copy that. It can send the reason with the ticket.

• What is my definition of done, and does the user appear in it?
• Where in my team’s chain does the reason behind a requirement get dropped?

Rewrite your current project’s definition of done as one sentence about the user’s life. Share it with the team and note who objects, and to what.

• Vanity inventory. “23 tabs” presented as a result.
• Survey theater. Asking users whether they liked it, in place of watching what they did.

• Acted on the advice: lounges used on every leg, a 20% price jump refused at a register, the driver verified and an unplanned passenger declined on arrival night.
• Held up under pressure: one traveler was questioned by customs officers at the border. She had followed the guidance, there was nothing to find, and she was released.
• The headline numbers of the build (55 releases, 158 sources, 23 tabs) describe effort. The evidence that it worked is the short list above: incidents from one trip, reported by the builder, with no comparison. That is all the case can claim (see “Limits of this case”).

• Which of my metrics would still look good if users were quietly failing?
• What did a user do last week, outside my product, because of my product?

Write three behaviors that would prove your product worked for a user this week: things they did, not things they clicked. Check whether you could observe any of them today. If not, that’s your instrumentation gap.