Writing about the future of AI in products is mostly a way to be wrong in public. So instead of predictions, here are the design problems that every product adding AI runs into — because those are already visible, and solving them is what separates a feature people use from one they switch off.
Problem one: confidence without calibration
A model answers a question it is certain about and one it is guessing at in exactly the same tone. Nothing in the output distinguishes them, and users cannot tell either.
The design responses that work:
- Show the source. “Based on your invoice from March” lets the user check in one glance.
- Show the working. For anything computed, show the numbers that produced the answer.
- Offer alternatives rather than one answer. Three options presented as options invite judgement; one answer presented as fact invites acceptance.
- Say when it does not know. Rare, valuable, and the fastest way to build trust in the times it does answer.
Problem two: nobody knows what it can do
An empty text box that accepts anything communicates nothing. Users type one thing, get a mediocre result, and conclude the feature is useless — which is a discoverability failure, not a capability one.
What works is boring: show three real examples of what to ask, drawn from the user’s own data. Not “Ask me anything” — “Summarise last week’s calls”, with their actual calls.
The general principle is that a free-text interface is the hardest one to learn, and most products reach for it first because it is the easiest to build.
Problem three: undo has to be real
| What the feature does | What undo must mean |
|---|---|
| Drafts text | Restore the previous version |
| Reorganises data | Full revert, including anything downstream |
| Sends something | Should not be automatic in the first place |
| Deletes or archives | Recoverable for a stated period |
Products that ship an AI action without a real undo see one of two outcomes: nobody uses it, or somebody uses it once and files a support ticket. Both are avoidable.
Problem four: the cost is per use
Traditional software costs the same whether a customer uses it once or ten thousand times. AI features do not — each generation has a marginal cost, and heavy users can cost more than they pay.
That reshapes product decisions in ways teams often discover late: limits become a design problem rather than a pricing footnote, and the interface has to communicate a quota without making the feature feel stingy. Deciding this before launch is much easier than retrofitting a limit onto a feature people already rely on.
Problem five: the trust cliff
Trust in an automated feature does not decay gradually. It works, works, works — and then produces one confidently wrong answer that the user catches, and they stop trusting all of it.
Which is the argument for the earlier points. A feature that shows its sources and its working survives being wrong, because the user can see why it was wrong. A feature that just asserts things does not get a second chance.
The practical version of this: prefer draft-and-approve over full automation for anything the user will be accountable for. It is slower on paper and much faster in practice, because it does not require the user to check everything twice — which is where the time savings actually go.
Common questions
Should every product add an AI feature?
No, and the ones that added a chat box because competitors had one are mostly quietly removing them. Add it where a specific task in your product is slow and verification is cheap.
How do we handle the privacy question?
Say plainly what leaves the product, where it goes, and whether it trains anything. Users accept a clear answer far better than a vague reassurance, and enterprise buyers will ask regardless.
Do we need to label AI output?
Yes, wherever the user might reasonably assume a human produced it. Increasingly a legal requirement in some markets, and unambiguously the right default anyway.
What is the most common design mistake?
Full automation of something with expensive failure. Draft-and-approve is almost always the better shape, and teams reach for it only after the first incident.
Leave a Reply