6 exercises — read and write clear Figma handoff annotations: spacing, fixed/fill/hug sizing, constraints, breakpoints, and layer naming conventions.
0 / 6 completed
1 / 6
Read the developer handoff annotation and choose what it tells the engineer:
"Icon: 20×20px, 8px spacing from label. Auto layout, gap: 8."
Spacing annotation — this note gives the engineer two precise, unambiguous values: the icon's fixed dimensions (20×20px) and the exact spacing between icon and label (8px), implemented via Figma's auto-layout gap property rather than manual margins.
Core spacing vocabulary: • Padding — space inside a container, between its edge and its content • Margin — space outside an element, separating it from its neighbours (less common in auto-layout-based Figma files, which prefer gap) • Gap — the fixed spacing auto-layout inserts between children automatically • Spacing scale — a constrained set of allowed values, usually a 4px or 8px base: 4, 8, 12, 16, 24, 32, 48, 64. Designers should always pick from the scale, not arbitrary numbers like "13px", so spacing stays consistent
When you read "gap: 8" in a handoff note, it means: don't manually position the icon with a margin — the parent frame's auto-layout will always keep exactly 8px between icon and label, even if the label text changes length.
2 / 6
A developer reads this annotation on a card component: "Width: Fill container. Height: Hug contents." What layout behaviour does this describe?
Constraint / sizing vocabulary — these three terms describe how a frame resizes relative to its content and parent, and map directly to CSS concepts:
• Fixed width/height — the dimension never changes, regardless of content or parent size (like CSS width: 320px) • Fill container — the element stretches to take up all available space in its parent (like CSS width: 100% or flex: 1) • Hug contents — the element shrinks or grows to exactly match the size of what's inside it (like CSS width: fit-content or a block with no explicit height)
So "Width: Fill container, Height: Hug contents" describes a very common responsive card pattern: the card is always as wide as its column, but only as tall as it needs to be — if the description text is longer, the card grows taller automatically, without any developer intervention.
These three words — fixed / fill / hug — are the standard Figma-to-code vocabulary bridge for describing intended resizing behaviour without writing CSS directly in the design tool.
3 / 6
What does this responsive annotation communicate to a developer?
"On mobile, the layout switches from 2 columns to 1 column at 768px."
Breakpoint annotation — this is the standard way to communicate responsive behaviour from design to development: name the breakpoint value and describe what changes on each side of it.
Reading breakpoint notes: • "switches at 768px" — 768px is the threshold; developers implement this with a media query, e.g. @media (max-width: 768px) { ... } • Good annotations specify direction clearly: "above 768px = 2 columns" vs. "at/below 768px = 1 column" — ambiguity here (is 768px itself 1 or 2 columns?) causes real bugs, so precise designers say "below 768px" or give the exact CSS operator intended (max-width vs. min-width)
Common breakpoint vocabulary in handoff notes: • Mobile-first — base styles target mobile; larger breakpoints add complexity via min-width • Desktop-first — base styles target desktop; smaller breakpoints override via max-width • Standard breakpoint names — mobile (~375–428px), tablet (~768px), desktop (~1024px+), wide (~1440px+) — exact pixel values vary by design system
Always annotate the exact pixel value and which side of it each layout applies to — "it switches around tablet size" is not developer-ready.
4 / 6
You need to write a developer handoff note for a button that has fixed 44px height, 16px horizontal padding, and should not shrink below its content width. Which annotation is most complete and unambiguous?
Writing a good handoff annotation means stating exact, unambiguous values for every dimension a developer needs, using the fixed/fill/hug vocabulary plus explicit numbers — never vague language like "about" or "roughly."
A complete annotation answers: • What is the exact value? (44px, not "medium") • Is it fixed or does it respond to content/container? (fixed height, hug-content width) • What happens at the boundary? ("does not shrink below content size" prevents the button from clipping its own label text)
Layer naming conventions also matter for handoff quality: • Name layers by role, not appearance: Button/Primary/Default rather than Rectangle 47 • Group related layers logically so the layer panel mirrors the component's actual structure • Add a component description in Figma's properties panel explaining intended usage, e.g. "Use for the single primary action per screen; do not use two primary buttons in the same view"
Precise, numeric, unambiguous annotations eliminate the most common cause of design-to-development friction: developers guessing at values the designer never wrote down.
5 / 6
A component description in Figma's Dev Mode reads: "Constraints: Left & Right (scale). Do not detach — update via the component library." What is the engineer being told?
Constraints + "do not detach" — two distinct pieces of information in one note:
• Constraints: Left & Right (scale) — describes horizontal resizing behaviour: as the parent frame resizes, both the left and right edges of this layer move proportionally, so the element stretches or shrinks with the parent (common for full-width banners or backgrounds). Other constraint values: Left (stays a fixed distance from the left edge only), Center (stays centered), Scale (resizes proportionally in both dimensions) • "Do not detach" — an instruction about the component library relationship: a Figma instance stays linked to its main component so that future updates to the main component propagate everywhere it's used. "Detaching" breaks that link, creating an orphaned copy that won't receive updates
For developers, "do not detach — update via the component library" is the design equivalent of "don't fork this shared UI component in code — extend the shared one," preserving a single source of truth across the whole product.
6 / 6
Which layer naming convention gives a developer the clearest information when browsing Figma's layer panel or Dev Mode?
Layer naming conventions — clear names are one of the highest-leverage habits for a smooth handoff, because they appear directly in Figma's Dev Mode inspector, generated code comments, and CSS class suggestions.
Good naming pattern: Category/Variant/State, e.g. Button/Primary/Hover, Card/Product/Default, Icon/Chevron/Right. This mirrors how components are organized in a design system and how they will likely be named in code (component name + variant prop + state).
Default Figma names like Rectangle 22 or Group 14 tell a developer nothing about the element's purpose, and force them to click through the design to figure out what maps to what — wasted time multiplied across every handoff.
Additional handoff-quality habits: • Add descriptions to components explaining intended use and any "do / don't" rules • Keep the layer tree flat where possible — deeply nested groups slow down Dev Mode inspection • Delete or hide unused/experimental layers before sending a file to development; stray hidden layers cause confusion when someone toggles visibility
What will I practice in "Figma Annotation Language — Product Design Exercises"?
This is a Product Design exercise set. It walks through 6 scenario-based multiple-choice questions built around real usage of product design terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 6 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the product design vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Product Design exercises?
See the Product Design exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — product design vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.