Prompt box design: patterns for AI products

What the prompt box has to do

In many AI products, the prompt box is the front door. It is the first thing a new user touches and the thing a regular user touches a hundred times. If it is unclear, the rest of the product does not get a chance.

A good prompt box does four jobs:

1. It tells people what they can ask. A blank box with a cursor says nothing.
2. It makes asking easy. Typing, pasting, attaching and sending all work without effort.
3. It shows what the model will use. The context, the files, the sources.
4. It gives the user control over the result. Without making them fill in a form each time.

The temptation is to add controls for all of these at once. A box with six icons, two dropdowns and a toggle looks powerful and feels like a cockpit. Most users want to type a sentence and press Enter. Everything else should be there when needed and quiet when not.

Example prompts that teach

Example prompts are the cheapest, most useful part of an AI interface. They do two things at once: they show what the product can do, and they teach how to phrase a good request.

Some rules we follow:

• Write them from real tasks. Look at what your customers actually do. "Summarize last week's support tickets" teaches more than "Tell me something interesting".
• Show a range. One simple prompt, one more detailed, one that uses the user's own data. Three to five is enough.
• Make them one click. Clicking a prompt should fill the box, and the user can edit before sending. Sending at once is faster, but it takes away the chance to adjust.
• Make sure they work. An example that gives a poor answer does damage. Test every one on the real model, and again after model updates.
• Change them with context. A user who has connected their data should see prompts about that data, not generic ones.
• Retire them. Experienced users do not need them on every screen. Move them aside once the user has sent a few messages.

The tone of the examples also sets the tone of the product. Short, concrete, ordinary requests suggest the tool is for real work.

Context and attachments

Often, the question depends on something else: a file, a page, a customer, a date range. If the product knows that context, show it. If the user must supply it, make that easy.

Context chips. Small labeled tags above or inside the box that show what the model will look at: "Q3 sales report", "This project", "Last 30 days". Each chip has a way to remove it. They make the invisible visible, and they let users fix a wrong guess before sending.

Attachments. Support the ways people actually bring files in: a button, drag and drop, and paste. After upload, show the file name, its type and a way to remove it. If the file is being processed, show that too. Say which file types are allowed before the user tries, not after an error.

Mentions. Typing "@" to pull in a document, person or dataset works well in products where there is a lot to reference. It needs search, keyboard selection and a clear display of what was added.

Whatever you choose, be honest about limits. If the model can read only the first part of a long file, say so.

Controls for tone, model and sources

Settings that change the answer are useful. But each one adds a decision for the user. Be strict about which ones deserve space near the box.

• Tone or length. Useful in writing tools. Best as a small menu or a set of quick options, not a long form.
• Model choice. Helpful for advanced users, confusing for everyone else. Put it behind a menu with plain labels like "Faster" and "More careful", and avoid model names that mean nothing to the user. If your audience is technical, names may be fine.
• Source selection. If answers can come from different data, let the user choose where to look. Default to the sensible choice and show the current one.
• Web or no web, files or no files. Simple toggles, with clear on and off states.

Settings should remember the user's last choice. Resetting every time is irritating. And any choice that affects trust or privacy, such as sending data to an outside service, should be clear and visible rather than buried.

Keyboard and mobile use

Many prompt boxes are used all day by people who type fast, and also by people on a phone. Both need care.

On a keyboard:

• Enter sends, Shift+Enter adds a new line. This is the common habit. If your users write long prompts, consider the reverse, and tell them which one you chose.
• The box grows as the user types, up to a limit, then scrolls.
• Pressing the up arrow in an empty box brings back the last prompt.
• Escape stops a running answer or closes a menu.
• Focus returns to the box after an answer, so the user can type again right away.

On a phone:

• Keep the box above the on-screen keyboard and make sure it is not covered.
• Make buttons large enough to tap. WCAG 2.2 sets 24 by 24 CSS pixels as the minimum target size, with a few exceptions, and bigger is kinder to thumbs.
• Put the voice input button where it is easy to reach, if you offer it.
• Avoid long lists of example prompts that push the box off the screen.

Also, label the box and the buttons properly for screen readers. An icon with no text label is invisible to many users.

Testing with real users

You cannot judge a prompt box from a design file. It needs real people typing real things. A simple test:

1. Give five users a task, not instructions. For example, "Find out which customers have not logged in this month."
2. Watch where they look first, what they type, and whether they use the examples.
3. Note when they hesitate, retype or give up.
4. Ask what they thought they could and could not ask.
5. Look at the prompts people send after launch. They show what the box needs to teach.

You will often find that users ask for things the product cannot do. That is useful. It tells you what to add, or what to say in the empty state.

A note on keeping it simple

The best prompt boxes feel almost plain: a box, a send button, a few quiet extras and good examples. The detail work, like context chips and states, makes it feel clear.

We design these as part of our AI product UX work, and you can read about what we do on the AI product design agency page. You can see what we build for ourselves in the Lab. If you have a prompt box you are unsure about, send us a screenshot through the contact page, and we will give you honest notes in a free design review.