The first-run experience: onboarding a tool nobody reads docs for

There is a polite fiction in a lot of product design that users will read the onboarding. They will watch the welcome tour, follow the tooltips in order, and absorb the documentation before they begin. For a free tool that someone opened from a search result with one specific task in mind, this fiction is simply false. They did not come to learn your tool; they came to remove a background, make a thumbnail, or cut a clip, and they will give the screen a few seconds to convince them it can do that before they bounce back to the results page and try the next link. The documentation you wrote, however good, is read by a tiny minority and almost never before the first attempt.

Designing for that reality is liberating once you accept it, because it collapses the onboarding problem into a single concrete question: when a stranger opens this tool with no preparation and no patience, does the first screen get them to their first result fast enough that they stay? Everything else — the docs, the tutorials, the help — is for the minority who go looking later. The first run is the whole onboarding for almost everyone, and it has to teach without a lesson, guide without a tour, and deliver without a setup. This article is about how to make a first screen do that job.

If you internalise one thing, make it this: the empty first screen is your onboarding documentation, because for most users it is the only instruction they will ever see. That reframes the empty state from a placeholder you tolerate into the single most important screen in the product. It has to answer, at a glance and without being read closely, three questions a newcomer is holding: what is this, what do I do first, and what will I get. A first screen that answers those three implicitly, through its layout and its single obvious action, has onboarded the user. One that just shows a blank canvas and assumes they will figure it out has quietly failed the majority before they started.

This is why a thoughtful empty state is worth more than any tour. A tour interrupts; an empty state teaches in place, while the user is already oriented toward doing the thing. The job is not to explain the whole tool — that is what the docs are for, for the people who want them — it is to make the very first step unmistakable and to imply the payoff. The deeper craft of designing a working empty state is its own subject, covered in /product-blog/empty-states-that-do-real-work, but the headline for first-run specifically is that you should pour your onboarding effort into that blank screen rather than into overlays the user will dismiss.

A newcomer faced with many equally-weighted options does not feel empowered; they feel stalled, because they do not yet have the context to choose and every option is a small demand to make a decision they are not equipped to make. The antidote is to make the single most important action unmissable and to let everything else recede until it is relevant. For a background remover that means a large, obvious way to add an image and very little competing for attention; the layers, the export options, the AI suite, the batch mode all exist, but none of them should shout on the first screen, because none of them is the first step. The first run should have one front door, not a lobby full of doors.

This restraint is hard because every feature team wants their feature visible, and the cumulative result of everyone winning that argument is a first screen so busy that the actual first step is lost in it. The discipline is to ruthlessly subordinate everything to the one action that starts the workflow, trusting that the rest of the tool will reveal itself naturally once the user is in motion. A new user who clearly sees what to do first and does it is now an engaged user who will happily discover the depth; a new user staring at twelve equal options is a bounce. Singular and obvious beats complete and overwhelming every time on the first screen.

The first run succeeds or fails on time-to-first-result: how long from opening the tool to seeing it do the thing it promised. This is the moment the visitor was actually after, and the faster it arrives the more likely they are to stay, because a fast first win converts curiosity into belief. Anything that stands between the open and that first result is suspect — a signup wall, a settings step, a configuration screen, a permission request that is not strictly necessary yet. Each of these is a place where a user who has not yet seen any value is asked to invest before getting any, and that is exactly the wrong order. Value first, asks later.

The signup wall deserves singling out because it is the most common and most costly first-run killer. Asking someone to create an account before they have seen the tool do anything is asking them to bet on a promise, and most will not — they will leave and try a tool that just works. The judgement of when an account is genuinely worth requesting is its own decision, argued in /product-blog/when-to-add-accounts-to-a-free-tool, but the first-run principle is unambiguous: never gate the first win. Let the user reach the result that proves the tool works, and only then, if at all, introduce the account for the things that genuinely need one. The first result is sacred; protect the path to it.

A powerful and underused first-run technique is to give the user something to act on rather than only a blank space to fill. A sample image they can try with one click, a pre-loaded example, a “try this” shortcut — any of these lets someone experience the tool before committing their own file, which lowers the barrier to the first result to almost nothing. It also demonstrates the workflow by doing rather than describing: the user clicks the sample, watches the tool work, sees the result, and now understands the whole loop without a single sentence of instruction. Showing beats telling, and a sample is the cheapest way to show.

This matters most for tools where providing your own input is itself a small hurdle. If using the tool requires finding and uploading a file, some fraction of curious visitors will not bother on a tool they are merely evaluating — but they will click a sample, because it costs nothing. Once they have seen the result on the sample, providing their own file feels worth it, because now they know what they will get. The sample converts a passive evaluator into an active user by letting them experience the payoff before paying the cost of their own input, which is exactly the sequence a good first run wants.

None of this means help should not exist; it means help should be layered so that the first run stays clean for the majority while the answers are within reach for the minority who want them. The model is progressive disclosure: the first screen shows only the one obvious action; a brief inline hint sits quietly nearby for anyone who pauses; and the fuller help — a getting-started tutorial, an in-context help mode, the docs — is one click away for the person who deliberately goes looking. Nobody is forced through a lesson, and nobody who wants guidance is stranded. The help is present at every level of need without imposing on the level below it.

The mistake at both extremes is instructive. Too little, and the genuinely confused user has nowhere to turn and leaves; too much, and the eager user is buried in tooltips and tours before they have done anything, and leaves for the opposite reason. The balance is to make the common path — open, act, succeed — require no help at all, and to make help unmissable the instant someone signals they want it, for example through a dedicated help mode of the kind described in /product-blog/designing-an-in-context-help-mode. Default to clean, escalate to helpful on demand. That layering is what lets a single first screen serve both the user who needs nothing and the user who needs a hand.

It is worth remembering what is actually at stake in those first few seconds. A free tool lives or dies on word of mouth and return visits, and both start with a first run that worked. The user who opened the tool, immediately understood what to do, and reached their result fast is the user who bookmarks it, tells a colleague, and comes back — not because of anything they read, but because the tool respected their time and delivered. Every second of friction before the first result is a tax on that outcome, and every unnecessary ask before any value is a reason to leave.

So the whole discipline of a zero-docs first run comes down to a kind of generosity with the newcomer’s attention: assume they will not read anything, will not watch anything, and will not wait long, and design the first screen to reward them anyway. Make the empty state teach, make the first action obvious, protect the path to the first result, offer a sample to try, and keep help one layer away. Do that, and a stranger who arrived with one task and no patience leaves having done the task — which is the only onboarding metric that ever really mattered. You can feel the difference by opening a tool cold and counting the seconds to your first result.