Skip to main content
How-To11 min read·2,066 words

Empty State Design for Mobile Apps

Empty state design for iOS and Android: classify zero-data screens, choose one action, and turn blank app screens into useful first steps users can complete.

#how-to#mobile app design#flow#empty state ui#zero data state#ios#android
floow.design Team

floow.design Team

Mobile Design·

Empty state design turns each blank mobile screen into one clear next step: classify it as first-use, user-cleared, or error/no-results; state what is absent; and present exactly one primary action. Make the first-use state lead directly to the app’s core value, because it appears before any user-created content exists. For search, echo the submitted query and suggest a replacement query. Keep illustrations decorative and non-blocking so the primary action remains available during Android time-to-initial-display and iOS app launch.

Key takeaways

  • Use exactly three empty-state classes: first-use, user-cleared, and error or no-results.
  • Each empty state has exactly one primary action, sized at least 44 pt on iOS or 48 dp on Android.
  • A search no-results screen must echo the submitted query and offer one suggested next query.
  • Do not put a decorative illustration on Android’s time-to-initial-display path or iOS’s launch path.
  • WCAG 2.2 AA requires 4.5:1 contrast for normal-size text.

This guide is for mobile UI/UX designers, founders, and engineers who already ship iOS and Android screens with lists, search, and account data.

Time: 45 minutes · You'll need: A floow.design mobile screen or equivalent iOS and Android artboards, A list, search, or saved-items app flow with sample data, iOS Human Interface Guidelines and Material Design 3 references, A WCAG 2.2 contrast checker

What's on this page

  1. Classify every zero data state
  2. Make the first-use empty state an onboarding step
  3. Write the user-cleared app empty screen
  4. Handle search and failure states separately
  5. Compose one action without delaying the screen
  6. Test the three states on both platforms
  7. Reference table

Building empty state design, step by step

1. Classify every zero data state

Audit every mobile screen that can show a collection, search result, download, saved item, or account record. Assign each blank condition to one of three classes only:

  1. First-use: the person has never created, imported, or received this content.
  2. User-cleared: content existed, and the person removed it.
  3. Error or no-results: content may exist, but the app cannot currently show a matching or reachable result.

Put the class in the screen name, such as Saved trips / first-use or Search / no-results. Do not reuse one generic “Nothing here” layout for all three. A first-use screen needs a creation path, a user-cleared screen needs an intentional recovery or repeat path, and an error state needs a retry or correction path. This naming also gives QA three testable conditions per feature instead of one vague blank-state check.

Tip: Treat offline, permission-denied, and server-failure screens as error variants, not as first-use screens.

2. Make the first-use empty state an onboarding step

Design the first-use empty state as the first task in the product, not as an apology for missing data. Place a specific value statement above one primary action: for example, “Save routes for offline access” with Download a route, or “Your medication schedule appears here” with Add medication. The action must open the shortest path to the core object, not a settings screen or a help article.

This is the highest-leverage onboarding surface because it appears at the exact platform behaviour where a person reaches a feature before any personal content exists. It can explain the value at the moment of intent without inserting an extra onboarding carousel before the app’s home screen. Use one primary button with an iOS target of at least 44 × 44 pt or an Android target of at least 48 × 48 dp. Keep navigation available, but do not add a second competing CTA inside the empty state.

Tip: If importing data is the real first task, label the button “Import calendar” rather than the generic “Get started.”

3. Write the user-cleared app empty screen

Use a user-cleared state when the person deliberately deleted the last item, archive, saved search, or download. Confirm the resulting condition with language that reflects their action: “No saved articles” is clearer than “No articles found” after they remove a saved item. Pair it with exactly one primary action that matches the feature’s next useful cycle, such as Browse articles, Create a budget, or Download episode.

Do not show Restore, Browse, and Create as three equal buttons. If restoration is available, make it the one primary action only when the platform or product provides a real undo mechanism. On Android, a transient Snackbar action can expose an immediate undo after deletion; once that opportunity has passed, the empty state should return to one durable primary action. On iOS, avoid promising recovery unless the app can actually restore the removed object.

Tip: Use a different title for user-cleared content than first-use content, even when both lead to the same create flow.

4. Handle search and failure states separately

Build search no-results as a correction screen, not an error screen. Echo the exact submitted query in the title or supporting copy, such as No results for “wireless charger”. Then offer one suggested next query that the person can tap, such as Try “charging cable”. The suggested query must come from a known synonym, a spelling correction, a removed filter, or an available category; do not invent a recommendation with no matching catalog data.

