Conversational UI: When Not to Use Chat

Almost every AI product starts in the same place: a text box with a send button. Conversational UI is quick to build, it demos well, and it lets a team postpone every hard question about what the product should actually look like.

Then it ships, and usage is thin. People try it twice and go back to the filters.

Conversational UI is a real pattern with a real, narrow set of jobs it does better than anything else. The mistake is treating it as the default surface rather than one option among several. Here is the decision rule for telling those cases apart, and the evidence on both sides of it.

What conversational UI actually is

Conversational UI is any interface where the user's primary control is natural language taking turns: you type or say what you want, the system responds, you refine. Chat windows, voice agents, and in-product copilots all qualify. The defining feature is not the model behind it. It is that the user's lever is a sentence rather than a visible set of controls.

Three terms get used interchangeably and should not be:

• Conversational AI is the capability underneath: understanding intent, tracking dialogue state, generating a response.
• Conversational UI is the surface: the box, the microphone, the turn-taking.
• Conversational UX is the quality of the experience across that surface: what happens when the system does not understand, how a user recovers, how much they have to remember, and whether they can tell what the thing can do at all.

The pattern also predates large language models by a decade, which is the part worth remembering. Facebook launched M inside Messenger in August 2015 as a human-assisted assistant, and shut it down on January 19, 2018 after it stayed in a beta of roughly two thousand users in California and never scaled. Facebook's 2016 Messenger bot platform arrived with the same theory, that conversation would replace apps, and the bot wave that followed largely receded.

The lesson from that cycle was not that chat failed. It was that chat had been sold as the interface for everything, and it is not. The models are vastly better now. The interface question has not changed at all.

The travel booking test

The sharpest version of that question I have heard comes from a 36-second clip on 20VC, where Aravind Srinivas, co-founder and CEO of Perplexity, turns it on the host. He asks Harry Stebbings how he books hotels and flights today: ChatGPT, or Google? The answer is Google. Asked why, Stebbings says he likes discovery and wants to see the options.

Srinivas' reading of that answer is the useful part:

"the interface is less about conversations and more about exploration"

The general rule he draws from it is a conditional: when "the decision-making is more subjective and vibes-based, you don't need an objective answer engine".

That is the whole test, and it is more precise than it first sounds. It is not about task complexity, and it is not about whether your users are technical. It is about whether a correct answer exists.

When there is one right answer, conversation is the most efficient way to ask for it. Typing a sentence beats learning your navigation. When there is no right answer, when the user is choosing rather than asking, a chat box removes the one thing they came for: the ability to see what the alternatives are and form a preference by looking at them.

Notice which side of that line most consumer commerce sits on. Hotels, restaurants, furniture, jobs, schools, houses. All choices, none of them with a correct answer. Now notice how much B2B software is the same. Picking a vendor, reviewing candidates, choosing which accounts to work this week. A ranked list from a model is an answer to a question the user was not asking.

Where chat is genuinely the right call

The pattern earns its place in four situations, and it is worth naming them precisely so you can check whether you are in one.

One objective answer exists. Balance, status, policy, definition, diagnosis with a known correct output. The user has a question, not a decision.

The input space is larger than any menu. If the set of things a user might want cannot be enumerated on a screen, natural language is the only affordable way in. This is why coding assistants work: no menu can contain the set of possible code changes.

The user's hands or eyes are busy. Voice on a phone call, in a car, on a factory floor. Here the conversation is not competing with a better visual interface, it is competing with nothing.

The alternative is a form nobody finishes. Support intake, scheduling, onboarding questionnaires. A conversation that asks one question at a time genuinely outperforms a twenty-field form, which is why AI customer service agents are the one place chat has clearly stuck.

Even inside these cases, the research says users want less conversation rather than more. A 2026 Nielsen Norman Group study of site AI chatbots found that participants approached them much like search bars: they typed as little as possible, expected fast responses, and preferred answers they could scan. The finding the researchers put bluntly is the one to design against: "A longer answer was not a better answer."

That is a useful correction even when chat is the right call. Users who land with a question are not looking for a conversation. They are looking for an answer, and the conversation is the cost they pay to get it.

Where chat quietly loses

Four failure modes, in rough order of how often they go undiagnosed.

