Your empty state is the onboarding

A B2B trial is mostly decided on a screen with nothing on it. The buyer signs up, lands in the product and finds a dashboard with no data, a table with no rows and a sidebar full of features nobody has set up. That screen is the onboarding. The tour, the welcome email and the checklist are supporting acts.

Most products treat the empty state as a gap the customer will fill later. It should be designed first. It is the one screen every trial user is guaranteed to see, and they see it at the exact moment they are deciding whether the product deserves an afternoon.

Why the first screen of a trial is usually blank

Products get designed with data in them. The mock-ups show a full dashboard with healthy charts, because that is what the product looks like when it works. The trial user gets the version nobody drew: zeros, "No results", and a spinner that might be loading or might be broken.

Kate Kaplan at Nielsen Norman Group makes the point in her guidelines on designing empty states in complex applications: in software the user has not configured yet, empty states are common during onboarding and early use. She also notes that "totally empty states cause confusion about how and whether the system is working."

That confusion arrives at a bad time. The person trialling your product has a meeting in forty minutes and two other tools on the shortlist. Every blank panel is a question they now have to answer on their own, and the easiest answer is to open the next tab.

The product tour is not the onboarding

The usual fix is a tour: five tooltips pointing at things the user cannot use yet. Nielsen Norman Group's research on onboarding tutorials versus contextual help finds that users frequently skip tutorials, that tutorials interrupt people, and that what they teach is quickly forgotten. The article describes the paradox of the active user: people want to start doing the thing, not prepare to do the thing, even when the preparation would help.

The tour has a second problem. It explains features in the order the team built them, to someone with no data to see them working. A tooltip saying "This is where your reports live", pointing at an empty reports panel, is a promise. It is not a demonstration.

The empty state does not have either problem. It appears when the user reaches the feature, which is what the same article calls a pull revelation: help that turns up because the user went there. Nobody has to dismiss it. Nobody has to remember it, because it will still be there next time.

An empty screen is the only page of your product every trial user is guaranteed to read.

What a well-designed empty state does

Kaplan's guidelines come down to three jobs, and they make a decent brief:

• Say what is happening. Empty, loading or broken: never make the user guess.
• Teach the feature where it lives. One line on what will appear here and why it is worth having.
• Offer the next step. A button that starts the task, not a paragraph describing it.

For B2B products there is a fourth: show the finished version. Sample data, a demo workspace, a preview of the screen full. One of the examples in the article offers exactly that choice, connect a real source or explore demo data, and the second option matters more than it looks.

The person running a business software trial may well be an evaluator rather than the eventual administrator. They may not be allowed to connect a live system on day one without asking someone, and they still have to argue for the product in a meeting. Demo data lets them see what they would be buying without a ticket to IT. An empty product asks them to take the good part on trust.

Design the product at zero first

The practical change is the order of work. Design every key screen empty before designing it full. Write the copy for the table with no rows before the copy for the table with a thousand. Then walk the trial as a brand new account would, with no data, no integrations and no colleagues invited, and count the screens that leave the user to work out what to do next.

That walk tends to be humbling. Sales demos run on a well-stocked account, so the product always looks finished in front of a prospect. The demo account has quietly done the onboarding on the salesperson's behalf. The trial user gets no such help, and gets it at the moment the deal is actually being decided.

It is also cheap to fix compared with most product work. An empty state is mostly a sentence, one action and a preview. It needs no new feature and no change to the data model. It needs someone to decide that it is part of the product rather than the absence of one. We treat it that way in our product design work, and it is usually among the first things we look at in a free UX audit.

Full dashboards sell demos, empty ones sell trials

Every other piece of onboarding points back at the same screen. The welcome email says log in and get started. The checklist says create your first project. The tour says look over here. If the screen they all point at is blank, they are pointing at nothing.

So judge the product the way a new customer meets it: empty, unconfigured and on a shortlist. A full dashboard wins the demo. The empty one wins, or quietly loses, the trial.