AI-Product UX

The agent sends it. Nothing on the screen suggested this answer was any less certain than the previous forty, because the interface presents every output the same way.

Every other pattern in this course assumes the system does what it is told. Here it produces something plausible, at speed, with no signal about which parts to check.

What This Domain Changes

Three things separate an AI feature from the rest of the course.

The output is probabilistic.It is usually right and sometimes wrong, and it looks identical either way. Confidence is a property of the writing rather than of the answer.

The input is open.A form asks for a date and gets a date. A prompt box accepts anything, which means people have no idea what this thing can do or how to ask.

It is slow, and unevenly so.A response can take five seconds or thirty, and the same feature can be instant on one request and stall on the next.

Everything in this module follows from those three. The patterns themselves are covered elsewhere: Loading & Skeletons owns waits, Error Messages owns what a broken request says, Empty States owns a blank screen. What changes here is what each of them owes somebody who cannot tell whether the answer in front of them is true.

The Parts You Will Be Naming

Every AI feature, from a one-word autocomplete to an agent, is assembled from seven parts: the input, the context, the wait, the output, the provenance, the controls and the fallback.

The next article defines them and the rules that connect them. The rest of the module takes one part each, which is also the order they go wrong in.

Anatomy of an AI Feature

An inline autocomplete and an agent that books a flight look nothing alike. They are assembled from the same seven parts, in the same order, and a feature that feels untrustworthy is almost always missing one of them.

Naming the parts turns "this AI feature is confusing" into a specific gap you can point at in a design review.

The Seven Parts

1. The input. Where the request is made. Three shapes exist: an open box that accepts anything, a structured form with fields and dropdowns, and an inline suggestion that needs no request at all. GitHub Copilot uses the third, which is why a developer never has to phrase anything.
2. The context. What the model is given besides the request: the selected text, the uploaded documents, the last ten messages, the account's data. The person almost never sees this, and it decides most of the answer.
3. The wait. The gap between request and answer, which in this domain runs from under a second to several minutes and is not predictable in advance.
4. The output. The answer itself, which is a first draft with the appearance of a finished one.
5. The provenance. What the answer rests on: a citation on a sentence, a highlighted source passage, a line saying what was searched. This is the part most features skip.
6. The controls. What can be done to the answer: accept, edit, regenerate, adjust, stop, undo, report.
7. The fallback. The way to do the job without the model, for when it is wrong twice or unavailable.

The Rules That Connect Them

The parts are not independent, and four rules link them.

The input shape sets the output quality.An open box produces vague requests and therefore vague answers, which the person reads as the model being weak. A structured form fixes that by asking for what the model needs.

No scoped context, no provenance.A citation is only possible when the system knows which documents it drew on. Features that pass everything to the model in one blob cannot cite, no matter how the output is designed.

Autonomy sets the size of the undo.The more the feature does without asking, the longer the reversal window has to be. A suggestion needs no undo at all; a batch action that touched 340 items needs days.

The wait determines whether the output can stream, and streaming is what turns a wait into reading time.

Where Features Usually Break

Two parts go missing far more often than the rest.

Provenance is the first, because it costs engineering work and the demo looks fine without it. Fallback is the second, because the team building an AI feature rarely wants to keep the manual route working beside it.

A feature missing both is one bad answer away from being abandoned, since the person can neither check it nor route around it.

Pro tip: Put the seven parts down the side of a page and fill in what your feature does for each one. The empty rows are your backlog, and they are usually provenance and fallback.