When a team discusses an AI feature, it is tempting to jump straight to a familiar pattern: a chat window, an input field and a button that says "Ask anything."

That might be the right answer. But it should be a design decision, not an automatic starting point.

I would first ask what someone is trying to accomplish. Are they exploring an unfamiliar topic? Comparing records? Reviewing a document? Updating a known field? Approving an action?

Those are different jobs, and I would not assume they all need the same interface.

Conversation is useful when the request is still taking shape

I would consider chat when the user benefits from asking follow-up questions, refining an open-ended request or exploring material without knowing exactly what they need yet.

For example: "Help me understand the differences between these proposals." That request may lead naturally to follow-up questions about pricing, delivery, exclusions and risk. A conversational interface gives the user room to explore.

Now take a different task: "Change the delivery date for these three orders."

For that, I would consider a way to select the orders, a date control and a clear confirmation. Making someone describe a precise, repeatable action in natural language can add work rather than remove it.

Put AI where the work already happens

Instead of creating a separate AI destination, consider whether help belongs inside the existing workflow. That could mean:

  • A suggested reply beside a customer message.
  • A summary above a long document.
  • A proposed category beside an uncategorized record.
  • A comparison panel within a purchasing workflow.
  • A draft description inside the field someone needs to complete.

The goal is not to make the AI invisible at all costs. It is to make its role understandable.

What did it produce? What information did it use? What can the user change? What happens if they accept it?

Make review part of the interface

A polished answer can look more reliable than it is.

Nielsen Norman Group cautions that AI-generated explanations and citations can themselves be inaccurate or misleading. A convincing explanation is not proof that an answer is correct.

For an AI-assisted document review, I would rather show the relevant source passage beside a proposed finding than present a confident paragraph with no practical way to check it.

For a suggested action, I would show exactly what will change.

For missing information, I would make the gap visible rather than let the interface fill it with something plausible.

Design for different levels of consequence

Drafting a headline and approving a financial transaction should not have the same interaction pattern.

My preference is to increase review and confirmation as the potential consequence grows. That might mean editable suggestions for low-risk content, explicit approval for external communications and stronger controls for actions involving sensitive data or business records. I wrote about the agent side of this in An AI agent's login is not permission to do everything.

Chat can be an excellent interface. It is not a product strategy by itself.

The design question is not "Where can we add a chatbot?" It is "What combination of conversation, controls, context and review helps someone complete this task responsibly?"

If you are planning an AI feature and the chat window arrived before the task did, email me.