1. It hides the option set. This is the travel booking case, and it is the expensive one, because the product looks fine in a demo. The founder types one query, gets one good answer, and never notices that a real user wanted six options next to each other. Exploration is not a worse version of asking. It is a different job.

2. Nobody can tell what it does. A chat box has no affordances. A menu tells you what the product can do simply by existing; an empty text field tells you nothing. In a companion NN/g article on site AI chatbots, the same researchers found participants rarely used them, often did not notice them, and struggled to see what they offered beyond search, filters, or tools they already had. If your onboarding has to include example prompts, that is the interface telling you it cannot explain itself.

3. It is single player by construction. This one is structural and gets missed entirely. In a Y Combinator request for startups on multiplayer AI, the framing is exact: "working with AI is largely single player. You open a chat, type a prompt, and get an answer in a box that only you can see." When you want to bring a colleague in, "the best you can do is send a link to a read-only transcript that they can't touch." The pitch rests on a pattern worth taking seriously: "The best work tools of the last two decades won by going multiplayer." A chat thread is the opposite of that: private by default, hard to hand off, impossible to edit together.

4. The output is unstructured, so nothing downstream can use it. A sentence is a terrible database. When your product's main artifact is a transcript, you cannot sort it, filter it, diff it, or show it to the next user. The interface decides what your product can remember, which is a much bigger commitment than it looks like at pitch time.

The interface decision is a business model decision

Here is the part of the Perplexity clip that founders skip, and it is the one with money attached. Srinivas connects the interface directly to monetization:

"the chat interface doesn't capture that user intent, that user behavior right now, which is why it was never a great fit for advertising"

Read that again with your own product in mind. The interface you choose determines which user intent you can observe. Google's ad business works because the interface makes commercial intent legible: a query, a set of options, and a click that says which one won. That signal is what advertisers buy.

The scale of it is easy to underestimate. Booking Holdings, the owner of Booking.com, reported 8.2 billion dollars of marketing expenses in its 2025 annual report. The filing says performance marketing is the substantial majority of that line, and that it goes primarily to online search engines, primarily Google. The figure floated in the clip is around 16 billion dollars, which is roughly double the company's entire reported marketing line, so treat the shape of the point rather than the number: a handful of advertisers fund an enormous business, and they fund it because the interface shows them what people want to buy.

A chat interface collapses all of that into one turn with no visible alternatives. There is no comparison set, no click, no revealed preference. That may be exactly what you want, if you are selling a subscription and the absence of an option set is the product. It is a serious problem if your model depends on marketplace take rates, lead gen, or advertising, and it is the kind of problem that shows up two years in, not in the first user test.

The same logic runs the other way for pricing your own product. If your interface never observes which alternative a user preferred, you have no data to price against, which is why interface choice and AI pricing end up being the same conversation.

The hybrid that usually wins

The honest answer for most products is not chat or no chat. It is conversation as the entry point, and a structured, explorable surface as the answer.

Concretely: the user types a sentence, and what comes back is not a paragraph. It is a comparison table, a filtered map, a shortlist of five with the criteria exposed and adjustable. The conversation solves the intake problem, which is real, and the visual surface solves the exploration problem, which chat cannot. The user can then ask for something cheaper and closer to the water, and watch the surface change rather than read a new paragraph.

That is the practical case for generative UI: the model assembles the interface around the request rather than answering in prose. It is also the direction the infrastructure is heading. On a16z's The New Rules of Enterprise Software, one of the hosts sums up what is changing: "accessing the UI is optional", with people getting information delivered to them instead of navigating to it. Elsewhere in the same conversation the panel frames agent access to a system like Salesforce as a UI-or-API question, and answers it API. If the interface is becoming a rendering decision rather than a fixed thing you ship once, then defaulting every response to prose is leaving the choice on the table.

The rule of thumb: let the user speak in sentences, and let the system answer in objects.

Draw the security boundary before you ship the box

A conversational UI is an unbounded, untrusted input surface pointed at a model that can call your tools. That is a straightforward description of the risk, and it is worth writing down before the box goes live rather than after.

The specific hazard is that conversational UI removes the visible affordance that told users what the system could do, which also removes their ability to notice it doing something else. A user looking at a menu knows the product cannot wire money because there is no button for it. A user looking at a text field has no such assurance, and neither does the model.

Four controls that cost little at the start and a great deal to retrofit:

