For about eighteen months, every product we have looked at has tried to bolt a chatbot to its homepage. A little floating circle in the corner. Sometimes a full-screen welcome modal. Sometimes a slash command. The feature itself is often serviceable; the framing rarely is. The chatbot is treated as a salesman who shouts about himself the moment you walk into the shop.
When we started building JuuLinkAI — our first in-house product, a link-in-bio platform for small merchants — we knew we wanted AI in it somewhere. The technology genuinely could help a non-native English speaker write a clean, professional customer review. But we did not want the AI to perform AI. We did not want a chat window, or sparkly badges, or copy that started with "Hi there, I'm Juu, your AI assistant!"
We started writing internal notes under a heading we eventually used as the design principle: soft-spoken AI.
What it means
A soft-spoken AI feature does its job and gets out of the way. It does not introduce itself. It does not ask for your patience. It does not congratulate you on completing a basic action. It treats the user as a competent adult who is here to get something done.
Concretely, the version we have arrived at is built on four rules:
- No persona unless one is earned. We do not give the model a name, a face, or a personality. Personas anthropomorphise the interaction in ways that mislead users about what is happening (and what can be trusted).
- One job per surface. A model that drafts review copy should only draft review copy. The same model should not be asked to also chat, also summarise, also recommend. Mixed-purpose AI surfaces invite users to ask things the system was not built to answer.
- Show, then offer. Instead of a blank input that says "ask me anything," we generate a draft up front, then let the user accept, edit, or regenerate. We start the conversation with a concrete artefact rather than a blank cursor.
- Make the cost visible. AI is not free; latency and token cost are real. We show the user a small inline indicator when a model is thinking, and we never run more than one call without their action.
The temptation of the chatbot
It is worth saying out loud why chatbots have spread so fast: they are cheap to ship. A chat input is the design escape hatch — when you do not know what the user wants, you give them a text box and let them figure it out. It is the equivalent of putting up a search bar on a product where you have not yet decided what users should be doing.
We think this is almost always a mistake. The whole point of a product is that someone has done the thinking already — has decided what the primary actions are, what order they happen in, what defaults are sensible. A chat box undoes that work. It pushes the cognitive load back onto the user, who now has to phrase their problem in words and hope the model interprets them charitably.
The chat window is the design equivalent of writing "TBD" in the product spec.
There are real use cases for conversational interfaces — debugging, long-form writing, complex search — but most products do not have those use cases. Most products have tasks, and tasks are better served by buttons.
Defaults are the message
A soft-spoken AI lives in its defaults. The temperature setting, the system prompt, the post-processing pass that strips emoji and excessive adjectives — these are the design decisions. The user does not see them, but they shape every sentence the model produces.
For JuuLinkAI's review feature, we run every model output through a small style filter before showing it to the user. The filter strips exclamation marks, removes the word amazing, deletes introductions like here is a review:, and capitalises the first letter. Nothing fancy. But it means the user sees a clean, publishable draft instead of model output with the seams showing.
These small post-processing passes are, we think, where the design of AI features actually happens. Anyone can prompt a model. The work is in the post-processing — in the editorial pass between the model and the user.
Refusing the persona
We mentioned at the top that we do not give our models a name. The reason is more than aesthetic. Personas encourage users to trust the system in ways the system does not earn. A model called Sarahwith a friendly avatar is one that users feel guilty correcting. A plain "Draft a review" button followed by editable text produces no such guilt. The user feels in charge — because they are.
Trust, in software, is best earned by giving the user the steering wheel and the brake. Personas are decorative. The brake is real.
What this looks like in practice
The JuuLinkAI dashboard has a button labelled Generate. The button produces three short review drafts written from the perspective of the merchant's described business. The user picks one, edits it if they wish, and saves. There is no chat. There is no assistant. There is no "hi there." The whole AI surface is one button, one list of drafts, and one save action.
We could have built something flashier. We could have given the feature a personality, a name, a little animated avatar. We didn't, because flash is not a feature — calm is.
A note for other teams
If you are building AI features and the design feels uncertain, here is the test we apply: would a thoughtful human assistant do this the same way? A thoughtful human assistant does not introduce themselves every time they hand you something. They do not ask permission to do their job. They do not narrate. They hand you the thing, quietly, and step back.
That is what we want our software to do. Soft-spoken AI is, in the end, less about AI and more about respect.