What is AI product design?

Designing products where the system's output is probabilistic rather than determined. The defining constraint is that the product can be confidently wrong, so the interface has to communicate uncertainty, make correction easy, and decide what happens when the model is mistaken.

How is designing an AI product different?

Conventional software does what it was told; the design question is whether people can tell it the right thing. An AI product produces a plausible answer that may be wrong, which adds three questions no ordinary feature has: how confident is it, how does somebody check, and what does correction cost them.

How should an interface show uncertainty?

Through what the user can do rather than through a number. Confidence percentages are rarely actionable. Showing the source, offering alternatives, letting somebody edit the output rather than accept or reject it, and defaulting to a draft rather than an action all communicate uncertainty in a form people can use.

What is the most common mistake in AI product design?

Designing the successful case. A demo shows the model getting it right, so the interface is built around that path, and the failure case — which in production is a substantial share of uses — gets whatever the engineer decided at the end of the sprint.

Do AI features need different onboarding?

Yes, because people arrive with expectations set by something else and either trust it far too much or not at all. Onboarding has to establish what the feature is good at and where it fails, and the honest version of that builds more trust than the confident version.

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 Disciplines

AI product design is designing products whose behaviour is probabilistic. The system produces a plausible answer that may be wrong, and everything distinctive about the discipline follows from that single property.

Conventional software does what it was told. The design questions are whether somebody can express their intent and whether the result is legible. An AI feature adds three more: how confident is the system, how does a person check it, and what does being wrong cost them.

The questions every AI feature has to answer

What happens when it is wrong? Not whether — how often, how visibly, and who pays. A wrong suggestion in a draft costs a moment. A wrong action taken automatically costs trust and sometimes data.

How does somebody verify it? An output with no route back to its source cannot be checked, which means it has to be taken on faith or ignored. Both are bad outcomes.

How expensive is correction? If fixing the model's answer takes longer than doing the task manually, the feature is a net cost however impressive the output.

What does it do by default? Suggesting, drafting and doing are three different products. The further along that scale, the higher the cost of being wrong.

What is it allowed to do alone? See human in the loop. This is a design decision rather than a technical one, and it should be made deliberately rather than inherited from what the API can do.

Communicating uncertainty usefully

Confidence scores are the obvious answer and mostly a poor one. "84% confident" tells somebody almost nothing about what to do next, and it invites a precision the number does not have.

What works is uncertainty expressed as affordance.

Show the source. An answer with the passage it came from can be checked in seconds. This does more for trust than any score.

Offer alternatives. Three options communicate that the system is choosing among possibilities. One answer implies certainty the model does not have.

Default to a draft. Something editable in place says clearly that it is a starting point, and it makes correction cheaper than rejection.

Make disagreement easy and visible. If correcting the system is a buried control, people stop correcting and start ignoring.

Say what it cannot do. Naming the limits raises trust rather than lowering it, because the alternative is somebody discovering a limit at the worst moment.

Designing the failure case first

The characteristic mistake is designing the demo. The model gets it right, the interface is built around that, and the wrong case is handled by whatever happened to be implemented last.

In production the wrong case is not an edge. Depending on the task it may be a fifth of uses or more, which makes it a primary screen rather than an exception.

Three things are worth designing before the success path.

The recovery. What a person does with a wrong answer, and how many actions it takes.

The partial. Most failures are not total. Four of six extracted fields are right, and the interface has to let somebody fix two rather than redo six.

The refusal. What happens when the system will not answer, and whether the person is told why in terms they can act on.

In B2B, the stakes change the design

Somebody is accountable. An analyst who accepts a wrong figure owns it in a meeting. That changes how much verification the interface has to support, and it is why "trust me" designs fail in enterprise settings that would pass in consumer ones.

Audit matters. What the system suggested, what the person changed, and when. Often a requirement rather than a nicety.

The buyer asks how it fails. Procurement and security reviews ask what happens with bad input and where the data goes. A product with no articulated answer struggles at that stage regardless of how well it demos.

Consistency beats peak quality. A feature that is excellent four times and badly wrong once gets switched off. Professionals optimise for predictability, and an interface that is reliably decent is used more than one that is occasionally brilliant.

In practice

A team ships an AI feature that extracts figures from uploaded documents. It works well in the demo and adoption stalls within a month.

Watching people use it explains why. When the extraction is right, it saves a few minutes. When it is wrong — which happens often enough to matter — the interface offers accept or reject, so a document with one bad field out of eight has to be redone entirely by hand.

The users had done the arithmetic before the team did. The average time saved was negative, because the occasional full redo cost more than the frequent small saving returned.

The fix is not a better model. It is making each field editable in place, showing which part of the document each figure came from, and flagging the two the system was least sure about. Same model, same accuracy, and a feature people now use.

Where teams get it wrong

Designing the demo. The success path is the easy half.
Confidence percentages. A number that changes nothing anybody does.
Accept or reject on a partial result. Forcing a full redo for one wrong field.
Automating before earning trust. Doing is a much higher bar than suggesting.
No route to the source. An answer that cannot be checked gets ignored or over-trusted, and both are failures.

Learn more

UI/UX design for B2B SaaS →