Prompt suggestions: how to help people start asking

What problem do they solve?

An empty text field says nothing. Someone arriving for the first time does not know whether the assistant can draft an email, analyze a spreadsheet or answer a contract question, and does not know how to phrase a first question either.

Suggestions answer that before the person has to ask. They work as a minimal map of the product, so their value depends on describing real capabilities. Nielsen Norman Group makes the same point for any empty screen: it should say what could be displayed and how to fill it, with direct pathways to key tasks.

Suggestions are one of the ways to make an AI discoverable: people learn what they can ask without reading a manual. The screen where they appear, the chat empty state, defines how much room they get.

Guideline G1 of HAX, Microsoft’s library of human-AI interaction patterns, applies directly: “Make clear what the system can do”. A suggestion that promises something the assistant does badly breaks that promise on the first use.

How do you write good suggestions?

The “Prompt Starters” guide from AI UX Playground recommends three to four short labels that are easy to scan, such as “Plan a trip”. It also asks that tapping one drop the text into the input field so the person can edit it before sending, and that the prompt be short, not a long brief. Details come later, in the conversation. A suggestion like “Ask me anything” teaches nothing.

Practical rules:

1. Use concrete tasks. “Summarize this contract in five points” teaches more than “Help with documents”.
2. Show the real scope. If the assistant cannot access your calendar, do not write “Schedule my meeting”.
3. Let people edit. The suggestion should fill the field, not send itself. That way people learn how to ask. The same guide allows one exception: a suggestion that already includes sample context can run end to end with one tap and show a clear result.
4. Keep the field visible. Someone who ignores every suggestion must still be able to type freely, and typing should replace the suggestions without friction.
5. Remove them afterward. Once the first message is written, the suggestions go away. If they come back with every reply, they become noise.

A quick way to review the wording is to compare weak and strong versions:

Should they be the same for everyone?

No. A general assistant can show different suggestions depending on the person’s role, recent tasks or the context of the screen they are on. For example, a designer who has just uploaded a prototype might see “Review the accessibility of this screen” instead of a generic phrase.

If the assistant can act, not just answer, the suggestion must also make clear what it will do. That boundary between answering and acting is covered in chat versus structured interfaces.

But personalization needs care. Using history to suggest is useful when the person knows it is happening; surprising them with a reference to something private is not. When a suggestion uses personal data, tell them where it comes from.

When should you NOT show them?

• With returning users. Someone who already knows what to ask does not need suggestions. For them, conversation history or recent actions are more useful.
• In highly specialized tools. If the product does one thing, an input field with an example in the help text is enough.
• If the placeholder already does the job. Text inside the field, such as “Write a summary of your week”, does the same work without taking up space.

How do you know whether they work?

You will not know by reading them. Three simple tests:

1. Measure the tap. Count how many people tap each suggestion in their first session. One that nobody taps is noise, however good it sounds.
2. Measure what happens next. If the person taps a suggestion and leaves before the second question, the suggestion probably led them to an answer that did not help.
3. Run a first-time test. Ask five people who have never used the product to say out loud what they think the assistant can do before they type anything. If most get the same thing wrong, the problem may be the purpose text, not the suggestions.

Suggestions are also content, and they age. Review them every time an assistant capability changes, because one that no longer works is worse than none: it promises something the product no longer does. Give them a review date, as you would for any interface text, and remove any suggestion nobody has tapped for a month.

Example

Illustrative example: a research assistant for designers first shows four generic suggestions: “Write an email”, “Summarize a text”, “Give me ideas” and “Ask me anything”. The team suspects almost nobody taps them, because they say nothing about the product. They replace them with three research tasks with context: “Group these interview notes by theme”, “Compare these two sign-up flows” and “Draft questions for a 30-minute usability test”.

To find out whether the change helps, they measure two things: how many people now tap a suggestion in their first session, and whether the first message they type afterward looks more like a real task than a “Hello”. If both improve, the suggestions are working as a usage manual.

Common mistakes

• Showing suggestions the assistant cannot fulfill.
• Showing more than four, or phrases so long nobody reads them.
• Sending the suggestion automatically when tapped, without letting people edit it.
• Keeping them in every conversation, even when the person is already typing.
• Personalizing with private data without explaining where it comes from.

Sources

• HAX Design Library: guidelines and patterns (Microsoft)
• Prompt Starters (AI UX Playground)
• Designing Empty States in Complex Applications: 3 Guidelines (Nielsen Norman Group)