Prompt Suggestions and the Blank Canvas Problem

The empty state of an AI feature is the highest-leverage screen in it, and it is usually the one nobody designed. Everything a user will ever believe about what your feature can do is decided in the few seconds they spend looking at an empty box.

A cursor communicates nothing

Hutchins, Hollan and Norman’s 1985 paper Direct Manipulation Interfaces gave us the vocabulary for exactly this failure: the gulf of execution is the distance between what a user wants to accomplish and the actions the system makes available, and an interface bridges it by making the available actions visible and matched to the user’s intentions.

A text box is the widest such gulf a modern interface contains. Every other control in your product signals its own affordance — a slider has a range, a dropdown has options, a disabled button says no. A text box accepts every string and signals nothing about which ones do anything useful. The user has to construct the entire model of the system from the outside.

Which is why the failure it produces is so consistent. Users type something small and safe, get a mediocre result because the request was under-specified, and conclude the feature is mediocre. They do not conclude the request was under-specified, because nothing told them a more specific request was possible.

Three jobs, usually conflated

Suggestion chips are asked to do three different things and most implementations pick one at random.

• Teach the capability boundary. What kinds of thing can this do at all? This job wants suggestions spread across categories — one from each cluster of what the feature supports — even if none of them is what this user wants today.
• Teach the input format. How specific should I be? This job wants one deliberately long, detailed example, because a row of four-word chips teaches that four words is the expected length, and four words is usually the reason the first result was bad.
• Get to first value. Do something useful right now. This job wants suggestions grounded in the user’s actual data, and it is the only one of the three that produces a real outcome on the first interaction.

They conflict. Breadth costs specificity; specificity costs coverage. The resolution that generally works: two or three broad chips for coverage plus one worked example that visibly demonstrates the format, rather than four chips that all do the same job badly.

Rules for a suggestion

• It must run and succeed. A suggestion that produces an error, a refusal or a bad answer is worse than an empty state, because you chose it. Suggestions are the one input path you fully control, so there is no excuse for one that has not been tested.
• It must be executable, not aspirational. If the feature cannot browse, do not suggest “summarise this URL”. The empty state is where the capability boundary is being taught, and a suggestion outside it teaches the wrong boundary at the worst possible moment.
• It should disappear once typing starts. Suggestions are an empty-state affordance. Persisting them beside a partly typed message competes with the thing the user is already doing.
• Keep the first slot stable. Rotation is good for teaching breadth and terrible for building a habit. A returning user should find the thing they used last time in the same place.
• Prefer a verb over a noun. “Draft a reply declining this” sets a task. “Email help” sets a topic and leaves the user to invent the task anyway.

Suggestions from the user’s own data

Generic suggestions teach that the feature is generic. “Write a poem about a robot” in a project-management tool tells a user that this is a language model bolted on, not a feature of their product.

The version that works is templated against whatever the user is currently looking at: “Summarise the 12 comments on PROJ-4417”, “Draft the release note for the 6 issues closed this week”. These require no model call to construct — they are string templates over data you already have on the page — and they do all three jobs at once: they demonstrate a capability, they show the expected level of specificity, and running one produces something real.

One caution: a templated suggestion has to be true. A chip offering to summarise twelve comments when there are none is a bug the user notices immediately, and it damages the empty state’s credibility more than a generic chip would have.

The feedback loop nobody notices

Suggestions shape your traffic, and your traffic shapes what you evaluate and optimise. Within a few weeks of shipping four chips, a large share of the requests hitting the feature are those four requests, or close paraphrases of them.

That is mostly good — it is the discoverability working — but it has two consequences worth planning for. Your prompt tuning will be driven by cases you selected rather than cases users brought, so the long tail gets quietly worse while the headline quality improves. And your production quality signal becomes partly a measure of your own suggestions.

The mitigation is cheap: tag requests by whether they came from a suggestion, and look at the two populations separately. If suggested prompts succeed far more often than typed ones, the gap is the size of your discoverability problem, and it is a number worth watching.

The typed population is also the more valuable of the two, and it is the one nobody reads. It is a continuously updating list of what users believe your feature should do, written in their own words, at the moment they wanted it. Requests that fail in that pool are either the next features or the next suggestions, and either way they are worth more attention than the aggregate success rate that averages them away.