Designing products when AI is part of the interface
Three guarantees your users relied on, and what to do now that you cannot make them
Thesis
Put a model inside a product and you break three promises that every interface before it made implicitly.
Determinism. The same action produces the same result. Users depend on this to build a mental model.
Discoverability. The interface shows you what it can do. Buttons, menus and affordances are a visible inventory of possible actions.
Reversibility. You can undo what just happened, and you know what "what just happened" was.
A text box connected to a model breaks all three at once. Same input, different output. No visible inventory, because the input space is a blank field. And the change it made may be diffuse enough that undo is not obvious.
The design work in an AI product is mostly the work of restoring those three guarantees by other means. Not making the model look magical. Not adding sparkle icons. Restoring determinism where you can, replacing discoverability with something that does the same job, and making reversibility total.
Context
The default AI interface in 2026 is a chat window, and it became the default for a reason that has nothing to do with it being good: it is what the underlying API looks like. Text in, text out. Building a chat interface requires no product decisions at all, which is why it is everywhere.
Chat is genuinely excellent for a narrow set of jobs. Open-ended exploration, where the user does not know what they want. Iterative refinement of language. Anything where the conversation itself is the product.
It is poor at nearly everything else, and specifically it is poor at the thing most products need, which is helping a user accomplish a bounded task inside a system with state. A chat box in front of a structured product is a command line that does not document its own commands. Users type something, get something unexpected, and have no way to work out what the acceptable inputs were. Norman's language is useful here: an interface with no signifiers gives the user no way to bridge the gulf of execution. They know the goal and cannot see the action.
This matters commercially rather than aesthetically. The most common failure in AI products right now is not bad output. It is users who cannot work out what to ask for, decide the product is not for them, and leave without ever seeing what it can do.
Research
The human factors literature worked on this problem for decades before language models existed, in aviation and industrial control, and it produced findings that transfer almost unchanged.
Bainbridge, 1983, "Ironies of Automation". The central irony: automating a task degrades the operator's skill at that task and their awareness of the system's state, and the moment the automation fails is exactly the moment you need both. This is the argument against automating something fully rather than partially, and it applies directly to any product where the model does the work and the human is expected to catch the mistakes. A human kept out of the loop is a poor supervisor of the loop.
Parasuraman and Riley, 1997, on use, misuse, disuse and abuse of automation. Their taxonomy names two opposite failures. Misuse is overreliance: the human stops checking, because the system is usually right. Disuse is rejection: the human switches it off after it is wrong once. Both are consequences of the interface failing to communicate reliability accurately, and both are extremely visible in current AI products.
Amershi et al., 2019, "Guidelines for Human-AI Interaction". Eighteen guidelines synthesised from two decades of prior work and validated across real products. The ones that bear on this argument: make clear what the system can do, make clear how well it can do it, support efficient correction, support efficient dismissal, and scope services when in doubt. That is a design specification for restoring discoverability and reversibility, written before the current wave of products ignored it.
Turpin et al., 2023, on unfaithful chain-of-thought. A model's stated reasoning can be systematically shaped by features it never mentions. If your interface displays the model's explanation as a justification, you may be displaying a post-hoc rationalisation, and users will trust it because it reads like reasoning.
Nielsen's response-time limits, 1993, restating Card et al., 1991. The 0.1 second threshold for direct manipulation and the 1 second threshold for uninterrupted flow. Inference does not meet either, which is a design problem rather than an engineering one.
Argument
Restoring determinism: separate the deterministic parts and make them look deterministic.
Not everything in an AI product needs to be probabilistic, and treating the model as the interface to everything is a mistake. If the user wants to change a title, that should be a text field. If they want to sort by date, that should be a control. Routing a deterministic operation through a model makes it slower, more expensive and less reliable, and it removes the user's ability to predict the outcome.
The useful pattern is a clear seam: structured controls for anything specifiable, model assistance for the genuinely open-ended, and a visible difference between the two. Users can then form an accurate mental model, which is: this part always does what I expect, that part is a collaborator.
Restoring discoverability: the model's capability has to be visible before use, not discovered through failure.
A blank text box communicates nothing. The substitutes that work are unglamorous and effective. Suggested actions that reveal the shape of what is possible. Examples that are specific enough to be templates rather than gestures at a category. Progressive scoping, where you offer a narrow set of things the system does well rather than an open field it handles unevenly. Amershi et al.'s "scope services when in doubt" is the same instruction: a narrower promise kept is worth more than a broad one broken.
The counter-intuitive part is that constraining the input increases perceived capability. A product offering six things it does reliably feels more capable than one offering anything and succeeding sometimes, because the user's experience of capability is built from successes, not from the size of the input field.
Restoring reversibility: undo must be total, and it must cover what the model did.
This is the guarantee it is least acceptable to break and the one most often broken. If a model modifies a user's document, project or data, every part of that change must be reversible in one action, and the user must be able to see what changed before deciding.
The stronger version of this principle, which I would apply as a rule: an AI acting on a user's work should propose rather than apply. A visible diff the user accepts is categorically different from a change that has already happened. It preserves agency, it makes review possible, and it means a wrong suggestion costs a glance rather than a recovery.
And the fourth thing, which is not a restoration but an addition: provenance.
A traditional interface does not need to tell you where its content came from, because it all came from the same place. An AI interface mixes retrieved fact, computed result, user input and generated text, and presents them in one visual register. That is the mechanism by which hallucination becomes damaging: the invented restaurant is styled identically to the real one.
So provenance has to be a design element. Not a citation footnote nobody reads, but a visible distinction at the level of the individual claim, strong enough that a user can tell what to check. This is genuinely hard to do without clutter and it is the open design problem of this product generation.
Uncertainty, communicated in a way that changes behaviour.
Confidence scores are close to useless in user interfaces. A number between zero and one is not something a person can act on, and it invites both of Parasuraman and Riley's failures: overreliance on high numbers and rejection after a high-confidence miss.
What works is behavioural rather than numeric. When confidence is low, show alternatives rather than one answer. When information may be stale, say when it was retrieved. When the system is guessing, ask instead of asserting. The interface should change shape with confidence, and the user should never have to interpret a probability.
Waiting, which is where most AI products feel broken.
Inference does not meet the 0.1 second threshold, so a direct-manipulation feel is unavailable. That leaves two honest options: acknowledge instantly and show progress, or make the work explicitly asynchronous and let the user do something else. The unacceptable option is the one most products choose, which is an undifferentiated spinner.
An agent doing multi-step work has real, nameable phases. Showing which one is running converts an opaque wait into visible progress, and it costs almost nothing. Users tolerate long operations they can watch. They abandon short ones they cannot.
Examples
A writing tool. The wrong design is a chat panel beside the document. The right one is inline suggestion with a visible diff, accepted or rejected per change, with the rest of the editor entirely deterministic. The model proposes; the user's document changes only by the user's action.
A data product. The wrong design is a natural-language query box that returns a chart. The right one shows the interpretation before executing: here is the filter, the grouping and the date range I understood, edit anything before I run it. That interpretation panel is the constraint object made visible, and it is the single most useful pattern in AI product design, because it makes the system's model of the user's intent auditable.
A creative tool. An agent that can add tracks, alter clips and generate material has to be a sequence of proposals rather than an ambient presence. Every action reversible, every generated element marked as generated, the user's hands on the object throughout. In a creative context the user's sense of authorship is the product, and an agent that acts unasked takes it.
A support product. Retrieved policy text and generated summary must be visually distinct, because the consequence of confusing them is a customer being told something false about their account.
Counterargument
"Users love chat. ChatGPT has hundreds of millions of users. You are over-designing a problem the market has already solved."
This is the strongest objection and it contains something true. Chat has demonstrated enormous product-market fit. It is learnable in seconds, requires no visual language, works identically on every device, and its flexibility means one interface serves an unbounded set of tasks. Adding structure adds design cost, maintenance cost and the risk of constraining users to what you anticipated.
There is a sharper version: the uncertainty and provenance apparatus described above adds visual complexity that users may not want. People do not read citations. They do not check diffs. Designing elaborate honesty mechanisms into a product that users respond to with speed and confidence may be optimising for a critic rather than a customer.
Where this is right. For open-ended assistance, chat is the correct interface and structure would make it worse. And there is a real risk of building a product that is scrupulous, cluttered and less pleasant than a competitor's confident one. Some honesty mechanisms genuinely do not pay for their pixels, and you should test rather than assume.
Where I think it is wrong. ChatGPT's success is evidence that chat works when the conversation is the product. Almost no other product is in that position. The moment the AI is a component inside a system with state, the blank field stops being flexible and starts being unmarked. And the products where users happily accept confident output are the ones where errors are cheap. As consequence rises, the tolerance for unverifiable confidence collapses, and it collapses suddenly rather than gradually, usually after one memorable failure.
So: chat where the conversation is the product, structure where the AI is a component. The failure mode is using chat because it was the shape of the API.
Practical implications
Draw the seam explicitly. List what is deterministic and what is probabilistic in your product. Make them visually distinct. Do not route specifiable operations through a model.
Never ship a blank field as your only entry point. Suggestions, examples or scoped actions. The input has to teach.
Make undo total, including model actions, and prefer proposals to applications wherever the model touches something the user made.
Design provenance at claim level. If a user cannot tell which parts to check, the retrieval is not doing its job.
Replace confidence scores with behaviour. Alternatives instead of one answer, questions instead of assertions, timestamps on anything that decays.
Name the phases of any multi-step operation and show which one is running. A spinner is a design decision not to communicate.
Make correction cheaper than redoing. If fixing the output takes longer than doing the work manually, the feature is negative value however good it looks in a demo.
Watch for both automation failures. Overreliance means your interface is projecting more certainty than it has. Rejection after one error means it projected certainty and then broke it.
My perspective
Opinion, from my own work.
The interface problem I found hardest is where an agent lives. Every other element in a product owns a region of the screen. An agent acts across all of them, which means it does not fit the spatial logic of interface design. A panel understates it. Ambient presence everywhere means it is always intervening, which users in creative and professional contexts genuinely dislike. The best resolution I have found is temporal rather than spatial: the agent is a sequence of proposals, appearing where it is acting, disappearing after. It has a place in time rather than a place on screen.
I also think the industry has this exactly inverted at the moment. Enormous effort goes into making AI output look confident and polished, and very little into making it checkable. That is backwards, because trust is asymmetric. It accrues slowly through small verified successes and it collapses completely at the first confident error a user catches. A product that shows its work will lose a few demos and keep its users.
The last thing, and it is the one I would push hardest on with any founder: the automation boundary belongs at irreversibility. Not at where the model gets unreliable, not at where the engineering gets hard. Ask what a mistake costs, and stop the automation just before the point where the answer is "a lot".
Conclusion
Adding a model to a product breaks determinism, discoverability and reversibility. Good design in this generation is mostly the work of restoring them: a visible seam between the specifiable and the generative, entry points that teach, total undo, proposals rather than applications, and provenance at the level of individual claims.
None of that is about making AI feel magical. It is about making a probabilistic system usable by someone who has to rely on it, which is a harder and less photogenic problem than the one most products are currently solving.
Sources
- L. Bainbridge, "Ironies of Automation", Automatica 19(6), 1983.
- R. Parasuraman and V. Riley, "Humans and Automation: Use, Misuse, Disuse, Abuse", Human Factors 39(2), 1997.
- S. Amershi et al., "Guidelines for Human-AI Interaction", CHI 2019. https://dl.acm.org/doi/10.1145/3290605.3300233
- Don Norman, The Design of Everyday Things, revised edition, Basic Books, 2013: signifiers, affordances, and the gulf of execution.
- S. K. Card, G. G. Robertson and J. D. Mackinlay, "The information visualizer, an information workspace", CHI 1991.
- Jakob Nielsen, "Response Times: The 3 Important Limits", Nielsen Norman Group, 1993. https://www.nngroup.com/articles/response-times-3-important-limits/
- M. Turpin, J. Michael, E. Perez and S. Bowman, "Language Models Don't Always Say What They Think", NeurIPS 2023. https://arxiv.org/abs/2305.04388
- Google PAIR, People + AI Guidebook. https://pair.withgoogle.com/guidebook/
Related reading in this archive
- What AI-native product management actually means
- Agents, autonomy and the human in the loop
- Cognitive load is the real SaaS design problem
- Designing trust in AI interfaces
- Veena Studio: where the agent placement problem came up in practice
- Design systems under non-deterministic output: the primitives that would make these decisions once instead of once per feature