1. Constrain the action space, not the input space. You will never successfully filter what users type. You can absolutely enumerate what the model is allowed to do, and keep every tool call inside a set you built and reviewed.
2. Separate read from write. Anything with a side effect (a payment, an outbound email, a deletion, a permission change) requires explicit user confirmation showing exactly what will happen, not a model's summary of it.
3. Treat retrieved content as hostile. The moment your agent reads a web page, a PDF, or a support ticket, that text is instructions someone else wrote. This is the ordinary case, not the exotic one, and it is the same discipline that context engineering for AI agents is built around.
4. Log the whole turn. Store the input, the retrieved context, the tool calls, and the output. When something goes wrong, the final answer alone will not tell you what caused it.

Least privilege is not new advice. What is new is that the permission boundary now sits behind a text field that accepts anything, which makes it much easier to draw the boundary too generously and much harder to notice you did.

A decision rule you can run in an hour

Take one surface of your product, not the whole thing, and answer four questions in writing.

1. Does a correct answer exist for this task? If yes, chat is a strong candidate. If the user is choosing among options with no right answer, it is not.
2. Can the things the user might want fit on a screen? If yes, show them. A menu that fits is always more discoverable than a prompt that has to be guessed.
3. Does anyone else need to see or continue this work? If yes, a private thread is working against you, and the artifact needs to be a shared object rather than a transcript.
4. Does your business model need to observe which alternative the user preferred? If yes, you need a visible option set, because a single answer produces no comparison signal.

Most products will find that different surfaces land differently, and that is the useful outcome. Support intake is a conversation. The catalogue is not. The reporting view is a generated object, not a paragraph. Deciding this per surface is the difference between a product with an AI feature and an AI-native company, which is the argument running through the AI for startups pillar.

The default is the problem, not the pattern. Chat became the default because it was the fastest thing to build in 2023, and defaults chosen for build speed have a way of becoming architecture. It is worth spending an hour to check whether yours was ever a decision.

What to do this week

1. List every surface of your product where a user currently types into a box, and mark each one as ask (a correct answer exists) or choose (it does not). Anything marked choose is a candidate to redesign.
2. Watch three real users use your chat surface without prompting them. Count how many type a short, imperfect query and how many write a full sentence. Design for what you see, not for the demo query.
3. Take your single most-used chat response and rebuild it as a structured object: a table, a shortlist, a filtered view with the criteria exposed. Ship it behind a flag and compare completion rates.
4. Write down what your product can do in one screen. If you cannot, your users cannot discover it either, and no amount of prompt suggestions will fix that.
5. Enumerate every tool your agent can call and mark which have side effects. Put an explicit confirmation in front of those this week.
6. Check whether your revenue model needs to see which option a user preferred. If it does and your interface never shows options, you have found a strategy problem disguised as a design problem.

Working out which surfaces should be a conversation, which should be an object, and how to tell the difference before you build either is the kind of decision the AI Operating System for Startups is built around.

Sources

• CEO of @perplexity-ai on Why Google Dominates the Ad Business, 20VC with Harry Stebbings, the clip this article distills, for the travel booking test, the exploration argument, and the link between chat and advertising.
• Perplexity CEO: Micron Will Be More Valuable Than Meta and How Export Controls Helped Not Hurt China, 20VC, the full episode the clip above is cut from, where the same exchange appears with the speaker turns unambiguous.
• Multiplayer AI, Y Combinator, for the single-player structure of chat and the read-only transcript problem. The written version is YC's request for startups on multiplayer AI.
• The New Rules of Enterprise Software with Steven Sinofsky, a16z, for the argument that accessing the UI is becoming optional as agents reach data directly.
• Less Chat, More Answer: Site AI Chatbots Need to Get to the Point and What Is Your Site's AI Chatbot for? Users Can't Tell, Nielsen Norman Group, both by Maria Rosala, Georgia Kenderova and Tanner Kohler, for the usability findings on how people actually use site chatbots.
• Booking Holdings 2025 annual report, filed with the SEC, for the marketing expense figure and its composition.
• Background on Facebook M: The Verge and TechCrunch on the shutdown and the roughly two thousand California users, Wikipedia for the August 2015 launch, and Wired on the wider retreat from chatbots that followed.
• Background on the people named: Aravind Srinivas, co-founder and CEO of Perplexity, and Harry Stebbings, founder and host of 20VC.