Twenty-One Blank Field Tools, in the Order the Chapters Introduce Them

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.