Tips for a better developer workflow

When I switched to Figma, my experience working with developers totally changed. Instead of handing off designs to them at the end of the process, I was able to involve them from the beginning. From the moment I started wireframing, I'd share the Figma URL — which stays up to date since Figma files are on the web — and they would give feedback and ask important clarifying questions. The resulting conversations shaped the designs in meaningful ways. It also helped us avoid any big surprises when designs were ready to be implemented in code. (I like to say Figma took me "from handoff to handshake" 😉.)

Because developer collaboration is such an important part of the design process, we're committed to evolving and improving the experience in Figma. In the past couple of weeks we made some small but important tweaks to support collaboration with engineers. In this article I'll highlight a couple of these changes and share a few tips that many of our users have found helpful in their own workflows.

Help developers understand more about your components

View-only users can now go to main components

One of our latest updates makes it easier for developers to discover where components come from. Even if they have view-only access, they can now select a component instance and choose "go to main component" from the context menu (or alternatively in the code view of the right-hand properties panel) just like editors of the file. Figma will then take them to the location of the parent component, whether it's located in the same file or a different one.

By seeing where the component is coming from, the developer has more context. They can deduce whether a component is part of the official design system or if it's a new element created by the designer for this specific project. That helps them figure out whether it already exists in their system, or if it needs to be built from scratch. In comparing the main component to the instance, the developer can also better understand the nature of the overrides that were applied to the instance.

If you think this new functionality will be useful, make sure developers on your team have view access to your libraries as well (otherwise they may get taken to a file where a main component resides, only to arrive at a 404 error 😆 ).

Component descriptions in the code panel

The second tweak we made is with component descriptions. We now show them in the code panel, so developers can review any information you include. I recommend adding details here that will help people understand how a component fits into your design system.

You might include:

• Actual component names from your code base (or a clear way of identifying the name and state of the component depicted by the instance)
• Relevant hyperlinks to code repositories
• Documentation that describes proper usage
• Explanation that a component is local to the file and not part of the broader design system (assuming you created a component like that)