Your Error States Are the Most Honest Part of Your Product

Error states are where product assumptions stop being theoretical.

A clean dashboard, a polished onboarding flow, and a fast green checkmark all say the same comforting thing: the ideal path works. But the empty state, the failed request, the timeout, and the retry button answer a harder question: does the team understand what the user is actually trying to do?

If the answer is no, the interface usually reveals it immediately.

Empty States Are Not Decorative

An empty state is not a blank canvas for illustration-first design. It is a product statement about absence. Material Design describes empty states as the moments when content cannot be shown and says they should prevent user confusion; its examples pair a subtle image with a short tagline, not a visual flourish with no operational meaning. (Material Design: Empty states)

That matters because a truly useful empty state answers at least one of these questions:

• why is this empty
• is this expected
• what should I do next
• what can I do right now

If the answer is only "nothing here yet," the design has not helped the user understand the product. It has merely described a condition the user already noticed.

Good empty states are specific. They distinguish between:

• a new workspace with no data
• a filtered view with no matches
• a permissions issue that hides content
• a sync problem that has not finished resolving

Those are different user situations, and they deserve different explanations. When teams collapse them into one generic empty panel, they are usually revealing that they have not modeled the user's intent very well.

Failed States Reveal Whether The Product Can Continue

A failure state is not just an error message. It is the point where the product either preserves momentum or abandons it.

WCAG's guidance on error identification is blunt about the baseline: if an input error is automatically detected, the item in error must be identified and the error must be described in text. Re-displaying a form without saying what failed is not enough. (W3C: Error Identification)

Government design guidance pushes the same idea into practice. The Home Office manual says error messages should be written in clear language and explain what went wrong and how to fix it; the GOV.UK Design System recommends error messages that point to the problem directly, not a vague warning that leaves the user to diagnose the issue alone. (Home Office: Error messages, GOV.UK Design System: Error message)

That is the real test:

• does the user know what failed
• can they still continue
• do they lose the work they already entered
• is the failure local, or does it collapse the whole screen

Teams that understand users usually preserve as much of the interface as possible. Teams that do not often choose the easiest implementation: clear the view, show a toast, and hope the user starts over.

Timeouts Are A Respect Problem

A timeout is not just a technical event. It is a moment when the product asks the user to wait without giving a convincing explanation of why.

That is why the best guidance on slow or interrupted states focuses on clarity, continuity, and state preservation. web.dev's offline UX guidance recommends telling the user what state their data is in, using multiple cues instead of color alone, and showing skeletons or preloader UI so the interface still feels present. (web.dev: Offline UX design guidelines)

Apple's Human Interface Guidelines make a related point for network problems: if an app detects a startup connection issue, consider showing cached or placeholder data with a nonintrusive label instead of interrupting the user with a blunt alert. (Apple: Alerts)

Those recommendations share a common principle. A timeout should not erase context.

Good timeout behavior usually includes:

• preserving typed input
• keeping previous results visible when they are still useful
• marking content as stale or refreshing
• making it obvious whether the user should wait, retry, or edit the request

When a timeout wipes the form or resets the page, the UI is telling you that the implementation mattered more than the user's time.

Retry Reveals Whether The Team Understood Risk

A retry button is only useful if the team knows what kind of failure just happened.

Material Design treats app errors, sync errors, connectivity failures, and incompatible state errors as different patterns. It also emphasizes that retry actions should come with clear communication and that user-entered input should be preserved wherever possible. (Material Design: Errors)

That distinction matters because not every failure should be handled the same way:

• a transient read failure can often be retried safely
• an interrupted upload may need a resume path
• a payment submission may need stronger confirmation
• a destructive action should not be blindly replayed

The retry control itself is not the product. The policy behind it is.

A good team can answer:

• is retry safe or dangerous
• is it automatic, manual, or both
• does it repeat the exact same request
• does it reuse the same state, or start from scratch

If the UI says "Try again" but nothing about the request changes, the product is not offering recovery. It is offering superstition.

The Honest Question To Ask

The fastest way to evaluate an error state is to ask what it assumes about the user.

If the design assumes the user came back later, the empty state should explain what would make the page useful. If the design assumes the user is mid-task, the failure state should protect progress. If the design assumes the network is unreliable, the timeout state should preserve context and explain the next move. If the design assumes retry is harmless, the control should make that safety explicit.

That is why error states are so revealing. They expose whether the team designed for a generic visitor or for a real person trying to finish a real task under imperfect conditions.

A Short Review Checklist

Use these questions when reviewing empty, failed, and retry states:

• what does this state tell the user that they do not already know
• does it explain why the content is empty or missing
• does it preserve work, selections, and prior results
• is there a specific next action that fits the failure
• would the message still make sense if the user were stressed, distracted, or on a bad connection

If the answer to most of those questions is no, the product is not being honest with the user.

Bottom Line

Empty states, failed states, timeouts, and retries are not edge cases. They are the clearest evidence of whether a team has actually thought through the user's intent, the product's failure modes, and the cost of making people start over.

The happy path can hide a lot of confusion. Error states cannot.

Sources

• W3C: Error Identification
• Home Office: Error messages
• Material Design: Errors