Designing the First Message in a Chat Interface

On this page11 sections

• Why the first message matters more than the model
• What the first message should say
• 1. Set the scope
• 2. Set the limits
• 3. Hand over a first move
• Starter prompts: teaching people how to ask
• How many to show
• When to show them
• Static or rotating
• Designing the first response
• Mistakes we see most often

The first message in a chat interface is everything a user sees before they have typed anything: the assistant's opening line, the starter prompts beneath it, and the empty input waiting for them. It is the highest-attention moment in the whole conversation, and in most AI products it is either blank or a generic "Hi! How can I help you today?"

Both waste it. A user who does not know what the assistant is for asks something vague, gets something generic back, and decides the feature is not very useful, usually within the first minute. This guide covers how to design that opening so the first exchange is a good one: what the first message should say, how starter prompts teach people to ask, and how to design the assistant's first response.

Why the first message matters more than the model

An empty chat box asks the user to do the hardest part of the job: work out what this assistant can do and phrase a good request, with no guidance. Experienced AI users manage. Everyone else types something broad ("help me with my account"), gets a broad answer, and concludes the feature is a toy.

The fix is not a better model. It is an opening that does the work the empty box leaves to the user. Trust in the assistant starts forming before anyone types, and trust is scarce: only 46% of people globally say they are willing to trust AI systems (KPMG and the University of Melbourne, 2025). The opening is where you earn the first bit of it.

What the first message should say

A good first message does three jobs, in two or three sentences.

1. Set the scope

Say what the assistant is for, in the language your product already uses. "I can answer questions about your invoices, payments and billing history" is useful. "I'm here to help!" says nothing, and it invites questions the assistant cannot answer.

2. Set the limits

Say what it cannot do, or where a person takes over. Users forgive an assistant that declared its limits up front. They do not forgive one that confidently attempted something it could not do. A single clause is enough: "I can't change your plan, but I can hand you to the team."

3. Hand over a first move

End with a concrete suggestion or question rather than an open floor. "Want me to start with last month's failed payments?" gets the user to a useful answer in one click. A blinking cursor gets them to a vague question.

Where you know something about the user, use it. An opening that references the page they are on, or the record they have open, feels like an assistant that knows where it is. That is most of what separates a useful in-product assistant from a generic chat widget.

Starter prompts: teaching people how to ask

Starter prompts, sometimes called conversation starters or suggested prompts, are pre-written questions the user can click to send. They are the most effective onboarding a chat interface has, because they teach by example.

Good starters do three things:

• Show the range of what the assistant handles, one prompt per kind of task.
• Sound like a real user, not a feature list. "What's the notice period in this contract?" beats "Analyse contracts."
• Model the right level of detail. Specific starters teach people that specific questions get better answers.

How many to show

Three to five. Fewer and users do not see the range; more and they stop reading them. On a narrow website widget, three is usually right.

When to show them

In the empty state, before the first message is sent. Once a conversation is under way the user is in a specific context, and generic starters become noise. The better pattern mid-conversation is follow-up suggestions based on the last answer.

Static or rotating

If the assistant does many different things, rotating starters across sessions shows more of its range. If it has a narrow job, keep them static: the same three good questions every time is a feature, not a limitation.

Designing the first response

The first message is what the assistant says unprompted. The first response is what it says after the user's first question, and it sets the pattern for everything after it.

• Answer first, explain second. Put the direct answer in the opening line, then the detail. Users skim the first sentence to decide whether the rest is worth reading.
• Show where the answer came from. If the assistant is grounded in the user's data or your documentation, show the source with the first answer. It is the moment people decide whether to believe it.
• Offer the next step. One or two follow-up suggestions keep the conversation moving, the same way the opening did.
• Be honest when unsure. If the first answer is uncertain, say so and suggest how to check. A confident wrong first answer ends the relationship; an honest "I'm not sure, here's where to look" does not.

Mistakes we see most often

1. The empty opening. No first message, just an input. It pushes all the work onto the user.
2. The generic greeting. "Hi! How can I help?" in every product, which tells users nothing about this one.
3. The wall of text. A welcome message listing every capability, which nobody reads.
4. Streaming the greeting. Animating a static message token by token makes the product feel slow before it has done anything.
5. Starters nobody would type. Feature names dressed up as questions, rather than the questions real users actually ask.

The first message is part of a bigger set of chat decisions, from message layout to streaming and error states; we cover those in our AI chatbot UI design guide, and the website widget specifically in chatbot window UI design. If you are designing an assistant into your product, this is the kind of work our AI chatbot UI design and AI copilot UI design engagements cover.