There are multiple ways a designer can do a Figma handoff to a developer. In this article, we’re going to look at three of them:
Let’s explore the pros and cons of these three ways and work out which way of handing over Figma designs for implementation is best for developers.
This is the way many companies are going. In our recent survey of 500 designers, 42% of respondents said that their company’s developers were working in Figma’s dev mode. Figma dev mode is a premium extra that was purpose-built for developers to make it easier for designers and developers to work together. It was launched after the Figma gods realized their tool wasn’t entirely suitable for developer workflows.
So, a designer hands off their designs in Figma and a developer uses Figma dev mode to inspect and extract what they need to implement them.
Not that it’s ever that simple.
For one, Figma dev mode is expensive. Each dev who uses it needs their own Figma license, whereas before it was introduced, there was a viewer-only mode that was free. The viewer-only mode no longer exists for obvious reasons: Figma want developers to be paid users.
Figma dev mode also has limitations. Version control is complicated and it’s hard for developers to track changes at the screen or frame level and make sure they’re working on the right design. Code snippets are not production-ready and require modifications. For dev mode to be effective, it’s crucial for designers to structure their design files properly, which doesn’t always happen. And even though there’s a “ready for dev” label, that doesn’t stop designers from editing work that’s supposed to be locked for handoff.
The overarching drawback is that Figma is a design tool. Even though dev mode was made for devs, it’s still complex and difficult to navigate for devs who aren’t familiar with the tool. It will always be a tool that was built for designers first.
Figma offers ways of integrating with Jira and Confluence so that you can embed a Figma design in a Jira ticket or Confluence page. For Confluence it’s a native feature within Figma. For Jira, you have to download an app from the Atlassian Marketplace (but it’s free so same deal).
Doing a Figma design handoff in Jira or Confluence has a number of benefits over doing it in Figma itself. Jira and Confluence are neutral collaboration tools that both developers and designers are already using. So, handing over designs in a Confluence page or Jira ticket puts designers and developers on an equal footing and allows them to collaborate more seamlessly. This is because there is no learning curve for developers and no scope for confusion over how to surface specs, because they should be there in Confluence or Jira.
A con of the native integrations is that Jira and Confluence users still need expensive licenses to view Figma designs, which renders the solution slightly pointless.
You also can’t embed a fixed version of a design in a Jira ticket or Confluence page. Changes in Figma will always automatically propagate to Jira or Confluence. This is great for documentation, saving designers from having to manually re-upload updated assets and components. But for a developer trying to code a design post-handoff—not so much.
CollabSoft offers a Figma integration for Confluence and an identical Figma app for Jira. These differ from the native integrations in two key ways:
When you’re ready for a tweaked design to reflect in Jira and Confluence, just update the version. Designers need to make sure this is clearly communicated to devs, although if they’re collaborating effectively, they will already have been talking about changes.
To remind developers and other team members that an updated design has been handed over, a future feature of CollabSoft’s Figma for Jira and Confluence will automatically send email notifications when a new version is pinned.
Looking at these three methods of handing over Figma designs, a few best practices become apparent.
Figma is a specialist tool for designers. Therefore, unless your developers have already learned how to use Figma and are comfortable with it, it’s more efficient and fair for design handoff to happen in general-purpose tools like Jira and Confluence.
It’s worth noting that a smooth Figma handoff in Jira or Confluence is contingent on having a fully documented design system. Without a design system, designers have to provide a LOT of information at the handoff stage, and there’s potential for copious back-and-forth. You can find out more about how to create a design system in Confluence in our earlier blog.
The purpose of integration is to remove barriers between tools, teams, and processes. For many teams it’s a bridge between a tool they use and a tool they don’t.
But a bridge is meant to connect two sides, not demand everyone crosses it. In other words, forcing a user to have a license to the tool they don’t use defeats the purpose of the integration and maintains the barrier the integration was supposed to remove. This is exactly what Figma’s native integrations do by requiring Jira and Confluence users to have licenses to view designs.
True integrations should let each team continue working in their own tool while benefiting from the shared data, like CollabSoft’s Figma for Confluence and Figma for Jira. These apps allow Atlassian users to view Figma designs in Confluence pages and Jira tickets without a Figma license or login.
If you can’t hand off Figma designs that are locked for editing, it means they could continually change while a developer is trying to work on them. In addition to the license requirements, this is the other fundamental problem with the native integrations.
CollabSoft’s Figma for Confluence and Figma for Jira solve this problem by enabling users to embed a fixed version of a design that won’t auto-update in Jira or Confluence. This allows for simpler and more stable handovers for developers.
If you’d like to streamline your Figma developer handoff process, try Figma for Confluence or Figma for Jira free for one month.