Anti-Pattern: Chat as the Default Interface

A chat box is the most defensible thing you can build in a planning meeting and one of the least defensible things you can put in front of a user who has a job to do. Both halves of that are worth taking seriously, because the first half is why it keeps happening.

Why the chat box wins the meeting

Chat is not chosen out of laziness. It wins on four real arguments, and a page that skips them will not change anybody’s mind.

• It has no scope. Every other interface requires you to decide what the feature does. A text box requires you to decide nothing, which is enormously attractive when the capability is new and nobody knows which of twenty use cases matters.
• It ships in a day. The interface is a list and an input. The entire cost is in the prompt, so the demo arrives before the argument about product direction is finished.
• It cannot be wrong in a specifiable way. If a summarise button produces a bad summary, the button is broken. If a chat produces a bad answer, the user asked badly. Ambiguity of contract is a real, if unattractive, engineering advantage.
• It matches the artefact. The model is a chat model. Building the interface that mirrors the API is the path of least translation.

The failure mechanism follows directly from the first argument. The reason chat has no scope is that it moves the entire specification problem onto the user, at the moment of use, every single time.

What it costs the person using it

Three costs, in rough order of how much damage they do.

The blank page

An empty input with a blinking cursor asks the user to know what the system can do, phrase it, and take responsibility for the phrasing. That is a design task delegated to someone who opened your product to get something else done. Every affordance a normal interface provides for free — what is possible, what the options are, what happened last time — has to be discovered by guessing.

No error surface

In a conventional interface, an unsupported action is greyed out or rejected. In chat, an unsupported action gets a plausible, fluent answer, because the model will answer whatever it is asked. The user cannot distinguish “this product cannot do that” from “this product did that”. This is the specific mechanism by which chat converts a missing feature into a hallucination, and it is a design decision rather than a model defect.

Repetition with no memory of intent

Chat has no state that the user can rely on. Anything they established three turns ago is present only as tokens in a window that will be truncated, and anything they want next week must be typed again. A form remembers because the fields exist; a conversation remembers only as long as somebody pays to re-send it, which is also why a long session costs more per turn than a short one.

Four shapes that usually beat it

The alternatives are not exotic. They are the interface patterns that existed before, with the model placed inside them rather than in front of them.

The test for which shape a feature wants is one question: can the system know what the user wants without being told? If the object under the cursor determines the task, it is an inline action. If the task is fixed and only the content varies, it is fill-and-review. If there is genuine ambiguity between a small number of interpretations, it is suggestions. If nobody needs to ask, it is enrichment. Chat is what remains when the answer is no to all four, and that is a smaller set of features than the current default suggests.

The signal that chat was the wrong choice

You do not need to argue about this in the abstract, because chat leaves a distinctive fingerprint in its own logs. Take a week of prompts and cluster them by intent — a cheap classifier is fine for this, and single-token classification costs almost nothing at this volume. Then look at the shape of the distribution.

• A short head — if a handful of intents cover most of the traffic, those intents are buttons that have not been built yet. The users have told you the specification you refused to decide, and every one of those requests is currently paying full model price to re-derive a task you could have fixed.
• A long, flat tail with low repeat use — people tried it once and did not come back. That is not a chat problem to be fixed with a better prompt; it is a feature nobody needed.
• Rephrasing within a session — the same user asking the same thing three ways is the blank-page cost, measured. Count the rate of second attempts within a session; it is the most direct metric of interface failure that a chat box produces.

The first of those is the useful one. A chat box is a legitimate research instrument for discovering what a feature should be, provided somebody has agreed in advance to read the results and replace it. The anti-pattern is not building it. The anti-pattern is building it, learning what the top five intents are, and leaving it as the interface anyway.

When chat is genuinely right

Three cases survive the argument. The first is genuinely open-ended exploration where the space of intents is unbounded and the user is an expert — a coding assistant, a research tool, an analyst querying data they know well. The second is when conversation is the product rather than the interface to a product: tutoring, interviewing, drafting with a collaborator. The third is a deliberate discovery instrument with an agreed end date.

What all three have in common is that the user brings the specification and knows they are doing so. That is the honest test. Chat is a good interface for people who already know exactly what they want and would find any menu you built too small — and it is a poor interface for everyone else, which in most products is nearly everyone.