Empty states: turn blank screens into first steps

A new user signs up, lands on the dashboard and sees nothing. No projects, no contacts, no bookings. A grey box says “No items yet”. They click around, find more empty screens, and close the tab to come back “later”.

That blank screen is called an empty state. Every new user sees it, and it appears just as they are deciding whether your app is worth the effort. An empty state that says nothing is a dead end. One that says the right thing is the first step of setup.

This post is a checklist for the screens your users see before they have any data: what to say, which one action to offer, and when to fill the screen for them instead.

Find every empty state first

Most products have more empty screens than the team thinks. The dashboard is the obvious one, but a new user also meets empty lists, empty search results, empty reports, an empty inbox and an empty settings page for every integration they haven’t connected.

Sign up with a fresh email and walk through your product as a new user. Write down every screen with nothing on it. Then sort them into three kinds, because each needs something different:

• First use. The user has never had data here. This is the one that matters most for setup.
• Cleared. The user had data and finished or removed it, such as an inbox at zero. A short “all done” is often enough.
• No results. A search or filter came back empty. Say what was searched and offer to clear the filter.

The rest of this post is about the first kind, since that is where new users stall.

What to say: the job, not the feature

The text on an empty state has one task: tell the user what this screen is for, in terms of what they want to get done. “No projects yet” describes the screen. “Projects keep your team’s work in one place. Start with the one you’re working on this week” tells them why to care and what to do.

A few rules keep it short and useful:

• Lead with the result. What will the user have once this screen is full? Say that first.
• One or two sentences. The user came to do something, not to read. Put the detail in a help link.
• Use their words. Name the thing the way your users would, not the way your database does.
• Don’t blame or apologise. “Nothing here yet” is fine. “Oops, you have no data” is not.

One action, clearly the main one

An empty state should offer one main action. A screen with “Create”, “Import”, “Connect”, “Watch a video” and “Read the docs” as equal buttons asks the user to make a decision before they understand the product. Many will pick none.

Choose the action that gets most users to their first result fastest. For a contacts product that might be importing a list. For a scheduling app it might be creating a first event type. Make that the one large button, and if a second path matters, put it underneath as a quieter link.

The action should also start the job, not describe it. A button that opens the import screen is good. One that opens a help article about importing sends the user away just as they were ready to act.

When to pre-fill instead

Sometimes the best empty state isn’t empty. There are two ways to fill it, and each suits a different case.

• Sample data shows the screen as it looks in use, with clearly labelled example items the user can explore and then remove. It works well when the value is hard to picture, such as a reporting dashboard or a pipeline view. It works less well when users mistake the examples for their own data, so label them plainly and make removing them one click.
• Sensible defaults create real, useful items the user would have made anyway: a default calendar, a first pipeline with common stages, a working set of notification settings. This removes setup steps rather than explaining them. It works when most users would choose the same starting point.

Leave the screen empty, with a clear action, when every user’s first item is different and only they can make it: their own clients, their own project, their own price list. Pre-filling those gets in the way.

Approach	Good for	Where it runs out
Message and one action	Screens where the user’s first item is their own	Users who aren’t sure how to do the action
Sample data	Showing what a full screen looks like	Users confusing examples with their own data
Sensible defaults	Steps most users would do the same way	Anything that depends on the user’s own data
In-app AI agent	Doing the first step when the user asks for it	Anything the app itself can’t do

The empty state checklist

Run each first-use screen through these questions:

1. Does it say what the screen is for, in terms of the user’s job?
2. Is it two sentences or fewer?
3. Is there one main action, and does it start the job rather than link to help?
4. Would sample data or a default make the first step unnecessary?
5. If there is sample data, is it labelled and easy to remove?
6. Does the screen point back to the next step of setup once it has data?
7. Have you checked it on a fresh account in the last month?

1. Step 1User landsNothing on the screen yet›
2. Step 2Say the jobWhat this screen will do for them›
3. Step 3Offer one actionThe step that starts it›
4. Step 4Pre-fill if it helpsDefaults or labelled samples›
5. Step 5First resultThe screen has real data

To see which empty screen is costing you the most new users, count how many get past each setup step. Where new users stall in setup shows how to build that funnel, and the user onboarding checklist covers the rest of the first session.

How an in-app agent like Stiro handles the first step

The hardest empty state is the one where the user knows what they want but not how to get it. They want their contacts in, or their first event set up, and the button leads to a form with fields they don’t understand yet. An in-app AI agent fits there: the user asks for the result in plain words, and the agent does the steps in your app.

Stiro is one. You add it with one script tag, with nothing to train and no flows to record. A new user looking at an empty event list can type or say “set up a 30 minute intro call I can share with clients”, and Stiro clicks, types and moves through your real interface to create it while they watch. The empty state becomes a finished first step.

• It works on the screens you have. Stiro reads the live screen, so when you redesign an empty state, there is nothing to update.
• It says so when it can’t. If a request isn’t possible in your app, it stops, explains why and changes nothing.
• The user keeps the final say. Anything that sends, spends or deletes is set up and handed back for them to press.
• Stuck goes to your team. If it can’t finish, a signed-in user can message your team or your help desk from the same panel.

We tested Stiro cold in three open-source apps it had never seen, a CRM, a project tracker and a scheduling app, and checked every result in the app’s own database:

requests done, first run, cold

44 of 44

on a repeat run of the same code

43 of 44

median time from request to reply

19.5 s

The benchmark lists every task and the reply Stiro gave.

Make the blank screen do some work

Find every empty screen, say what each one is for, offer one action that starts the job, and pre-fill where most users would start the same way. For the users who still aren’t sure where to begin, let them ask. Stiro does that first step in your app when they do, and the free plan includes 50 runs a month on localhost and a staging address, so you can try it on your own empty states before they reach a real user.