AI Product Design
Designing products whose behaviour is probabilistic — where the system can be confidently wrong and the interface has to account for it.
Design DisciplinesConventional software is deterministic: the same input produces the same output, and a wrong result is a bug with a fix. An AI feature is not. It returns a plausible answer with a confidence the user cannot see, it varies between identical requests, and it fails in ways that look exactly like success. Every interface decision follows from that: what the system claims, how a person checks it, and what happens when it is wrong.
Three problems recur. Setting expectations — what the feature can and cannot do, stated before use rather than discovered through failure. Showing provenance — what the answer was based on, so it can be verified without redoing the work. And designing the correction path, which is where most AI features are thin: regenerating is not a correction, it is a second guess. Undo, edit, and a way to say why the output was wrong are what make the feature usable on real work.
Cost and latency are design constraints
A model call can take seconds and costs money per request. That rules out patterns that assume instant, free responses — live previews on every keystroke, speculative generation — and makes streaming, caching and human review design decisions rather than implementation details.
In practice
A contract-review tool surfaced flagged clauses with no source reference. Lawyers had to re-read the document to verify each flag, which took longer than reading it once themselves; use collapsed after a month. Adding a click-through to the exact paragraph with the matched text highlighted turned it into the tool's most-used feature.
Where teams get it wrong
- Presenting probabilistic output with the confidence of a deterministic result.
- No provenance, forcing the user to redo the work to check it.
- Regenerate as the only correction path.
- Interfaces designed around the happy path, where the model is right.
- Ignoring latency and per-request cost until after the interaction pattern is built.
Learn more
You may ask
Frequently Asked Questions
How is designing AI products different from normal product design?
The system is probabilistic. It can be confidently wrong, varies between identical requests, and fails in ways that resemble success — so expectation setting, provenance and correction paths become primary interface concerns rather than edge cases.
Should AI features show confidence scores?
Usually not as a raw number, which people calibrate badly. Showing the evidence behind an answer, or coarse bands tied to a recommended action, helps more than “87% confident”.
What should happen when an AI feature gets something wrong?
The user needs to correct it, not just retry. Editing the output directly, undoing an applied change and recording why it was wrong all beat a regenerate button, which is only a second guess.
Related terms
All terms- Generative UIInterfaces assembled at runtime by a model, rather than laid out in advance by a designer.
- Prompt DesignDesigning what a product asks a model, and what it asks the user — the interface layer around a prompt, not just the wording of one.
- Human in the LoopKeeping a person in the decision path of an automated system — reviewing, approving or correcting before an action takes effect.
- Vibe CodingBuilding software by describing what you want to an AI model and steering the result, rather than writing the code yourself.
Defined by Mara Last reviewed .
Let's talk about your product.
Happy to look at what you're building and say where design would move the needle.
Contact Us