Design the first-run experience for a user who has never used an AI feature.

How to answer this, stage by stage

Eight moves. Each one has the words you'd actually say. Read them aloud once, then say them your own way.

Let's learn

Say we build a tool that reads a stack of resumes and ranks them. It goes into a small dental clinic. The office manager will be the first person there to touch any AI tool at all.

Before we had it, she read all 40 resumes by hand, one evening a year, after the clinic closed. It took her four hours. She was good at it. She could tell in ten seconds if someone had never worked a front desk.

Now she presses a button and gets a ranked list in ten seconds. That is not the interesting part.

The number barely moved

This is her first time trusting a machine with a decision like this. She has no feel yet for when to believe it and when not to. That feel has to come from somewhere. If we don't build it in, she builds her own, and we don't get to choose what she learns.

So the real design question is not "how do we make a good ranked list." It is what happens the first time the list is wrong.

What I would leave alone. The ranking itself does not need to be perfect on day one. A slightly imperfect order is fine, because she is going to skim the top ten either way, not blindly hire whoever is first. Chasing ranking accuracy before we have earned her trust in the reasons is solving the wrong problem first.

The long version, for when you want to feel why it matters

You don't need this to answer the question. Read it when you want to understand why the answer is right, not just what it is.

Nadia has run the front desk and the books at a six-chair dental clinic for eleven years. Hiring is not her whole job. It is two weeks a year, usually in January, when someone leaves and she has to find the next one. She is good at it in a way nobody ever taught her. She can read a resume and know, almost without thinking, whether someone has actually sat at a front desk with a phone ringing and a patient waiting, or whether they just think they'd be good at it.

Every January until this year, she did it the same way. She'd wait until the clinic closed, make a cup of tea, and go through the whole stack at the kitchen table. Forty resumes, one evening, four hours. By the end she'd have six names on a sticky note and she trusted every one of them, because she'd read every word herself.

The same evening, three ways

This January there is a new tool built into the practice software. It reads the resumes and hands her a ranked list before she has even opened her laptop, the one with the cracked hinge she keeps meaning to replace.

The list is good. Genuinely good. The top three are exactly who she would have picked. She hires the first name on it, a woman named Beth, and Beth is wonderful. In March, Nadia mentions it to Dr. Halvorsen, almost proudly. "The new tool actually found her. Ranked her first."

Then, in June, a second front desk role opens. She runs it again. It ranks a young man named Colton at the top. He interviews well. She hires him.

Colton does not work out. Not dramatically. He is polite and slow to learn the insurance codes and twice sends a patient's file to the wrong fax number. Nothing that gets him fired outright. Just enough that by August, Dr. Halvorsen asks her, gently, what happened with the hiring this time.

And here is the thing Nadia does. She does not say the tool ranked him first. She says she liked his interview. That is not even false. She did like his interview. She just leaves out the part where the ranking is what put him in front of her.

She keeps using the tool. Nobody told her to stop. But from that August on, she reads every resume herself again, the whole stack, the way she used to, and only opens the ranked list afterwards, alone, to see if it agrees with her. If it does, she feels a small private relief. If it doesn't, she never mentions that either.

We lost the one moment in March where she said, out loud, to the person she answers to, that a machine had done something worth trusting. That sentence does not come back once it stops getting said.

I want to say the problem was that Colton was a bad ranking. But Beth was a good one, and it didn't matter. One good pick and one bad pick, and Nadia landed exactly where a fair person would land after that: private use, public silence.

Switch, not dial

So here is the decision, made back when this was still a screen in a design file. We were going to show her a single number next to each name. Ninety-four percent for Beth. Eighty-nine for Colton. Clean, confident, and it tests well in a demo.

Take that number off before it ever reaches her. In its place, three or four lines under each name. For Colton: matched two years of reception experience, comfortable with the phone system. Missing: any mention of insurance billing, which is half the job.

Now walk August forward with that version instead. Colton is struggling with insurance codes. Nadia opens the tool's old note on him, out of curiosity more than anything. It already told her, in June, that billing was missing. It was not that the tool was wrong about Colton. It told her exactly where the gap was. She hired him anyway for the parts he was strong on, which was a real and reasonable choice.

Now when Dr. Halvorsen asks what happened, she has an answer that costs her nothing to say. "The tool flagged that he had no billing background. I hired him anyway because the rest was strong, and that's the part that didn't hold up."

A score asks someone to trust a verdict. A reason lets them share one. We built the version that asks the harder thing first, on the one day she had no practice trusting us at all.

SPARK, in one screen

This is a design question, so the framework is SPARK. (A "what if the error rate doubled" question would use FLIPS instead. Different question shapes get different tools.)

SPARK, for design questions

Run SPARK on a different product

A small accounting firm rolls out an AI tool that drafts the first pass of a client's tax return from their uploaded documents. Same framework, completely different risk.

Same framework, different risk

S. Marcus, a solo bookkeeper with about ninety small-business clients, all due the same week every April.
P. The habit you want: he stops re-entering every number by hand and starts reviewing the draft instead.
A. Flag which documents are incomplete or unusual for that client at intake, before the draft is generated, so a messy client visibly asks for more attention from the start.
R. If one bad draft slips through on a messy client and it costs him a call from the tax office, he doesn't review harder. He starts running only his simplest clients through the tool and quietly types the messy ones from scratch. Full trust at the top of the client list, none at the bottom.
K. Don't try to handle the messy clients automatically on day one. Flagging them is enough, and it's the part that keeps him from writing them off the tool entirely.

Flashcards (click a card to flip it)

Check yourself Score: 0 / 0