Milestone map
Milestone map
3 milestones
Master auto-layout, component variants, and design system primitives
5 weeks
Develop command of Figma's three most important professional-level features: auto-layout (nested, with fixed and hug sizing on both axes), component variants (creating a component set with multiple properties — state, size, colour), and a design system foundation (a type scale, colour styles, and at least 10 components using both features). Build a mini UI kit demonstrating all three working together on a real design problem, not toy examples.
Proof required
Figma file link showing a mini UI kit with a documented type scale, colour styles, and at least 10 components using auto-layout and variants — annotated to show which property each auto-layout and variant configuration controls.
What gets checked
- Auto-layout used correctly for at least 5 components (not frames that are manually positioned)
- At least one component set has ≥3 variant properties (e.g. state, size, type)
- Type scale and colour styles are defined as Figma styles and used consistently — not repeated local values
Common mistakes
- Using frames without auto-layout and manually adjusting spacing — this is the most common indicator of non-production-level Figma proficiency and the first thing a developer reviewer notices
- Creating variants by duplicating components manually rather than using the Figma variants panel — duplication makes the component set unmaintainable
- Defining colours as fills rather than colour styles — local fills do not update globally when the design system colour changes
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Open the Figma file and resize a frame — confirm auto-layout components stretch or hug correctly rather than breaking
- Check that changing a variant property updates correctly without detaching the component
- Confirm colour styles exist in the file's Styles panel (not just local fills)
You'll sign in first, then come straight back here.
Build a complete product design using the design system
6 weeks
Use the design system from M1 to build a complete multi-screen product design — an app or website covering at least four distinct screens. Every component used must come from the design system: no one-off custom frames. Include a realistic information architecture and at least one interactive prototype connection showing how a key user flow works (e.g. button press to next screen). The design must be self-consistent: spacing, type, and colour follow the system throughout.
Proof required
Figma file link with at least four screens built exclusively from design system components, plus a Figma prototype link showing at least one interactive user flow with a working transition.
What gets checked
- All four screens use only components from the M1 design system — no orphaned one-off frames
- Prototype link demonstrates at least one end-to-end user flow
- Spacing, type, and colour are consistent across all screens (no local overrides that deviate from the system)
Common mistakes
- Building screens that look consistent because they were designed manually rather than using the system — this falls apart the moment the system needs to change
- Making a prototype with non-interactive screens connected by invisible hotspots — real prototype quality means the interactions show meaningful state changes
- Designing only one or two screens and calling them 'complete' — a product design must show enough coverage to evaluate the information architecture
Powstik Guide
Four screens built only from system components, prototyped.
Steps
- Use only components from your system.
- Build four connected screens.
- Wire a clickable prototype.
- Share view links to both.
Template
File link: Prototype link: Screens: Components used:
What gets sent back
- Detached or one-off components.
- Fewer than four screens.
- No prototype.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Open the Figma file and check at least 3 components used in the screens — confirm they are from the design system (not local detached copies)
- Run the prototype flow — confirm the interaction transitions and that screens look correct in presentation mode
- Spot-check one spacing value across two different screens — confirm both use the same value from the design system
You'll sign in first, then come straight back here.
Produce a handoff-ready file and present to a developer or designer
2 weeks
Prepare the file for developer handoff: export specifications for key components (padding, spacing, type styles), annotate the prototype flow, and add a file cover page documenting the design system basics and how to use the file. Then present the design to a developer or experienced UI designer for a live Q&A — the reviewer must be able to ask 'what were you thinking here?' about any screen and receive a specific answer. Document the session and any issues raised.
Proof required
Figma file with a cover page documenting the design system and exported component specs, plus Q&A notes (200+ words) from the developer or designer review recording specific questions and your responses.
What gets checked
- File has a cover page and the design system is documented in the file
- Reviewer is a developer or experienced UI designer (not a general stakeholder)
- Q&A notes record at least three specific design decision challenges and responses
Common mistakes
- Presenting the file without a clear structure guide — developers who cannot find components or understand the file organisation cannot use the handoff
- Asking for review from someone who will not challenge design decisions — the Q&A purpose is to test reasoning, not collect praise
- Not updating the file based on feedback — failing to act on specific reviewer points signals the review was performative
Powstik Guide
A handoff-ready Figma file, reviewed by a developer or designer.
Steps
- Add a cover page listing styles and components.
- Annotate spacing and type on key components.
- Label each prototype flow.
- Walk a reviewer through it and log their questions.
Template
File link: Cover page includes: styles ☐ components ☐ flows ☐ Reviewer name and role: Questions they asked: 1. 2. What I changed after review:
What gets sent back
- No cover page.
- Specs missing on key components.
- Review notes under 200 words.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm the reviewer is a developer or experienced UI designer — ask for their professional background
- Review Q&A notes for substantive design challenges — not just 'looks great'
- Open the Figma file and confirm a cover page exists with the design system documented
You'll sign in first, then come straight back here.
Part of