How do you design the prompt input for an AI product?
Design the prompt input by answering three questions for the user before they type: what can this do, what should I write, and what will it look at. An empty box with Ask anything answers none of them. Suggested prompts, templates, context chips and structured controls each answer one or more.
This is often called the blank-box problem. Open text input is powerful for people who already know what to ask, and paralyzing for everyone else. Most of your new users are everyone else. This guide covers the patterns that fix it, and it's part of our hub on AI product UX. If you're unsure whether your product needs a prompt box at all, our guide to inline AI patterns covers ways to add AI without one.
What makes an AI input box design work?
An AI input box design works when it makes the next action obvious and the cost of a bad prompt low. The box itself is only one part. The placeholder, the suggestions around it, the context it shows and the controls inside it all shape what users type.
Element | What it does | Good example | Weak example |
|---|---|---|---|
Placeholder | Hints at scope and phrasing | Summarize a call, draft a reply, or ask about an account | Ask me anything |
Suggested prompts | Shows real tasks to start from | Draft a follow-up to today's demo call | Tell me a fun fact |
Context chips | Shows what the AI will read | Acme Inc. account, Q3 call notes | Hidden context the user can't see |
Mode or tool picker | Sets what kind of answer to expect | Search docs / Write / Analyze data | A dozen unlabeled icons |
Attachments | Adds files or records to the request | Drag a file or @mention a record | Upload only through a separate page |
Send and stop | Starts and cancels the request | Clear send, stop while generating | Enter only, no stop |
Size the box for the prompts you expect. A one-line box suggests short questions. A taller box that grows as users type invites detail, which usually gets better results for writing and analysis tools.
How should suggested prompts and prompt starters work?
Suggested prompts should be specific tasks your users actually do, written in their language and ready to run with one click. Prompt starters that show off the model's range, like poems or trivia, teach users that the product is a toy rather than a tool for their job.
- Source them from real usage. Look at what your best users ask, rewrite those prompts cleanly and use them as starters.
- Make them contextual. On an account page, suggest prompts about that account. On an empty project, suggest setup tasks.
- Keep three to five visible. More than that becomes a menu to read rather than a nudge.
- Let them run or edit. Clicking a starter can either send it straight away or drop it into the box for editing. For anything with blanks, drop it in.
- Rotate after use. Once a user has run a starter, replace it with the next most useful one.
When should you use prompt templates?
Use prompt templates when the same kind of request repeats with different details, such as a weekly report, a customer reply or a product description. Prompt templates UX turns a carefully written prompt into a form with a few blanks, so every user gets the result your best user would get.
Find the repeated job
Look for prompts users rewrite often with small changes. Those are templates waiting to happen.
Fix the instructions, expose the variables
Keep the tone, format and rules inside the template. Show only the parts that change: customer name, tone, length, the record to use.
Use real input types
A dropdown for tone, a record picker for the account, a short text field for the goal. Don't ask users to type what a menu could offer.
Preview the full prompt on request
Power users want to see and tweak what's sent. Hide it by default and offer View full prompt.
Let teams save and share
A template library per workspace lets one person's good prompt become everyone's starting point.
For example, suppose a sales tool adds a follow-up template
For example, suppose a sales tool adds a Follow-up email template. The user sees four fields: Account (record picker, prefilled on the account page), Call (picker showing recent calls), Tone (Friendly, Direct, Formal) and Goal (short text, such as book a technical review). Behind the template sits a longer prompt with rules about length, sign-off and not inventing pricing.
The user fills two fields and clicks Draft. They never see or write the long prompt, and the output is consistent across the team. This is a hypothetical walkthrough to show the structure.
How do you show what context the AI can see?
Show the context the AI can see as removable chips inside or just above the input. If the AI will read the current document, a selected record or an attached file, users should see that before they hit send, and be able to remove it.
Context chips solve two problems at once. They explain why an answer mentions things the user didn't type, and they let users scope the request, for example removing an old file that would confuse the answer. Support @mentions for records, files and people, so users can add context without leaving the box. Keep the chips short and recognizable: a file name, a record name, a date range. If the AI also draws on stored memory, show that too, or link to where it can be managed. Our guide to AI chat interface design covers how context fits into the wider chat layout.
When should structured inputs replace free text?
Structured inputs should replace free text whenever the options are known ahead of time. If there are four valid tones, three output formats or a fixed list of records, a menu is faster and more accurate than asking users to describe their choice in words.
Pros
- Fewer failed or ambiguous requests
- Faster for repeated tasks
- Easier to test and keep consistent
- Teaches users what the AI can do
Cons
- Less flexible for unusual requests
- More design and build work up front
- Can feel rigid if there's no free-text escape hatch
The best AI inputs mix both: structured controls for what's predictable, plus a free-text field for the rest. A mode picker, such as Search, Write or Analyze, is a light version of this that sets expectations without adding a form. If your product leans fully on structured input, it may really be a copilot or a feature rather than a chat, which our guide to copilot vs agent vs chat helps you decide.
How do you build a prompt input that lasts?
Build the prompt input as one shared component with clear states: empty, typing, with attachments, sending, generating with a stop control, and disabled with a reason. That way every AI feature in the product uses the same box and users learn it once.
Teams building on component libraries can start from an existing text area and extend it, which our comparison of shadcn/ui and a custom design system discusses. The AI-specific parts, such as chips, starters and the stop control, are usually custom. Our guide to design systems for AI products covers how they fit together. We design the words in the box along with the box itself, because the placeholder and starters do as much work as the layout.
