Your mission objective
Know what “cleared” looks like before opening Figma.
By the end, you can…
- Build navigation, overlays, and back paths.
- Use interactive component variants.
- Design a modal's focus and Escape behaviour, not just its visuals.
- Document responsive, motion, and screen-reader intent for handoff.
Bring with you
- Responsive dashboard screens
- Button and form components
Decode the system
Understand the production logic before following steps.
A prototype should answer interaction questions, not merely connect every frame. Start with the critical path, then add cancellation, validation, and recovery. For this project, the path runs from dashboard to workload detail, recovery setup, review, confirmation, progress, and success. Each transition should clarify what the user expects next.
Interactive components are useful for local state such as hover, press, toggle, and disabled feedback. They reduce duplicated product frames and keep state logic near the component. Overlays fit confirmation and focused tasks, but they need reliable close, cancel, and keyboard expectations: focus should move into the overlay when it opens, Escape should close it exactly like the visible cancel control, and focus should return to the control that opened it.
Figma's own accessible-prototype mode lets a screen reader (VoiceOver, JAWS, NVDA) navigate your frames on desktop — it does not work on mobile or mobile-web prototypes, and it does not prove your eventual production build will be accessible. Treat it as one more stress test, the same way you'd treat a narrow viewport: useful for catching an obviously wrong reading order or an unlabelled control, not a substitute for real accessibility work in the built product.
Handoff communicates more than pixel values. Frame names, semantic variables, component properties, responsive annotations, empty-state behaviour, motion intent, and interaction notes explain the system behind the screens. Write down what a screen reader should announce for anything non-obvious, and note where a transition should respect a learner's reduced-motion preference instead of assuming animation is always welcome. Dev Mode availability may depend on a paid Figma seat, so the underlying discipline must remain understandable through ordinary inspection and written annotations.
The action that begins a transition.
The visible response: hover, error, progress, or success.
Cancel, back, close, Escape, and focus-return paths.
Named intent, tokens, behaviour, motion, and screen-reader notes.
Prototype the recovery workflow
Follow once, then explain each structural choice.
- 01
Connect dashboard to workload details.
- 02
Open recovery configuration from the primary action.
- 03
Add target selection and a validation error state.
- 04
Connect review to a confirmation overlay with cancel and close paths — note where focus should land when it opens and where it should return on close.
- 05
Create progress and success frames with meaningful status copy.
- 06
Use interactive button variants for hover, pressed, and disabled states.
- 07
Turn on accessible-prototype mode and tab through the critical path once, then annotate breakpoints, motion intent, screen-reader notes, and any exceptional behaviour.
Cloud Recovery Operations Platform
Build this fictional SaaS project in your own Figma file. No proprietary source file or private embed is required.
Framewise doesn’t yet have a duplicable starter file or a completed reference outcome for this mission — that’s on the roadmap, not something we’re pretending exists. The link below opens a genuinely blank Figma file, not a prepared course file.
Create a new Figma file ↗Try to break the build
A layout is not responsive until real variation tries to break it.
Cancel from confirmation.
Submit without a target.
Return from review and preserve the choice.
Try the flow with keyboard-only assumptions.
Run the accessible-prototype screen-reader check on the critical path and note anything unlabelled or out of order.
Build without the guide
Remove tutorial dependence and work from the outcome.
Build one interactive control with Default, Hover, Pressed, and Disabled states without duplicating full product screens.
Check your understanding
Five fast retrieval rounds. Land 80% to clear the checkpoint.
Pass criteria
Self-certify observable results, not effort.
Lock in the learning
Write two short answers in your own notes.
- 01
Where can the user safely change their mind?
- 02
Which behaviour would a static screen fail to communicate?
Ready to claim the reward?
Score 80% in the mission quiz and check off all 5 build criteria to claim the reward.