We hope those little updates make your 'handshake' with developers go more smoothly! In addition, I wanted to share a collection of tips that have helped me collaborate with engineers in Figma.
When you're creating type, color, and effect styles, give them names that align with color names you're using in code (for example, token or variable names). Developers will then see these names in the code panel in Figma. They'll surface as comments in the CSS view, and as line items in the table view. This can enable developers to implement variables in some cases, rather than hard-coded values (like hex values) that might exist in their system.
Some teams may even take a functional approach to naming their styles. This method can be useful for adding a layer of semantics to the naming scheme. For example, you could name a color based on its hue, but that wouldn't describe its intended use case. Teams who choose instead to implement a functional naming system add a level of abstraction to their naming to ensure proper usage for both the designer and the developer. For example: a drop shadow named $modal-shadow or color named $alert-warning makes it clear which style to use where.
Figma has built-in contextual visualizations to display redlines for measurements and distances. Viewers can access them by selecting elements and hovering over other elements that they want to measure the distance between. This can reduce most of the arduous effort associated with manual redlining when creating specification docs for developers.
But sometimes it can be beneficial to add annotations or manual redlines to the canvas when you want to provide additional information. I recommend doing so when you want to:
It's good practice to clearly communicate which parts of your work are ready for implementation. That way, you don't send developers deep sea diving into your designs to figure it out for themselves. There are many paths to communicating the 'ready file' status in Figma. Here are a few ways we've seen teams do it:
When you invite developers into your projects earlier, you create more transparent workflows and ensure no one is left in the dark. Developers can then ask clarifying questions throughout files and flag any potential issues early instead of at the time of implementation.
We hope this recommendation, combined with some of the improvements and tips outlined above, will streamline your process of going from concept to implementation. If you have more tips and tricks that have helped your workflow, please share them on our online Spectrum community!