TL;DR
Edge states represent sixty percent of implementation work but receive less than ten percent of wireframe attention. This guide provides a systematic approach to identifying edge states for every screen type, documenting them efficiently in wireframes, and prioritizing which states require full wireframe treatment versus annotation-only documentation.
What Are Edge States in Wireframing
Edge states are the conditions your interface must handle when things deviate from the ideal scenario. The "happy path" shows a user with good data, working connections, and sufficient permissions completing their task successfully. Edge states cover everything else: no data available, data loading, data failing to load, the user lacking permission, input being invalid, sessions expiring, and dozens of other conditions that the product must handle gracefully.
Most wireframes only show the happy path. This creates a systematic gap between what has been designed and what needs to be built. Engineers encounter edge states during implementation, realize they have no specification for how to handle them, and either make independent design decisions, which risks misalignment, or interrupt the designer with questions, which slows both teams down.
The Edge State Taxonomy
Empty States
Empty states occur when a screen has no data to display. Every list, table, dashboard widget, feed, and search result page needs an empty state definition. The empty state should answer three questions: why is there no data, when will data appear, and what action can the user take to populate the view.
For new user accounts, the empty state serves as an onboarding moment. A dashboard widget for a new user should not show a blank canvas or a generic "no data" message. It should explain what data will appear here, guide the user toward the action that will generate data, and show a preview or example of what the populated state will look like.
For filtered results that return nothing, the empty state should explain that the current filters produced no matches and suggest ways to broaden the filters. This is different from a global empty state because the system has data, but the user's filter combination excludes all of it.
For deleted or archived content, the empty state should acknowledge that content existed previously and provide a path to view archived items or create new ones.
Loading States
Loading states occur during data fetching and processing operations. The wireframe should specify the loading treatment for each asynchronous operation.
Skeleton screens show a structural placeholder that previews the layout of the incoming content. Use skeleton screens when the content layout is predictable and the loading time is one to three seconds. Skeleton screens reduce perceived wait time because users can see the page structure assembling, which feels faster than watching a spinner.
Inline spinners show a small loading indicator within a specific section while the rest of the page remains interactive. Use inline spinners for partial page updates where only one section is loading while others display their data normally.
Full-page loading shows a centered loading indicator that prevents interaction with the page. Use full-page loading only when the entire page must load before any interaction is meaningful, such as an authentication check or initial data hydration.
Progress indicators show completion percentage or step progress for operations that take longer than five seconds. Use progress indicators for file uploads, data processing, and bulk operations where the user needs to know the operation is progressing and approximately how long it will take.
Error States
Error states occur when operations fail. Every API call, form submission, data processing operation, and external service integration can fail, and each failure needs a planned response.
Recoverable errors are failures the user can resolve by trying again or adjusting their input. The error message should explain what went wrong in plain language, suggest what the user can do to resolve it, and provide a clear action such as a retry button or a link to edit their input. Never use technical error codes as user-facing messages because they provide no actionable guidance.
Non-recoverable errors are failures that require external intervention such as contacting support or waiting for a system recovery. The error message should acknowledge the problem, set expectations about resolution timeline if possible, and provide contact information or a link to a status page.
Partial errors occur when some parts of a page load successfully while others fail. Document whether the successful sections remain visible and interactive or whether the entire page shows an error state. The recommended approach is to show successful sections normally and display inline error messages for failed sections, allowing users to interact with the available content while failed sections retry automatically.
Permission States
Permission states occur when users attempt actions they are not authorized to perform. Document three possible treatments for each restricted action.
Hidden means the restricted element is not rendered at all. The user never knows the capability exists. This approach is appropriate for features that are irrelevant to the user's role.
Disabled means the element is visible but not interactive, with a tooltip or label explaining why it is restricted. This approach is appropriate when the user should know the capability exists but understand they cannot use it with their current role or plan level.
Upgrade prompt means the element is visible and interactive, but clicking it triggers an upgrade flow rather than the normal action. This approach is appropriate for plan-gated features where you want to encourage users to upgrade by demonstrating the value of higher-tier capabilities.
Boundary States
Boundary states occur when data reaches its limits. Document what happens at maximum capacity for lists and tables, such as pagination behavior when there are thousands of items. Document what happens when text content exceeds the available display space, including truncation rules and "show more" interactions. Document what happens when numerical values reach extreme ranges, both very large numbers that may not fit in their display container and zero or negative values that may need special formatting. And document what happens when time-based content becomes stale, including whether old items are archived, hidden, or marked with a staleness indicator.
The Edge State Audit Process
Step 1: Screen Inventory
List every screen in your wireframe flow. For each screen, identify every dynamic element: data displays, interactive controls, form fields, navigation elements, and status indicators.
Step 2: State Generation
For each dynamic element, ask these five questions. What does this element show when there is no data? What does this element show while data is loading? What does this element show when data fails to load? What does this element show when the user lacks permission? And what does this element show at extreme data values?
Step 3: Priority Classification
Not every edge state deserves a full wireframe treatment. Classify each identified state into three priority tiers.
Must wireframe states include empty states for primary screens, error states for critical operations like payment and account actions, and permission states that affect core user tasks. These states need full wireframe attention with complete layout documentation.
Annotation-only states include loading states that use standard patterns such as skeleton screens defined once and referenced throughout, boundary states for non-critical elements, and error states for secondary operations. These states need text documentation but not visual wireframes.
Defer states include edge cases that affect less than one percent of users, states related to features planned for future releases, and extreme boundary conditions that can be addressed during implementation. These states are documented in a list for future reference but receive no wireframe or annotation treatment now.
Step 4: Documentation
For must-wireframe states, create a separate wireframe view showing the full screen with the edge state active. For annotation-only states, add detailed text annotations to the primary wireframe view describing the expected behavior. For deferred states, maintain a running list in the project documentation.
Edge State Documentation Patterns
The State Matrix
For complex screens with many edge states, create a state matrix that cross-references elements with state types. The rows are UI elements and the columns are state types such as empty, loading, error, permission, and boundary. Each cell contains either a wireframe reference, an annotation note, or a "deferred" marker. This matrix provides a comprehensive inventory that ensures nothing is overlooked and gives engineering a structured reference during implementation.
The State Flow Diagram
For flows where edge states create branching paths, such as a payment flow where different error types lead to different recovery flows, document the branching logic as a simple flow diagram alongside the wireframes. This diagram shows which edge states lead to which recovery paths and ensures that the engineer implements the correct branching logic.
Performance-Related Edge States
Performance edge states are conditions caused by slow network connections, large data sets, or resource-intensive operations. These states are frequently overlooked because they rarely occur during development on fast machines with small test data sets, but they significantly affect real-world user experience.
Slow Connection States
Document what happens when data takes longer than expected to load. The wireframe should specify timeout thresholds for each data request, what the user sees when the threshold is exceeded such as a retry option or a cached data fallback, and whether the user can continue interacting with other parts of the interface while the slow request completes.
Large Data Set States
Document what happens when lists, tables, or data visualizations contain thousands of items. Specify the pagination or infinite scroll behavior, including how many items load initially, how many load on each subsequent page or scroll event, and what visual indicator communicates that more items are available. For charts with thousands of data points, document whether the data is aggregated, sampled, or displayed in full, and how the aggregation affects the accuracy of the visualization.
Offline States
For applications that need to function without a network connection, document which features work offline, how data entered offline is synchronized when connectivity returns, and what visual treatment communicates the offline state to the user. The offline indicator should be prominent enough to prevent users from submitting data they expect to be processed immediately.
FAQ
How many edge states should a typical wireframe document?
A well-documented wireframe for a five to seven screen flow typically has fifteen to twenty-five documented edge states across all screens. This number increases significantly for data-heavy screens like dashboards and decreases for simple informational screens. The goal is comprehensive coverage of states that affect user experience, not exhaustive coverage of every theoretical possibility. Focus your effort on states that users will encounter frequently and states where poor handling creates significant frustration.
Should edge states be reviewed during wireframe reviews?
Yes. Include edge state coverage as an explicit review criterion. The review rubric should assess whether the wireframe documents edge states for all critical user paths. Missing edge states discovered during review are far cheaper to document than edge states discovered during implementation. Request that engineering reviewers specifically check for states they have encountered in previous projects that designers commonly overlook.
Can edge states be standardized across a product?
Yes, and they should be. Create a product-level edge state style guide that defines standard visual treatments for empty, loading, error, and permission states. Reference this style guide in wireframes rather than re-specifying standard treatments for every screen. This approach reduces documentation effort and ensures consistency across the product interface. Standard treatments should cover the visual design, copy patterns, and interaction behavior for each state type, allowing individual wireframes to reference the standard with only the content-specific details documented inline.