Use an error state only when the app cannot complete the request because of a named condition, such as no network connection, a server failure, or denied permission. Its single primary action should match that condition: Retry for a failed request or Open Settings for an OS-controlled permission. Do not show Retry on a genuine zero-match search. A retry cannot change a valid query with zero matching records.

Tip: Keep the query visible after a no-results result so people can correct it without relying on memory.

5. Compose one action without delaying the screen

Arrange the empty state in this order: state title, one-sentence explanation, exactly one primary action, then an optional illustration. The illustration should soften the blank area, but it must not delay the button, title, or essential text. On Android, keep it off the startup critical path measured by time to initial display; on iOS, do not depend on it for the launch screen or the first actionable view.

Use a local vector or a small cached asset when the illustration is decorative. If it fails to load, the state must still communicate the absence and expose its action. Mark purely decorative images appropriately: Android views can use a null contentDescription, while iOS accessibility should not present a decorative element as a separate meaningful control. Check body text against WCAG 2.2 AA’s 4.5:1 minimum contrast ratio for normal text. The primary action remains understandable without color or artwork.

Tip: If an illustration pushes the button below the first viewport on a small phone, remove or shrink the illustration before reducing the action target.

6. Test the three states on both platforms

Create a test matrix with three rows for each feature: first-use, user-cleared, and error or no-results. For search, enter one known zero-match query and verify that the screen echoes that exact query and changes the suggested next query when the input changes. For a failed request, disable connectivity or use a controlled failure response, then confirm that the one primary action is Retry rather than a creation action.

Test the primary action at iOS 44 pt and Android 48 dp minimum target sizes, including when Dynamic Type or Android font scaling increases text height. Run VoiceOver and TalkBack with the illustration unavailable or treated as decorative; the title, explanation, and button must still make sense in that order. Finally, measure Android startup so an optional image does not postpone time to initial display. Record screenshots of all three conditions in the design handoff and QA acceptance criteria.

Tip: A screenshot set with populated, first-use, cleared, no-results, and error variants prevents engineers from treating blank content as an unhandled edge case.

Reference table

Rules for the three empty-state classes

State classPrimary actionsRequired signal
First-use1 actionName the first core task
User-cleared1 actionReflect intentional removal
Search no-results1 actionEcho query; suggest query

Common mistakes

Using “Nothing here yet” for first-use, deletion, failed loading, and zero-match search.

Use the three named classes. A failed request needs a recovery action, while a valid zero-match search needs query correction.

Showing Create, Import, Browse, and Learn more as equal buttons.

Choose exactly one primary action based on the current state. Keep explanatory links out of the primary-action hierarchy.

Hiding the searched text after a zero-results response.

Echo the submitted query verbatim and provide one tappable next query based on a synonym, spelling correction, filter, or category.

Making a remote illustration necessary to understand the screen.

Make the title, explanation, and primary action work before the image loads. Keep decorative media outside Android time-to-initial-display.

Frequently asked questions

What should an empty state include in a mobile app?

A mobile empty state should include a named absence, a short explanation, and exactly one primary action. Classify the condition as first-use, user-cleared, or error/no-results before writing the content. Size the action target to at least 44 pt on iOS or 48 dp on Android.

How do I design a search no-results empty state UI?

A search no-results empty state UI should echo the submitted query and offer one suggested next query. Write the query exactly as entered, such as “No results for ‘winter boots’,” then suggest a term supported by your catalog, synonym list, spelling correction, or active filters. Do not use Retry for a valid zero-match result.

Why is the first-use zero data state so important?

The first-use zero data state is important because it is the first in-context opportunity to direct a person to the feature’s core task. It appears before personal content exists, so a specific action such as Add medication or Import calendar can replace a separate instructional screen. Keep that state to one primary action.

Should an app empty screen use an illustration?

An app empty screen can use an illustration when the screen remains understandable and actionable without it. Keep the image decorative, local or cached where possible, and outside Android’s time-to-initial-display path. Do not let artwork move the primary button below the first viewport or reduce text below WCAG 2.2 AA contrast requirements.

Where this leaves you

A blank collection is not one design state. It is one of three conditions with different evidence, language, and recovery paths: first-use, user-cleared, or error/no-results. The common rule is tighter: every state exposes exactly one primary action sized for the platform, while its text explains why that action is relevant now. Search requires the extra discipline of retaining the query and proposing a credible next query. Start with one high-traffic mobile feature today, create its three state variants, and add them to the same review flow as its populated screen.

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

Related

Sources

Design your mobile app with AI

Generate pixel-perfect iOS & Android screens in seconds. Export to Figma and ship faster.