Practical guide

Design the screens between the happy paths

Make empty, loading and failed states useful parts of the application.

Last materially reviewed 2026-09-18

Quick answerExplain what is happening and which action is available without making missing data look like success.
What to know

Start with a genuinely empty account

A new user may have no records, while a demonstration is usually filled with attractive sample content. Decide what the empty page should explain and how the user begins the first task. Do not display fake completed activity as if it belonged to the account. If examples are helpful, label them and keep them separate from real records so an export or report cannot quietly mix the two.

What to know

Show loading without disrupting the task

When a request is pending, preserve stable labels and the user’s current position where possible. Avoid repeatedly rebuilding the page in a way that closes expanded details or moves keyboard focus. State what is being loaded when that information is useful. Do not show a zero total while the actual total is still unknown; zero and unavailable are different pieces of information.

What to know

Diagnose denied and failed states separately

A permission problem, expired session and temporary server failure need different recovery paths. Explain whether signing in again restores access or whether a feature is unavailable for the account. Do not suggest that retrying will create a permission the user lacks. Keep private information from remaining visible after access is lost. Test those transitions with fixed local responses before relying on a live service.

What to know

Verify the complete state sequence

Walk through new account, first submission, pending result, success, interruption and return. Check that the original record or request remains identifiable throughout. Test the page with keyboard navigation and enlarged text, including long error messages. A state diagram and a few fictional examples can make the brief more precise. This is original interface guidance, not a statement that any particular generated Overskill app has passed these tests.

Continue when useful

Next: Make a generated app usable without a mouse

Check keyboard paths, readable text and clear form feedback before wider use.

Open Make a generated app usable without a mouse →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. MDN accessibility introduction — Reference · developer.mozilla.org · Publisher independence not verified · checked 2026-09-18
  2. Overskill API error guidance — Merchant documentation · overskill.com · Merchant-controlled · checked 2026-09-18