Specify Loading States in Figma
Specify what the interface does while work is pending, including which controls remain available and what happens when the operation finishes or fails. The design should communicate progress without claiming completion before the system confirms it.
Before you start: Have the core action, success and error outcomes, and engineering input on the request lifecycle. Agree which loading behavior is illustrative rather than a promise about response time.
Worked example: When a user saves a project, preserve the entered name, prevent accidental repeat submission and show a recoverable error if saving fails. A spinner alone does not explain those rules.
Step-by-step guide
Identify pending operations
List which actions wait on a request or background task. Separate initial page loading from a button submission and a longer-running operation because each needs different user feedback.
Choose the loading presentation
Draw an appropriate pending state using the existing design system. Explain why a skeleton, progress message or button state fits the task instead of using the same treatment everywhere.
Define interaction rules
Specify what can be clicked, cancelled or edited while work is pending. Decide whether repeated actions are blocked and whether navigating away is safe.
Connect the outcomes
Show the transition to success, failure and any retry path. Include what happens to entered data so developers do not have to infer whether to clear the form.
Review accessibility and timing
Describe the status message and any focus change the application should provide. Keep illustrative delays separate from actual timeouts or performance requirements agreed with engineering.
Test the complete sequence
Walk the save example with both a quick and a slow response. Check that feedback appears at the right moment and that failure never looks like successful completion.
Common mistakes
Pending looks like success
A confirmation message before persistence can mislead users. Reserve success feedback for confirmed completion.
Disabled controls without explanation
Users may not know why an action stopped responding. Pair the pending state with understandable status feedback.
Discarding input after failure
A failed request should not silently erase work. Specify what remains and how retry works.
Tips
List the pending operation beside its success and failure outcomes.
Keep cancellation separate from an unsuccessful request.
Check status announcements with an accessibility reviewer.
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.