Twenty-One Blank Field Tools, in the Order the Chapters Introduce Them
Every tool in this book has a blank, reusable version on these pages, in the order the chapters introduce them.
Companion to You Are Not the User · Updated 2026-09-29
Every tool in this book has a blank, reusable version on these pages, in the order the chapters introduce them. Each one starts with a line saying when to reach for it and names the chapter that runs it on a worked example. Fill in one copy per workflow or claim, and keep it next to the decision it informed. The three AI prompts the book introduces are in the prompt library.
- Trace Where the Need Changed Meaning Along the Handoff Chain
- Ask Which of Five Parties “the Customer” Means
- Weigh What Each Function Sees Well and Systematically Misses
- Find Which Testing Question Was Actually Answered
- Do Not Treat a QA Pass as Proof That Users Can Do the Job
- Say How Far a Tester Was From the Person Who Does the Job
- Attach an Honest Label to Any UAT Result From a Non-User
- State How Strong the Evidence Is Before a Claim Drives a Decision
- Put a Product Change on One Page With Its Evidence
- Count the Behavior Before Arguing About It
- Keep the Pain and Test the Diagnosis in Each Complaint
- Observe How the Task Is Really Done
- Interview for What People Did
- Turn “Easy to Use” Into Things You Can Measure
- Rank Workflows by Frequency and Friction to Choose What to Fix First
- Check What a Change Does Beyond the One Screen
- Put a Number on What a Change Does to One Unit of Work
- Split “the User” Into the Kinds of People the Workflow Serves
- Get Working Alternatives in Front of Real Users Within Days
- Run the Monthly Product Review on What Users Did
- Check That No Stand-In Did a User’s Step
In this section
- Trace Where the Need Changed Meaning Along the Handoff Chain
Use this when a shipped feature surprised the people it was built for and you want to see exactly where the meaning changed.
- Ask Which of Five Parties “the Customer” Means
Use this when anyone says “the customer” about a workflow and you need to know which of five different parties they mean.
- Weigh What Each Function Sees Well and Systematically Misses
Use this when you need to weigh what each internal function tells you about users, knowing what each one sees well and what it systematically misses.
- Find Which Testing Question Was Actually Answered
Use this when someone says “we tested it” and you need to know which of the six questions was actually answered.
- Do Not Treat a QA Pass as Proof That Users Can Do the Job
Use this when a team is treating a QA pass as proof that users can do the job, or scheduling UAT that is really a second round of QA.
- Say How Far a Tester Was From the Person Who Does the Job
Use this when you need to say how far a tester was from the person who does the job, which tells you how much weight the result can carry.
- Attach an Honest Label to Any UAT Result From a Non-User
Use this when a UAT result came from anyone other than a real user, so the result travels with an honest label.
- State How Strong the Evidence Is Before a Claim Drives a Decision
Use this when a claim about users is about to drive a decision and nobody has said how strong the evidence behind it is.
- Put a Product Change on One Page With Its Evidence
Use this when anyone proposes a product change; the brief travels with the proposal and fits on one page.
- Count the Behavior Before Arguing About It
Use this when a team is about to argue about how users behave in a workflow the product could already be counting.
- Keep the Pain and Test the Diagnosis in Each Complaint
Use this when a complaint or a feature request arrives with a diagnosis attached, and you want to keep the pain and test the diagnosis.
- Observe How the Task Is Really Done
Use this when you need to see how a task is really done, rather than hear how it’s usually described.
- Interview for What People Did
Use this when you can only interview, not observe, and you want the interview to produce evidence about what people did rather than what they think they do.
- Turn “Easy to Use” Into Things You Can Measure
Use this when someone says a workflow should be “easy to use” and you need to turn that into things you can measure.
- Rank Workflows by Frequency and Friction to Choose What to Fix First
Use this when you have more friction to fix than time to fix it and need to know which workflow to fix first.
- Check What a Change Does Beyond the One Screen
Use this when a proposed change looks good on one screen and you need to check what it does to the rest of the system.
- Put a Number on What a Change Does to One Unit of Work
Use this when you need to put a number on what a workflow change does to the cost and value of one unit of work.
- Split “the User” Into the Kinds of People the Workflow Serves
Use this when a workflow serves more than one kind of person and someone has written “the user wants” as if there were only one.
- Get Working Alternatives in Front of Real Users Within Days
Use this when you’ve observed a problem and want working alternatives in front of real users within days.
- Run the Monthly Product Review on What Users Did
Use this when leadership reviews product decisions every month and you want the meeting to run on what users did rather than what the room believes.
- Check That No Stand-In Did a User’s Step
Use this when you want to check that a piece of product work went through the whole loop without a stand-in doing a user’s step.
