Design Empty and Error States in Figma
Design empty states and error states separately: one explains an absence of content, while the other explains a failed or blocked operation. Both need a reason, a useful next action and a clear relationship to the rest of the flow.
Before you start: Have the core flow and a list of data and permission conditions. Use existing components where possible and ask engineering which failures can be identified reliably.
Worked example: A project list can be empty because a workspace is new, a filter matches nothing or access was removed. Those cases should not all tell the user to create a new project.
Step-by-step guide
Inventory absence and failure
List the causes behind a blank area or unsuccessful action. Separate first use, no search results, access limits and service failures before drafting screen copy.
Define the next action
Choose a safe action for each cause. Resetting a filter, inviting an owner and retrying a request solve different problems; the primary button must reflect the actual cause.
Draw the relevant states
Use separate frames or supported component states to show the difference. Keep hierarchy and layout consistent enough that recovery does not feel like an unrelated page.
Write specific copy
Explain what happened in ordinary language without exposing technical internals. State whether work was saved and what the user can do next if that affects recovery.
Connect recovery paths
Show what retry, cancel or reset does in the prototype. Include an unsuccessful retry when repeated failure requires a different path rather than an endless loop.
Review with engineering
Check which error types and permission changes the system can detect. Turn each state into an acceptance check with a trigger and a visible result.
Common mistakes
One empty screen for every cause
A no-results search should not offer the same action as a new workspace. Match the action to the absence.
Retry with no outcome
A button without a defined transition leaves implementation ambiguous. Specify success, repeat failure and retained input.
Blaming the user
Messages should explain the condition and recovery without assuming the person caused it.
Tips
Use realistic failure copy instead of lorem ipsum.
Specify whether typed input survives an unsuccessful submission.
Include a safe way to leave a blocked flow.
Sources and verification
Based on product documentation checked on 2026-10-24. This is a documentation-based guide, not a hands-on benchmark. Features and availability can change.