Figma

This section contains everything you need as a developer when working with Figma. From understanding column layouts and measurements to properly exporting images and using annotations for implementation, these guidelines will help you translate designs into code accurately and efficiently.

Overview

Figma is designed around visual design with developer handoff.

Unlike working directly with code, Figma:

provides visual layouts that must be translated into implementation
uses Dev Mode to expose measurements, spacing, and assets
supports both comments (for questions) and annotations (for handoff)
follows an 8-point spacing system for consistency

Because of this, developers must actively verify measurements, column usage, and asset requirements rather than relying on visual approximation alone.

Before implementing a design from Figma, always check:

how many columns each element spans
whether measurements follow the 8-point system
what visual styles should be handled in CSS vs baked into assets
whether annotations provide additional context or constraints

Columns in Figma

Understanding how columns work in Figma is essential when creating components, modules, and full page layouts. Knowing exactly how many columns an element spans helps avoid mistakes during implementation and ensures consistency between design and development.

In some cases, column usage is obvious at a glance. In others, especially when content length or copy changes, it can be misleading. That’s why it’s important not to rely only on visual intuition, but to actively check the layout guides and the actual bounding box of each element.

In this video, you’ll learn:

how to show and hide layout columns in Figma
how to use layout guides in both Design Mode and Dev Mode
how to verify how many columns an element really occupies
why clicking on elements is key to understanding their real width, beyond what the copy suggests

This is a fundamental step when working with grid-based layouts and should always be checked before building or reusing components.

Comments and Annotations

Figma offers two different ways to communicate inside a file: comments and annotations. Although they may look similar at first, they serve very different purposes and should not be used interchangeably.

Comments are meant for conversation and problem-solving. They are useful when you have a question, need clarification, or want to unblock yourself quickly while working on a module or page. Comments are temporary by nature: they create a discussion thread, can include mentions, links, or media, and are resolved once the issue has been addressed.

Annotations, on the other hand, are part of the handoff. They are meant to stay visible and provide long-term context for the project. Annotations attach directly to specific elements and help explain implementation details, constraints, or decisions that developers need to be aware of.

In this video, you’ll learn:

when to use comments vs annotations
how each one behaves inside the Figma canvas
why annotations are preferred for handoff and implementation notes
how both designers and developers use annotations to keep track of requirements

Using the right tool for the right purpose helps keep communication clear, avoids confusion, and makes collaboration between design and development much smoother.

Measures

The Measure tool is essential when translating designs into code, especially when building components and modules from scratch. It helps you understand exact spacing, padding, margins, and distances between elements, directly inside Figma.

When working on implementation, you should always be in Dev Mode, where most measurements are visible automatically when selecting elements. In addition to that, the Measure tool allows you to manually measure distances and keep those measurements visible as a reference while working.

In this video, you’ll learn:

where to find and use the Measure tool in Figma
how to read spacing, padding, border radius, and distances between elements
why all measurements should follow an 8-point spacing system
how to spot potential design mistakes when values are not multiples of 8

If you find a measurement that doesn’t follow the 8-point system and you’re not sure whether it’s intentional, always ask the design team before implementing it. Adding arbitrary values usually leads to inconsistencies and bugs.

Exporting images from Figma

Exporting images from Figma is not always as simple as clicking “Export”. Depending on how the design is built, images may include visual styles (such as border radius, gradients, or masks) that are meant to be handled in code rather than baked into the asset itself.

In this video, you’ll learn how to properly export images for development, making sure they match the intended implementation and remain flexible when used in the browser.

You’ll see:

how to export images directly from Figma using the right sidebar
when and why to switch to Design Mode to prepare assets
how to safely duplicate elements before making changes, so you don’t affect shared components
how to remove visual styles like border radius or gradients that should be handled via CSS
how to adjust image size and crop settings to control aspect ratio and visible area
when it’s better to ask the design team for help, especially with complex or custom-shaped images

Following this workflow helps avoid exporting incorrect assets, prevents visual bugs, and ensures images behave correctly across different screen sizes and layouts.

WebP Exporter Plugin

Using the correct image format is essential for performance. At Terra, all images used on websites should be WebP, instead of JPEG or PNG. WebP provides better compression, smaller file sizes, and improved rendering, which directly impacts loading speed and overall user experience.

In this video, you’ll learn how to export images as WebP from Figma and how to make sure those assets are actually suitable for the web.

You’ll see:

how to export WebP images from Figma using the WebP Exporter plugin
why exports should always use 100% quality
how to choose the right resolution (1x vs 2x) depending on the use case
why exported WebP files can still be too heavy
how to properly compress images using tools like TinyPNG
alternative workflows using PNG/JPEG → WebP converters when needed

Even if an image already looks “light enough”, it should always be passed through a compression tool. This extra step can significantly reduce file size without any visible loss in quality and is a required part of our asset preparation workflow.

Best Practices

Do’s ✅

✅ Always consult Foundations first: Before defining a custom color, size, or spacing, verify if a token already exists in Foundations
✅ Respect 1:1 nomenclature: Maintain Figma names when creating files in code
✅ Always work in Dev Mode when implementing designs.
✅ Implement all states: Each component should have its hover, active, focus, and disabled states when applicable
✅ Implement all variations: If a component has multiple design variations in Figma, they must have modifier classes in SCSS (e.g., c—card-e for default, c—card-e—second, c—card-e—third for variations)
✅ Maintain folder structure: Respect the project organization based on Figma structure
✅ Use the Measure tool to verify spacing and check for 8-point system compliance.
✅ Click on elements to check their actual bounding box and column usage.
✅ Use comments for questions and annotations for handoff notes.
✅ Ask the design team before implementing measurements that don’t follow the 8-point system.
✅ Duplicate elements in Design Mode before removing visual styles for export.
✅ Export all images as WebP using 100% quality.
✅ Always compress exported images using TinyPNG or similar tools.
✅ Review annotations for additional context or constraints before starting implementation.

Don’ts ❌

❌ Don’t create custom tokens without consensus: Don’t define colors, sizes, or spacing that don’t exist in Foundations without first consulting
❌ Don’t invent names: Don’t change Figma component names when implementing them in code
❌ Don’t ignore variations: If a component has multiple design variations in Figma, all must be implemented with their corresponding modifier classes
❌ Don’t use hardcoded values: Always use defined variables and tokens, avoid arbitrary values like margin: 23px
❌ Don’t skip responsive: All components must work correctly across all breakpoints
❌ Don’t modify global components without reviewing impact: Changes to base components can affect multiple pages
❌ Don’t duplicate code: If a component already exists, reuse it instead of creating a new one

Knowledge Check

Test your understanding of this section

Loading questions...