When a product adds AI, the default move is to add a chat box. It is the obvious choice, because chat is how most people first encountered AI, and it is the easy choice, because a text box is simple to build. For a large share of the problems products are actually trying to solve, it is also the wrong choice. Chat is the right interface when the user genuinely wants a conversation. For most AI features, the user does not want a conversation. They want an outcome, and a chat box makes them do work to get it.

The better question is not how to add chat to the product. It is what the AI is for, and what interface that purpose actually implies. Sometimes the answer is chat. Often the answer is an interface that does the work without asking the user to describe it first, or one that runs in the background and surfaces only when something needs a human. Designing that well is a product decision, and it is one many teams skip by reaching for the text box on reflex.

What a chat box asks of the user

A chat interface looks effortless and quietly pushes effort onto the user. To get value from it, the user has to know what to ask, phrase the request well enough for the system to act on it, and do this every time. The interface sits idle, waiting for input, contributing nothing until the user works out what to say to it.

For some tasks that is exactly right. When the user's need is genuinely open-ended, when they are exploring, asking follow-up questions, or working through something whose shape they do not yet know, a conversation is the natural form and a chat box serves it well. The problem is that most features inside most products are not like that. The user has a specific job to do, knows roughly what they want, and would be better served by an interface that simply does it than by a blank field asking them to describe it. A chat box in front of a well-defined task is a step backwards, a command line wearing friendly clothing, asking the user to generate the instruction that a good interface would not have needed.

From designing a conversation to designing a policy

The most useful shift in thinking is away from designing a conversation and towards designing a policy. A great many AI features are not really conversational at all. They are monitoring, automation, or judgment tasks that happen to be powered by a model, and the right interface for those is not a chat box. It is a system that knows what to watch for, what to do when it sees it, and when to involve a human.

Designing that means answering a different set of questions from the ones chat raises. What conditions should trigger the system to act. What is it permitted to do on its own. What requires a person to approve before it happens, and what should it surface for a human to judge rather than decide itself. These are policy questions, not conversation-design questions, and they describe an interface that works in the background and escalates by exception rather than one that waits in the foreground for instructions. The user is not asked to drive. They are asked to set the rules and to handle the cases the rules deliberately route to them.

This is squarely the work of Product Clarity, the phase that determines what to build before committing to building it. The decision about what interface an AI feature should have is not a styling decision made late. It follows directly from what the feature is for, and getting it wrong is expensive in a way that is hard to reverse, because an interface shapes how users understand the whole feature. A monitoring task delivered as a chat box does not just feel slightly off. It teaches users that the feature is something they operate by asking, when its actual value was in not having to ask at all.

Where the judgment goes

None of this removes the human. It relocates them, and being deliberate about where they go is the heart of designing the feature well. A policy-driven AI feature does not eliminate human judgment. It directs that judgment to the cases that need it and keeps it away from the cases that do not.

This is the same frame the studio applies to AI everywhere. AI accelerates the work, and the expert turns the output into a decision. A well-designed AI feature decides, explicitly, which decisions the system can make on its own and which it must route to a person, rather than collapsing every interaction into a chat box that makes the user do the routing themselves. The interface is where that division becomes real. A chat box puts the human in the loop for everything, including the routine work they would rather not touch. A policy-driven interface puts the human in the loop for the cases where their judgment actually changes the outcome, which is both a better use of the human and a better product.

What this means for your next AI feature

Before you add a chat box to your product, it is worth asking what the feature is actually for. If the user genuinely wants to converse, to explore, to ask and follow up and ask again, chat is the right form and you should build it well. If the user wants a specific outcome, a chat box is making them describe work that the product could simply do, and you should design the interface that does it.

And if the feature is really monitoring, automation, or judgment, the question is not what the conversation should look like. It is what the policy should be: what to watch, what to do, and when to involve a person. The chat box is the default because it is easy, not because it is right. The features that feel effortless to use are usually the ones where someone did the harder work of deciding that a conversation was not what the user wanted in the first place.