Adding AI without turning the product into a chat box

AI product design works better when the assist sits on the field the person was already editing. A paragraph, a subject line, a price, a status. The model proposes a change in that place. The person keeps the cursor where it was.

A blank chat is a second product. It asks someone to learn a new room, a new tone, and a new way of asking, before they can finish a task they already understood. Most products do not need that room.

Start from the field already on screen

Watch the task without the model. Where does the person hesitate? A support lead stares at an empty reply box. A shop manager stares at a thin product description. A founder stares at a homepage headline that still sounds like an internal codename. The assist belongs in that box, as a suggestion they can accept or rewrite.

The suggestion should be about the field's job. A reply box gets a reply. A price field gets a number with the reason beside it, not a essay about pricing strategy. A status field gets the next status the workflow allows, not a paragraph of encouragement.

Bring in only the context that field needs. The reply box may need the last customer message and the order number. It does not need the entire account history in the prompt if that history can leak into the draft. Smaller context is a design choice. It keeps the suggestion relevant and keeps private details out of a sentence the person might send in a hurry.

If you cannot name the field, you are not ready to add the feature. "Add AI" is not a screen. "Draft the first reply in this thread" is a screen.

What the suggestion should contain

A useful suggestion is short enough to judge in place. Nielsen Norman Group wrote in 2011, in how long people stay on web pages, that users often leave within 10–20 seconds and have time to read only about a quarter of the text. A chat transcript fails that test on purpose: it is a growing pile of words. A three-line draft in the field can be read. A twenty-turn conversation about the draft usually will not.

Show the suggestion as a proposal, distinct from text the person wrote. A light difference in the surface is enough: a border, a label that says "Draft," a clear accept. Do not mix the model's words into the document silently. Silent insertion is how a person ships a sentence they never chose.

Say what the draft used. "Using the customer's last message" is enough when it is true. If the draft also used a policy page, name the page. The person should not have to guess which facts are theirs and which arrived from somewhere else.

One suggestion is often better than five. Five options look generous and create a new chore: picking among near-duplicates. Offer one solid draft and an easy way to ask for a different angle, with the angle named. "Shorter" and "more formal" are angles. "Try again" is a slot machine.

Why a blank chat asks them to learn a new product

A chat box has its own rules. What do I type? Will this send to the customer? Is this private? Which earlier answer is the current one? Those are onboarding questions. You have added a product inside the product, and you have added it at the moment the person was trying to finish something else.

Chat is the right surface when the task is a conversation: search across messy notes, or a back-and-forth where the person does not yet know the shape of the answer. It is the wrong surface when the shape is already on screen. They came to write a refund reply. Hand them a refund reply.

There is a practical cost too. Chat becomes the place every half-built idea lands, and the actual record, the ticket, the product page, the invoice, stays empty. The work then lives in a scroll nobody else can audit. Fields keep the work in the system you already trust.

If you already shipped a chat box and people are pasting its answers back into the form, that paste is the design telling you where the feature should have been. Move the assist to the field. Keep the chat only for the questions that have no field yet.

Accept, edit, and dismiss

Three actions are enough. Accept writes the draft into the field and leaves it editable. Edit lets them change the draft before it lands, or land it and keep typing. Dismiss removes it without guilt and without a follow-up question about why.

The W3C's WCAG 2 overview says the guidelines apply to AI web interfaces. The four principles still hold: perceivable, operable, understandable, and robust. The draft has to be perceivable as a draft. Accept, edit, and dismiss have to be operable controls with names, including for someone who is not using a pointer. The label has to be understandable. "Magic" is not a name. "Insert draft" is a name.

Keyboard users should be able to accept without hunting. A suggestion that only appears on hover, or only after a gesture nobody was taught, will be used by the person who built it and missed by everyone else.

Do not move the cursor in a surprising way. If they were editing the second sentence, a refresh that jumps them to the top feels like the software seized the document. Insert at the caret, or insert in a preview that does not steal the place they were working.

After accept, the field is theirs again. Further suggestions wait to be asked for. An eager model that keeps rewriting while they type is not an assistant. It is a struggle for the keyboard.

When a conversation is actually the job

Some tasks are conversations. Exploring a research pile, asking questions of a long document, or triaging a vague request before you know which form it belongs in. A chat surface can earn its place there, with a transcript the team can file back into the record when the exploration becomes a decision.

Even then, end the chat in a field. The outcome should land as a note, a ticket, or a draft in the system of record. A conclusion that exists only in the chat will be lost, and the next person will ask the model again and get a different one.

Keep the conversational feature out of the path that has a deadline. Buying, sending, and deleting should still be ordinary controls. The chat can advise. The button that acts should be the button you already had, with the same confirmation you would have shipped without a model.

Hanabi's services include product interfaces for early software, and this is the shape of an AI feature that belongs in one: on the draft the person was already editing, with accept, edit, and dismiss in plain language.

Trust is the other half of that screen. Designing an AI feature people can trust is the next piece, because a suggestion in the field still has to show its source and its limit, or people will stop accepting it.