Flows and states
Draw the ten-state chart of a model-backed screen before the mock, then give each state a daily count and a screen the agent can act on.
On this page
The design file for a drafting feature usually shows one screen: a ticket on the left and a finished, correct draft on the right. That is one state out of ten. Every screen already had six (idle, loading, empty, partial, error, done) and a model adds four: streaming, refused, wrong and over budget. The chart of all ten comes before the screen because at 48,000 drafts a day a state that happens once in a hundred calls happens 480 times, and the agent who meets it sees whatever the engineer improvised.
Six states every screen already had
The running example is one tenant: 1,200 agents at 40 tickets a day, 48,000 tickets, each offered a draft. That assumes the tenant's queue sits wholly inside the intents the assistant covers, coverage 1.0 against the 0.60 the North Star averages across tenants.
Idle. The ticket is open and nothing has been asked. The one decision is whether the draft starts on open or on a click; the third question at the end prices it.
Loading. The request has left and nothing has come back. A skeleton sits where the draft will land, never a spinner over the composer, because the agent can keep typing and a spinner says not to.
Empty. Nothing to draft from: retrieval found no help article close enough, so the service declines to call the model rather than draft without a source, one answer to the choice reading an architecture poses for a retrieval timeout. The screen says why in one line and hands the composer back. Drawn as loading, it leaves the agent waiting for a draft that is not coming.
Partial. Part of the answer arrived. On a list that is half the rows; on a draft it is a reply cut mid-sentence because the stream dropped or the output cap was hit.
Error. A timeout, a server error, a rate-limit response. Retry once without telling the agent, with an idempotency key so a slow success and its retry do not put two drafts in the composer and two calls on the bill; then show a one-line reason.
Done. The draft is complete and Insert is live.
Most mocks draw idle and done with a spinner between them: two of the six, before the model has added anything.
Four states the model adds
Streaming. The last token arrives at 2.1 s at the median and 6 s at the p95, the first at about 400 ms, so for most of every call the draft is neither loading nor done. Insert waits for done, with a Stop control beside the text. The draft streams into a suggestion area above the composer, never into text the agent is writing. The non-deterministic UI sets its clock.
Refused. The model declines: a ticket that reads like a request for another customer's details, or one its instructions rule out. The call succeeded, so this is not an error, and the same prompt usually refuses again, so Retry is the wrong control. The screen is the composer with a one-line reason. Code tells refused from done only by the stop reason or a structured-output field, so the PM asks for that field first (reading the response).
Wrong. The draft is complete, well formed and wrong: last year's price, a refund the policy forbids, a tone off the house style. To the system it is identical to done; only the agent, reading, can enter it. Its exits (edit inline, regenerate, report) are the most important design on the screen. The golden set fails 8% of drafts: half a point on facts, one draft in 200 and the most the launch gate allows, and 7.5 points on tone. So this tenant enters the wrong state about 8% × 48,000 = 3,840 times a day, 0.5% × 48,000 = 240 of them on a fact.
Over budget. The feature has a cost guardrail (cost per untouched resolution under $0.03, from AARRR and guardrails) and the tenant may have a monthly draft cap. When either trips, the model is not called, and 1,200 agents see either a generic error they retry and report, or the reason and the reset date.
The chart before the screen
Each arrow is a trigger, and each trigger is a product decision needed before the screen exists. Loading to empty: what match score counts as "no article"? Streaming to partial: is a draft cut at 250 of 300 tokens kept, and one cut at 40 discarded? Done to wrong: how many actions does a correction take, and where does a report go? An engineer who meets these mid-sprint picks the cheapest answer, usually a red toast saying "Something went wrong".
The mistake: designing the done state
The designer mocks done, the engineer builds done, and the other nine states turn up in the pilot. In week one: a skeleton that never resolves, because empty was drawn as loading; a half-sentence inserted into a customer reply, because partial had no rule; a red toast for a refusal, so agents click Retry and pay twice; a draft landing on top of a reply the agent started at 3 s; and, when the cap trips, 1,200 agents seeing the same toast at once. None is a model problem. Each is a state nobody drew.
The fix is one table, written with the chart, before any mock. Where a rate is not yet measured the cell says so, and that cell becomes an instrumentation line in the spec, beside the eval and cost lines what changed and what did not adds to it.
| State | The agent sees | The agent can | Per day, at 48,000 |
|---|---|---|---|
| Loading | a skeleton | keep typing | every draft, under 1 s |
| Streaming | text arriving | stop it, keep typing | every draft, 0.4–2.1 s at p50 |
| Done | the draft, Insert live | insert, edit, regenerate | about 44,000 |
| Wrong | a draft that is wrong | edit, regenerate, report | about 3,840; 240 on a fact |
| Empty | "No article matches this ticket" | write the reply | not measured; 1% is 480 |
| Refused | a one-line reason | write the reply | not measured; 1% is 480 |
| Partial | the cut draft, marked | continue, regenerate, discard | not measured |
| Error | a reason, after one silent retry | write the reply | not measured |
| Over budget | the reason, the reset date | write the reply | zero, then all of them |
Two things fall out of the last column. Wrong, at 3,840 a day, is the biggest number after done, four times empty and refused together at 1% each, so it gets the most design: designing for "the model might be wrong" makes each of its exits one action. And over budget jumps from nothing to everything in a minute, so its message is written with sales and the tenant's admin, not by the engineer on call.
In an interview
"Design the screen for an AI drafting feature" tests whether you design for volume or for the demo. Draw the chart first and say it: "Six states every screen has, four the model adds: streaming, refused, wrong, over budget. Wrong matters most because the system cannot detect it. At 8% of 48,000 that is 3,840 a day, so correction is one action and every report feeds the eval set."
The mistake that loses points is drawing one screen, the done state with good data, and a spinner. The second is folding refused and wrong into error: a refusal is a successful call that retrying will not change, and a wrong draft is one the system believes is right, so an error toast handles neither.
Check yourself
1. Refusals turn out to be 0.4% of drafts. The designer proposes folding refused into the error state, Retry button included, to save a screen. Decide.
Keep refused separate. 0.4% × 48,000 is 192 a day, and a retry sends the same prompt, which usually refuses again: two calls, two waits, and an agent who learns that Retry does nothing. What would change it: one retry clearing more than half of refusals, which would justify a silent retry, still with no button.
2. The tenant's contract caps drafts at 1.2 million a month. Estimate when over budget arrives, and decide what the agents see.
48,000 a day × 30 = 1.44 million a month, so the cap trips on day 25 (1.2 million ÷ 48,000), and 1,200 agents draft by hand for the last five or six days of every month. That is a pricing conversation before it is a screen. Warn the tenant's admin at 80%, day 20; on the day it trips, agents see the reason and the reset date, never an error.
3. An engineer proposes starting the draft only when the agent clicks, to stop paying for tickets closed without a reply. One ticket in ten closes that way. Decide.
4,800 drafts a day × $0.009 is about $43 a day, roughly $1,300 a month. Drafting on click adds a click and a wait on each of the 43,200 tickets that do get a reply; drafting on open usually finishes before the agent has read the ticket. Draft on open, unless a tenant closes half its tickets unread.