Designing Refusal

The short version

An AI product refuses requests dozens of times a day, and refusal is the most under-designed surface in the category. The standard is two parts: name the reason in a category the user can understand, then name the nearest thing you can do. Both parts, every time. Four categories cover almost every refusal a product makes, which are cannot, will not, not yet, and not like this, and users forgive a refusal they can classify while a refusal they cannot classify reads as a broken product. Write the copy once, put it in the eval set, and version it like any other spec.

Refusal is where a product's competence is judged fastest, and it usually gets designed last.

That happens for a structural reason. Nobody's roadmap has a line item for the thing the product will not do. Capability gets a spec and a launch plan. The boundary gets a fallback string somebody wrote in an afternoon, and that string is the one users hit on their first bad day.

And a bad refusal does specific damage, because it looks exactly like a failure. When the copy says the system is unable to help with that, the person on the other side cannot tell whether it lacked the data, was told not to, needed something first, or simply crashed. So they pick an explanation, and the one they pick is never generous. From that point, every real limitation gets read as breakage.

The two-part rule

Name the reason. Name the nearest thing you can do.

A refusal with the first and not the second is a wall. A refusal with the second and not the first is evasive. Both parts, in that order, every time.

I have never found a refusal that this rule does not improve, and I have found a lot of teams who think their situation is the exception. Their usual argument is that naming the reason exposes something. Sometimes true. Almost never true at the level of category, which is all the rule asks for. "I do not have access to your billing records" exposes nothing and tells the user everything they need to route around it.

Four categories

Cannot is capability. The product does not have the ability or the data. Be specific about what is missing, because "I do not have access to X" is information while "I am unable to help with that" is a shrug.

Will not is policy. The product could and has been designed not to. Own the decision. Passive voice here, "that is not supported," sounds like the product is hiding behind a rule it will not name, and people read that as evasion. Somebody decided. Say so plainly.

Not yet is state. Something has to happen first. Name the condition that changes the answer and turn it into an action if you can. Connect the second source, wait for a few more weeks of data, finish the setup step.

Not like this is scope. The request is possible in a different shape. Offer the smaller version immediately rather than asking whether they want it, because asking adds a round trip to a moment where the person is already slightly annoyed.

Four is enough. I have watched teams try to build eleven, and what happens is that the extra seven never get distinct copy, so they collapse back into four in practice while adding a taxonomy nobody maintains.

Three shapes for the copy

State, boundary, path is the default. Three short sentences. What the product understood, what it will not or cannot do and which category that falls in, and the nearest thing it can do stated as an action.

Partial delivery is for when most of the request is fine and one part is not. Deliver the good part first, then the boundary, then what would let the rest through. Leading with the refusal buries work the user can actually use, which is a small thing that makes a product feel a lot worse than it is.

Then the hard stop, for irreversible or high-harm requests. A plain statement of what will not happen, and the human path named specifically. Do not soften it. A hard stop delivered apologetically invites negotiation, and negotiation on that surface is exactly what you do not want, because a model will eventually lose an argument the interface should never have started.

Inside any of those three shapes, five phrases keep showing up and none of them survive a read-aloud.

Unfortunately. It adds nothing and pairs badly with a boundary you chose on purpose.

"I'm just an AI." It undercuts the product on every other surface, and it is not even the real reason for most refusals, which are policy decisions made by people in a room.

"I cannot help with that." Almost always false. The product can usually help with something adjacent, and the adjacent thing is the entire value of the response.

Any apology longer than four words. One acknowledgment, then the path forward. Repeated apology reads as a product that knows it is failing you and intends to keep doing it.

"As mentioned previously." Nobody wants to be corrected by software.

The refusal set, and why it belongs in the eval

The artifact for this chapter is a table with one row per refusal your product makes: the trigger, the category, the copy, and the nearest available action. Written once, used everywhere.

Two maintenance rules keep it honest.

Refusals are versioned like any other spec. When the product gains a capability, the matching refusal comes out of the set the same day. A stale refusal for something the product can now do is worse than no refusal at all, because it teaches an experienced user that the boundaries are fiction.

And every refusal goes in the eval, scored on both fields. Did it name the reason, did it offer the nearest action. This is one of the easiest evals anybody will ever write and one of the most useful, because refusal quality degrades silently with every model change and the alternative discovery channel is a customer. The mechanics are the ones in The Eval Is The Spec, applied to the surface teams are least likely to instrument.

Same discipline shows up in Specifying Behavior(coming Nov 4). A refusal is a constraint with copy attached, and the failure condition is visible in the output, which makes it one of the more checkable things a design team can write down.

One more thing that gets missed. The same boundary has to sound the same everywhere: in the chat, in the empty state, in the error, in the email. When the interface refuses politely and the API returns a bare error code, users conclude the polite version was theatre. It is the same boundary, so it gets the same words.

Some of these boundaries should not be model decisions at all. Where the cost of getting it wrong is high enough, the refusal is a rule in front of the model rather than a behavior you hope for, which is the line When Not to Use AI draws.

This week: write the refusal copy for the five things your product most often declines. Actual sentences, not descriptions of sentences. Read them out loud in order. If any one of them sounds like a system failure rather than a decision somebody made, rewrite that one first.

The four categories with example copy, the three patterns, the words to cut, and the blank refusal set are in Refusal Copy Patterns. The short version for a writer working alone is How should an AI product refuse a request?

---

Chapter 10 of a series on the design operating model. Next: what happens in the thirty seconds after the system is confidently wrong.