6 exercises — read and write clear Figma handoff annotations: spacing, fixed/fill/hug sizing, constraints, breakpoints, and layer naming conventions.
0 / 19 completed
1 / 19
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 / 19
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 / 19
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 / 19
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 / 19
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 / 19
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
7 / 19
You're reviewing a PR for a new UI component. A teammate leaves this comment:
`Annotation: fill-parent width, margin: 16px`
What does this annotation primarily instruct the designer to do regarding the component's layout?
The `fill-parent` annotation specifies that the component should take up the full available width of its parent. A margin indicates space around an element. The other options describe incorrect or less relevant behaviors for a Figma annotation. This is a standard UI design constraint.
8 / 19
A designer creates a component in Figma and adds this annotation: `Auto Layout: Horizontal, Padding: 24px`. What is the primary effect of these settings?
`Auto Layout: Horizontal` dictates that the component's children are arranged horizontally. `Padding: 24px` adds spacing around each child within that horizontal arrangement. This is a fundamental aspect of responsive design using Figma annotations.
9 / 19
A product designer is describing the behavior of a component to a developer. They use this annotation: `On iOS devices, the component's height should be dynamic and adapt to its content`. What is the most accurate interpretation of this instruction?
This annotation describes a responsive behavior. On iOS devices, Figma annotations can dynamically adjust the component's height to accommodate its content—a key aspect of adapting designs to different screen sizes and resolutions. The other options describe fixed or incorrect behaviors.
10 / 19
A developer is tasked with implementing a design handoff for a form input field. The designer provides the following annotation: `Border Radius: 8px`. What does this annotation request?
`Border Radius: 8px` is a common design annotation that specifies rounded corners for an element. The `8px` value defines the radius of those curves—a frequently used aesthetic choice in user interface design. This directly influences the visual appearance of the input field.
11 / 19
Sarah (Product Designer) sent this annotation to the development team for a new navigation bar component:
"Annotation: `Width: Fill container. Height: Hug contents.` What is the primary goal of these settings in Figma?
These settings instruct the developer to create a responsive layout. `Fill container` means the navbar will take up all available horizontal space, while `Hug contents` ensures it scales vertically to fit its content. The common misconception is that 'Hug contents' forces a specific aspect ratio; instead, it adapts proportionally.
12 / 19
Mark (Developer) needs to understand the annotation for a modal window:
"Annotation: `Position: Center`. What does this annotation primarily communicate to the developer?
The `Position: Center` annotation tells the developer that Figma will automatically center the modal's content within its parent container. This is a common technique for creating visually balanced layouts. Options A, C and D are incorrect because they describe fixed positioning or specific percentage-based distributions.
13 / 19
David (Lead Engineer) is reviewing a PR that includes this annotation for a card component:
"Annotation: `Shadow: Box shadow with blur radius 8px and spread radius 0`. What effect will this annotation have on the card's appearance?
This annotation defines a box-shadow effect. The `blur radius` controls the softness of the shadow, while the `spread radius` determines how far the shadow extends from the element. A blur radius of 8px creates a typical soft shadow effect that is commonly used in UI design to add depth and visual separation.
14 / 19
Emily (UI Designer) has created this annotation for a form input field:
"Annotation: `Input Type: Email`. What does this annotation instruct the developer to do?
The `Input Type: Email` annotation specifies that this input field should behave like an email address field. This triggers browser-level validation and provides features like autocomplete and keyboard type optimization for email addresses. This is crucial for usability and data integrity.
15 / 19
Alex (Product Designer) is explaining a new icon component to the development team. He includes this annotation: `Size: 32px`. What does this annotation primarily instruct the developer regarding the icon's dimensions?
This annotation specifies a fixed size. It means the developer needs to ensure the icon's width is *at least* 32 pixels. Options B and C are incorrect because they describe scaling or setting a specific value – this annotation focuses on minimum size for visual consistency. Option D introduces an unrelated accessibility consideration.
16 / 19
During a code review, Ben (Developer) sees this annotation attached to a dropdown component: `Alignment: Center`. What does this primarily tell him about how the dropdown's content should be positioned within its container?
'Alignment: Center' defines a specific positioning strategy. The content will automatically adjust to the center of the container. Options B and C are incorrect as they suggest a placeholder or vertical centering respectively – this annotation directly states horizontal alignment. Option D is misleading.
17 / 19
Chloe (UI Designer) adds the following annotation to a text field: `Text Alignment: Left`. What does this primarily instruct the developer regarding the text within the input field?
'Text Alignment: Left' dictates a specific positioning strategy. The developer needs to ensure that if the text exceeds the width of the input field, it will wrap to the next line – this is standard behavior for left-aligned text. Options B and C are incorrect as they describe wrapping or specifying an edge alignment.
18 / 19
During a Slack discussion about a new modal window, David (Developer) receives this annotation from Emily (UI Designer): `Z-Index: 10`. What does this annotation primarily relate to?
'Z-Index: 10' refers to the layering order – a higher Z-index value means the element is visually placed closer to the front. This ensures the modal appears above other elements on the page. Options B and C are incorrect as they describe opacity or background color respectively, while option D relates to animation.
19 / 19
Liam (Developer) is implementing a handoff for a card component. The designer provides this annotation: `Stretch: To Fill`. What does this instruction primarily mean within the context of Figma's layout constraints?
'Stretch: To Fill' is a common Figma annotation that means the card will expand horizontally to fill the entire width of its parent container. The content might need adjustment within the card to maintain a reasonable aspect ratio. Option B and D are incorrect; option C describes aspect ratio, not stretching.
What will I practice in "Figma Annotation Language — Product Design Exercises"?
This is a Product Design exercise set. It walks through 19 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 19 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.