Empty, Loading and Error States: The Screens Founders Forget

Every screen in your app has more states than the one in your prototype. Empty (nothing here yet), loading, error, no connection, partial data and success. Most prototypes show only the screen with data in it, and the rest are left to developers to invent. Design them on purpose, starting with the ones a new user sees first: the empty state and the first error.

Prototypes show the happy path, with data loaded and everything working. Real people meet the other screens first: the empty list on day one, the spinner that does not end, the message that says "Something went wrong". For many users, these are the first impression of the product.

Which states does a screen need?

What does a good empty state look like?

An empty state is the first thing a new user sees in many parts of an app. A blank screen with "No items" is a dead end. A good one does three things: explains what the area is for, shows what it will look like when it is full, and offers the one action that fills it.

In Lit, an app for meeting people through activities, a first-time user with no activities yet sees an empty state that points straight into Discover, not a dead end. Once someone has joined or created activities, they live on one dashboard organised into Joined and Created tabs and tagged by status: scheduled, ongoing, completed or canceled.

What does a good error state look like?

• Plain words. Say what happened and, if you know, why. "We could not save your changes. Check your connection and try again."

• Keep the input. Never ask someone to retype what they already entered.

• A way forward. A retry, an alternative or a way to contact support.

• No blame. Do not say "invalid input" when the instructions were unclear.

When a path has no ready answer, give it a fallback. On Alva, an AI scanner app, a product that cannot be found by barcode or photo can be added manually. On Wheel, one of the problems we fixed was the inability to enter data manually when a LinkedIn import failed. In both cases the failure has a way out.

What does a good loading state look like?

Keep the layout stable so content does not jump when it arrives. Use skeletons or placeholders for content that loads in pieces. Show progress when you know it, and a clear message when something takes unusually long. A spinner with no end and no explanation reads as a broken app.

How do you decide which states to design first?

1. The first-use empty states. What a new user sees on every main screen before they have created anything.

2. The errors on the core journey. Sign-up, payment, submission: anywhere failure stops the task.

3. No connection and permission denied for anything that depends on them.

4. Everything else. Add as the product grows.

What to do this week

1. Take your main screens and write the states each one can be in.

2. Make a fresh account and screenshot every empty screen.

3. Turn on airplane mode and go through the core journey.

4. Make a list of everything that shows a blank screen, a spinner or a generic error.

5. Design the top three.

FAQ

Do I need to design all the states before the MVP?

Not all. Cover the ones that would make the main task unsafe, impossible or misleading, and the empty states a new user meets. Put the rest in a documented backlog.

Who writes the error messages?

The design team, with developers, because the message depends on what the system can detect. Write them with the people who know what can fail.

Are these states part of a design handoff?

Yes. Without them developers invent their own. See what a development-ready handoff includes.

If you want a review of your app's states and journeys, see our mobile UX/UI design service, or book a free 30-minute Product Diagnosis.