To get new users past the blank prompt box in your AI tool, stop asking them to invent a prompt on their first visit. Put one plain line above the box that says what the tool does and doesn't do, offer three to five clickable starter prompts written from real jobs, add a "try it with a sample" button that shows a real result in under a minute, and swap part of the open box for two or three simple fields on the first run. Then track one number: how long it takes a new signup to reach their first useful output, meaning an output they copy, export, or save. Below you'll find the steps, a made-up example, a pattern table, a 14-day plan, and the traps that undo all of it.
Why the empty prompt box loses so many signups
Your landing page promised an outcome. Then the user signs up and gets a cursor blinking in an empty box. Nielsen Norman Group's article on prompt suggestions describes the moment well: "When people first begin using an AI system, they're often faced with the 'blank page' problem and must think about how they could use the product."
You've typed thousands of prompts into your own product. Your new user has typed zero. NN/g's study on how AI literacy shapes genAI use found that people with low prompt fluency wrote prompts that "often resembled search queries," without the context or constraints that make an output useful. Three words in, a vague answer out.
Others don't type a task at all. In NN/g's research on new users and generative-AI tools, newcomers asked the bot about its own abilities instead, the "Can You" prompts. Microsoft's HAX Toolkit puts the cost plainly in its first guideline, make clear what the system can do: "Unclear user expectations about the set of supported tasks or domains can lead to disappointment, product abandonment, and even harms."
The running example (made-up)
Brieflark is an illustrative, made-up product, and every number and user input about it below is made up too.
The setup: a solo founder builds an AI tool that turns a client's rambling email, or a designer's call notes, into a one-page design brief with goals, deliverables, and open questions. The first screen is a big empty box that says "What do you need?" In launch week, 40 people sign up. Seventeen never press Generate. Of the 23 who do, the most common first inputs are "hi", "what can you do", and "write a brief" with nothing pasted underneath.
Step 1: Define the first useful output
"Generated something" isn't the finish line. What matters is whether the output was worth something to the user, and the honest signal is what they did next: copied it, exported it, sent it, or saved it.
Pick one event that fits your product's job. For Brieflark, it's "copied or exported a brief that was generated from the user's own client notes." A brief made from the sample input doesn't count. Then record two timestamps for every new account: signup and that first useful output. The gap between them is your time to first useful output, and the share of signups who get there at all is your first-run rate.
If you haven't chosen an activation event before, this guide to tracking the product metrics that matter before your first 100 users covers how to pick one and what to ignore while your numbers are small. My rough rule for AI tools: if a motivated new user can't reach a useful output in about five minutes, the first run is the problem, not the model.
Step 2: Find out exactly where people stall
Before changing anything, add four events: saw the prompt box, typed anything, submitted, and reached the first useful output. They show whether people freeze before typing or get an answer they don't use.
Then read the actual first inputs from your last 20 or 30 signups. Only do this if your privacy policy covers it and users know you look at inputs to improve the product. Sort each one into a bucket:
Empty: saw the box, never typed.
Capability question: "can you do X?" or "what is this?"
Too thin: the right job with no material ("write a brief").
Wrong job: asked for something your product doesn't do.
Good: real material and a clear ask. Keep these. They become your starter prompts in Step 4.
If you can, watch three people do their first run on a call and keep quiet. In the made-up Brieflark data, the buckets come out as 17 empty, 6 capability questions, 9 too thin, 2 wrong job, and 6 good. The model was never the bottleneck. The box was.
Step 3: Say what it does and doesn't do, right above the box
Google's People + AI Guidebook chapter on mental models advises: "Be up-front about what your product can and can't do the first time the user interacts with it." It even offers a fill-in template: this is your product, it helps you by these benefits, right now it can't do these things.
Shrink that to one or two lines right above the input, not in a welcome modal. Brieflark's version: "Paste a client email or your call notes. You'll get a one-page brief with goals, deliverables, and questions to ask. It won't invent budgets or deadlines that aren't in your notes." That answers the capability questions before anyone types them.
Placement matters. NN/g's AI literacy study watched a first-time user work around a large welcome message in Gemini for about 10 minutes before dismissing it, with no sign she read it. The earlier NN/g piece on new AI users is blunter: "People don't want to read a long list of instructions before they can try something out."
The line should also match what your landing page promised. If your homepage keeps shifting while you find fit, here's how to approach writing a landing page when your product changes weekly so the promise and the first screen stay in sync.
Step 4: Write three to five starter prompts from real jobs
Starter prompts are the biggest single fix, because, as NN/g's prompt suggestions article puts it, "If the prompt suggestion is right, users can skip typing." They also teach the shape of a good request without a tutorial.
Write them from evidence: the "good" inputs from Step 2, the jobs people mention in support emails, and the use cases on your landing page. Brieflark's four (made-up):
Turn this client email into a one-page brief: [paste email]
Make a brief from my call notes and list what I still need to ask: [paste notes]
Rewrite this brief so a non-designer client can approve it: [paste brief]
Compare these two client emails and list what changed in scope: [paste both]
How specific should they be? NN/g's research pulls two ways here. In the 2024 study of first-time chatbot users, broad examples like "Help me generate text" worked better than niche ones like horoscope matching. In the 2025 guide to designing use-case prompt suggestions, the advice is that "Broad or generic prompt suggestions are rarely effective." The way I read them together: write at the level of your user's real job. Broad enough that most of your users have that task this week, specific enough that they can tell in a second whether it's theirs.
The mechanics from that 2025 guide are worth copying:
Put the suggestions near the input field, where attention already is.
Make them clickable. The guide suggests a click can insert a longer prompt into the field for the user to edit before submitting. That's exactly what the bracketed slots above are for.
Curate them by hand rather than pulling them automatically from recent activity.
If you measure which ones get clicked, randomize the order, because placement affects clicks, not just content.
Step 5: Offer a "try it with a sample" path
Some users can't paste their own material on the first visit, or just want to see what happens first. The PAIR chapter's advice fits: "Suggest a low-risk or reversible action they can try right away."
Add one button next to the box: "Try it with a sample." It fills in a realistic input, labelled as a sample, and runs it. Brieflark's sample is a made-up, slightly chaotic client email about a bakery rebrand, with the budget mentioned once in passing and two contradictory deadlines. The brief comes back with an "open questions" section that catches the contradiction. Now the user knows what good input looks like.
Two rules keep this honest. First, the sample run is not your activation event. The next screen should have one clear button, "Now try it with your own email," and only that run counts toward Step 1. Second, the sample output must be a real output from your product, not a polished mockup. NN/g's 2025 guide notes that one well-known assistant's pre-login carousel used conversations so simplified that they "arguably misrepresented the complexity" of getting that result. If your sample looks better than what real input gets, you've just set up the first disappointment.
For ordinary SaaS dashboards, the same idea is seeding demo data, covered in this piece on fixing the first 10 minutes instead of the landing page.
Step 6: Turn the first run into a few plain fields
An open text box asks the user to do two jobs at once: decide what they want and phrase it for a machine. A few fields split those jobs apart. NN/g's AI literacy article suggests "lightweight controls for common filters or constraints" and one-click refinements as ways to help people say what they need. HAX Guideline 1 points the same direction with its patterns for demonstrating possible inputs and exposing system controls.
For the first run only, Brieflark replaces the empty box with:
A large field: "Paste the client email or your notes."
A dropdown: project type (logo, website, packaging, other).
An optional line: "Anything the brief must include?"
The product builds the full prompt behind the scenes. After the first output, the normal chat box appears underneath for follow-ups. If your users are developers or heavy AI users who'd rather type freely, keep a small "skip to a blank prompt" link. Nobody should be trapped in a form.
Step 7: When the first prompt is vague, ask one question back
"Write a brief" with nothing attached is a common first message. The worst response is a confident, generic brief about an imaginary client, because the user learns the tool makes things up. NN/g's AI literacy study suggests asking a short clarifying question when a prompt is vague instead of guessing.
Brieflark's reply to that message: "Happy to. Paste the client's email or your call notes and I'll turn them into a brief. Nothing handy? Try the sample first." One question, one escape hatch.
Handle "Can You" questions the same way. NN/g's study of new users recommends that the bot know its own capabilities and answer when asked. In practice, put a short, accurate capabilities note in your system prompt: the jobs it does well, what it won't do, and a pointer to the sample button.
Step 8: Make the first output easy to fix, not a dead end
Even a good first output won't suit everyone, so make it easy to adjust. The PAIR chapter puts it simply: "Don't create dead-ends when an AI feature fails," and give people a way to finish the task themselves.
Under Brieflark's first output sit three refinement chips (shorter, add questions for the client, friendlier tone), an editable text area so the user can fix one line without regenerating everything, and a prominent copy and export button. That last part matters for Step 1: if copying is hard to find, your first useful output event undercounts, and you'll think the product is failing when the button is.
Step 9: Follow up with people who left before the first useful output
Some people will still leave early. Send one behavior-triggered email to accounts that signed up but never reached the first useful output, and skip anyone who did. Make the link do the work: open the sample run, or open the box with a starter prompt already filled in, rather than dropping them on an empty dashboard.
Brieflark's version is three sentences: what the tool does in one line, "most people start by pasting one client email," and a button that opens the first-run fields. For the full sequence logic, see this guide to writing onboarding emails that get users to their first win. For a first-run fix, one or two emails is plenty.
Which first-run pattern to use
You don't need all of these at once. Here's how I'd choose. The effort column is my rough estimate for a solo founder, not a benchmark.
Pattern | Best when | Skip or delay when | Rough effort |
|---|---|---|---|
One-line "does and doesn't" note | Always. It's the cheapest fix there is. | Never skip it. | An hour |
Starter prompts (pills) | Your tool has a few common jobs | You haven't read real first inputs yet | An afternoon |
Example gallery (prompt plus output cards) | Output is visual or the task is complex | You'd have to fake the examples | A day or two |
Try-with-sample button | Users often lack material on visit one | The output is only meaningful on their own data | An afternoon |
First-run fields | Most first inputs are empty or too thin | Your users are fluent prompters | A day or two |
Clarifying question | Thin prompts like "write a brief" are common | Inputs are usually complete already | An hour of system-prompt work |
Refinement chips plus editable output | People get output but don't copy it | Outputs are already used as-is | An afternoon |
Rescue email | A real share of signups never reach the first useful output | You can't trigger it on behavior yet | An hour |
A 14-day plan to fix your first run
Day 1: Define the first useful output event. Add the four events from Step 2.
Days 2 to 4: Let real signups flow. Read 20 to 30 first inputs and sort them into buckets. Watch three first runs on a call if you can.
Day 5: Write the "does and doesn't" line and put it above the box. Check it against your landing page promise.
Day 6: Write three to five starter prompts from the "good" bucket. Make them insert editable text.
Days 7 to 8: Build the sample path with a real output, plus the "now try your own" button.
Days 9 to 10: Add first-run fields or a clarifying question, whichever your biggest bucket calls for.
Day 11: Add refinement chips, an editable output, and an easy-to-find copy and export button.
Day 12: Set up the rescue email for signups who haven't reached the first useful output after a day.
Days 13 to 14: Compare the first-run rate and median time to first useful output against your Day 1 to 4 baseline.
With small numbers, treat that comparison as a direction, not proof. In the made-up Brieflark run, the next 40 signups produce 21 useful first outputs instead of 6, and far fewer "hi" messages. If you want to know which change did it, ship them one at a time.
Traps that keep catching AI founders
A tour before the box. Five slides about features nobody has used yet. People skip them, and the box is still blank afterward.
Starter prompts that show off. A haiku about quarterly taxes proves the model is clever. It doesn't match anything your user came to do.
A sample that's better than reality. If the demo output is hand-polished, the first real run feels like a downgrade.
Counting suggestion clicks as success. A click is interest. A copied, exported, or saved output is the win.
Removing the open box for everyone. Fields help newcomers. Fluent users need a way out.
Logging first inputs quietly. Tell users you review inputs to improve the product, and keep only what you need.
FAQ
Should I replace the chat box with a form?
For the first run, often yes. After that, usually no. Fields help people who don't know what to ask, and chat is better for follow-ups. A form for run one with chat underneath is a good default for most single-job AI tools.
How many starter prompts should I show?
Three to five is my rule of thumb. Fewer than three can hide the range of jobs. More than five and people start reading instead of clicking. NN/g's 2025 guide notes that short prompts take little space, so several can fit near the input, while longer, richer examples work better shown one at a time.
Do I still need a product tour?
Rarely, for a single-job AI tool. NN/g's guidance for new AI users is to skip long onboarding where you can and give contextual help when someone needs it. A one-line note, starter prompts, and a sample teach by doing.
Fixing the first run pays off most on launch week, when a wave of people meet your blank box at the same time. Once yours greets them with a clear first step, launch your AI product on EarlyHunt and let the early adopters show you whether it worked.