I keep watching teams ship AI features inside a chat interface for tasks that already had perfectly good forms, then spend the next quarter trying to figure out why nobody used the AI feature. For any feature where the input shape or the output shape is known in advance, chat is the wrong choice, and the cost shows up as low usage three weeks after launch.

Why chat became the default

Chat became the default because it's the path of least resistance for any team wrapping a language model, and I get why. The model takes text in and gives text out. A chat window is the thinnest UI you can build on top of that primitive, and it doesn't fight the shape of the underlying API. Most chatbot UI design starts there: a window, a text input, a thread of message bubbles. Every starter template ships with one. Every demo your CEO saw uses chat. Of course chat is what shipped.

Chat genuinely helps when the user does not yet know what they want, or when refining unstructured work where the freedom to wander matters more than precision. Stanford researchers recently ran a head-to-head comparison of generative interfaces against conversational ones, and chat actually held its own in casual how-to queries and basic prompts. There are real tasks chat fits well.

Designers have been making this case for years. Amelia Wattenberger's 2023 essay is the canonical version, and the argument has hardened into consensus among practitioners. Chat is the right interface for some AI features. The problem is treating it as the default for all of them. What I want to add is the developer-side rule.

Three scenarios where chat is the wrong choice

Scenario A: A complex form filled by AI

The first time I saw this fail in production was on an insurance application. The team had built a chatbot that asked for each field by name, interpreted the user's reply, and confirmed turn by turn. The flow looked clean in the demo. Once it shipped, completion rates dropped against the old web form. Geoffrey Litt has been arguing for years that LLMs should generate the UI a task actually needs, not force the user to describe their task in prose. We had done the opposite: taken a form that already worked, replaced it with chat, and asked the model to extract from sentences what it could have prefilled into fields.

We swapped it out for a generative form. The AI prefilled fields from the user's prior submissions and uploaded documents, the user edited inline. No conversation. Completion rates recovered. The output shape was known the entire time. It was a form. The fields had names. The conversation existed only because someone decided "AI feature" had to mean "talks to you."

// Wrong shape: chat
Bot:  "Let's start your application. What's your full legal name?"
User: "Jane Smith"
Bot:  "Got it. And your date of birth?"
User: "March 14, 1985"
Bot:  "Thanks. Now your current address..."

// Right shape: generative form
Name:     Jane Smith            from account
DOB:      March 14, 1985        from account
Address:  221B Baker St         from last claim, edit?
[Continue]

Scenario B: Querying a database

Within a sprint of launch, the chat interface we had built sat untouched. The eleven analysts on the team had defaulted back to the dashboard they already knew, and the non-technical operators we had hoped would use chat to query the billing dataset never showed up at all. Chat forced the analysts to type natural-language sentences to do what their existing dashboard filters did in two clicks. The right interface was a natural-language search bar above the existing dashboard, with results appearing as charts directly below it, not paragraphs in a chat thread.

The same Stanford team I cited earlier put a hard number on this. In data analysis tasks specifically, 93.8% of users preferred a generative interface that produced charts and tables over a chat interface that produced text. Most chatbot UI design hides this problem in the demo because demos are linear and clean. Real analyst work jumps between tabs and lives inside charts.

// Wrong shape: chat
Analyst: "Show me revenue by region last quarter"
Bot:     "Q3 revenue by region: NA $2.3M, EMEA $1.8M, APAC $1.1M.
          Want me to break this down further?"
Analyst: "Yes, by product line"
Bot:     "Sure, here is the breakdown..."

// Right shape: NL search above the dashboard
[Search bar above existing dashboard]
"Revenue by region last quarter, by product"
  charts render below, filters update, columns persist

Scenario C: Kicking off a workflow

A platform team I consulted with built a chatbot that let users start a multi-step approval process. Type the trigger. Confirm the parameters. Watch the bot narrate progress. The whole interaction was the bot reading back what the user had just said and then asking for confirmation in different words. The right interface was an action panel: one button to start, prefilled fields the user could edit, and a status timeline that showed progress without anyone having to "send a message" to find out.

The input shape was known, the output shape was known, and the trigger was already a button. Wrapping all of that in a conversation added latency, ambiguity, and a UX surface where the user could send free text the bot then had to parse and reject.

// Wrong shape: chat
User: "Start the Q3 budget review for marketing"
Bot:  "Got it. Who's the approver?"
User: "Sarah Chen"
Bot:  "Amount?"
User: "$45,000"
Bot:  "Confirming Q3 budget review, $45,000, Sarah Chen. Submit?"

// Right shape: action panel
[Start budget review]
  Period:    Q3 2026          (auto)
  Amount:    $45,000           (last quarter)
  Approver:  Sarah Chen        (team config)
  [Submit]   [Edit fields]
[Status timeline: Submitted -> In review -> Approved]

The decision rule

Every AI feature spec I write starts with two questions: does the input have a known shape? Does the output? If either answer is yes, the chat window is friction the user did not ask for.

When the input has a shape, use a command palette, a structured form, or a generative form the AI prefills. When the output has a shape, use the component that fits the shape: charts for data, action panels for workflows, code editors for code, calendars for scheduling. Chat earns its place when neither the input nor the output has a known shape, which is a real category. It is just a smaller one than the field acts like. The test takes ten seconds: sketch the feature on paper, then ask whether you could draw the input fields and the output components without the model in the picture. If you could, build that interface and put the model behind it. Most AI features have at least one known shape. Most AI features should not be chatbots.

The obvious counter is Cursor, which uses chat and works. But Cursor is not pure chat. Its chat handles intent expression while the file tree, diff view, and Apply button handle consumption. Chat as a thin intent layer on top of a structured surface works. Pure chat for both is the failure mode the three scenarios above describe.

Chatbot UI design is the most expensive interface to build well, because the model has to handle every edge case the UI would otherwise constrain. It is also the cheapest to ship badly. If a structured input would have worked, ship the structured input and let the AI fill it.

What's the worst chatbot you've used recently for something that should have been a button? Drop it in the comments. I'm always looking for new examples.

I'm a designer at Fuselab Creative, working on dashboards and AI interfaces for healthcare and enterprise clients. More writing at fuselabcreative.com.