For many companies, design handoff is a complex, drawn-out process that’s fraught with frustration and inefficiency.
It doesn’t need to be.
Let’s say your company has designers creating designs in Figma, developers implementing designs in coding tools, and both teams managing and documenting their work in Jira and Confluence. In effect, Jira and Confluence are the central hubs that sit in between the specialist tools and connect all teams.
That makes Jira and Confluence an ideal place for design handoff to take place, because designers and devs can interact and exchange information on an equal footing.
At most organizations, this isn’t what happens.
In this article, I’ll explore what usually happens at design handoff, why it’s so messy, and how you can simplify the process with the tools you’re already using.
Design handoff is when designers hand off design files to developers for implementation. It includes sharing both the “what” (design specifications and user flows) and the “why” (design context and intent) of a finished design.
Many companies make design to dev handoff way too complicated. There are two reasons why this happens.
Lots of design handoffs include sharing all the technical information about a design. For example, tokens for colors, typography, and icons, along with components and patterns for specific functionality.
Yes, designers do need to provide all this information for a design to be successfully implemented. It makes sure developers don’t build outside of the guidelines, or even rebuild a component that already exists.
But should designers be providing all these specs at design handoff? No. This is what a design system is for.
A design system is a set of standards, principles, and building blocks to help keep the look and feel of your digital products and experiences consistent. It includes design principles, guidelines on how and when to use different elements, and a complete catalog of components, patterns, and styles.
According to the 2023 DesignOps Benchmarking Report, 68% of design and dev teams think that poor design system adoption is the main cause of design-to-dev inefficiency. Design file organization came a close second (67%) and design documentation was third (66%).
The report also said that over two thirds of respondents lose 25-75% of their time each week to design delivery inefficiencies. This is leading to decreased team motivation, a decline in designer productivity, and delayed feature launches.
It all makes the importance of getting a design system in place—not just in place but properly documented and actually used—pretty damn clear.
The other thing that makes handing off designs to developers much harder than it needs to be is the tooling. These days, designers are putting all the handoff information into Figma and giving the devs access to it. But this carries challenges that affect the entire process of product development.
Design tools like Figma favor a designer’s experience over a dev’s. In a previous article we explored the stark contrast between designers' and developers' tools, and the totally different approach and mindset behind them. To a dev who likes order and logic, Figma is messy and chaotic and difficult to navigate. As a result, devs struggle to surface the specs they need, or even make sure they’re working on the right design.
Sometimes, bad file organization and documentation is down to the designer, not the tool. But that doesn’t change the fact that tools like Figma are made for designers, not devs. You can draw a picture in Microsoft Word, but that doesn’t mean you should.
Sure, Figma has a developer mode and inspect functions to help devs find what they need quicker. But these additions only go so far. For example, version control in Figma dev mode remains complicated; it’s hard for devs to track changes at the screen or frame level and it’s easy to miss important updates. Also, dev mode’s “ready for dev” label doesn’t stop designers from editing work that’s meant to be locked for handoff.
A Figma handoff can be difficult for a designer, too. Designers will spend hours every week manually organizing their design files and explaining them to devs. Files that have to be maintained going forwards, eating up even more time.
Another obvious drawback of getting your devs to work in Figma is that you have to pay for the privilege. Buying a pricey Figma license for your developers is difficult to justify, particularly if they’re only using it to look at designs.
A better understanding of what developers really need at design handoff can help simplify the process. Although it will vary depending on your workflow, here's a list of the top things we hear developers ask for.
At the heart of every build is an overarching objective. This should be a nice, concise explanation of what the feature or design is supposed to accomplish. This helps make sure developers keep users and their needs in mind while implementing a design.
For example, your objective could be to create a better login experience and reduce the number of failed logins.
Context provides the bigger picture and background on why a feature is being built, who it’s being built for, where it will be used, along with any relevant constraints. If it’s a new login process, why is it necessary and why are users struggling with the existing way to log in? Is it for users who do or don’t have a license? Is it for premium users? Context helps developers better understand the purpose and rationale of a design.
Design intent is the overall experience that a designer wants a user to have when interacting with a user interface. It provides the reasoning behind specific design choices such as layout, interaction, and visual elements, to make sure developers don’t overlook critical details designed to meet users' needs.
For example, your login process might include a new error message that specifies the exact issue, e.g. “incorrect password” instead of “login failed”.
Acceptance criteria are the requirements for the build. They should encompass all the specifications on user flow, i.e. the path the user takes when interacting with a product, and what the product should do at every step. What should happen when a user clicks a button? What should the button look like when you hover over it? What should appear when content is being loaded?
A designer could give a broad list of acceptance criteria for the design, or make detailed lists specific for different screens, e.g. screen 2 is the loading screen, which should look like this, and screen 3 is the logged-in screen, which should look like this.
There should be no ambiguity about which design file is the right one. Otherwise, a developer will waste time building the wrong thing. Adding locked-in Figma designs to a Jira ticket or Confluence page is a simple solution to developers' need for finalization. It provides a clear separation between the free-form canvas designers are continuously iterating on and the locked designs that developers, managers, and other stakeholders can use for reference.
Figma’s own Jira and Confluence integrations don’t let you add a locked-in design; all embedded designs simply auto-update to the latest version, and there’s no way to switch to past versions. But you can do both these things with Figma for Jira Pro and Figma for Confluence Pro from CollabSoft.
To make sure your design handoff is smooth and not overly complex, you should have a design system in place. But don’t put it in Figma. Figma might seem like a sensible place for for your pattern libraries and style guides, but a design system is not just pattern libraries and style guides. It’s more strategic and in-depth and includes the how and why behind everything, which is why it should live in a knowledge base tool like Confluence.
Plus, everyone’s already working in Confluence. Not just your developers, but your marketing teams as well, who’ll also need to use the design system. It simply doesn’t make sense to put the design system in a design tool that none of the rest of the company has access to.
Your design handoff tool shouldn’t be a tool that favors one team’s experience over the other. Not if you’re trying to reduce design delivery inefficiency and improve collaboration between developers and designers. In other words, your design handoff tool shouldn’t be Figma. It should be a neutral tool, one that developers, designers, and the rest of the product team already use.
This is why it makes sense to use Jira and Confluence. For small projects and minor usability improvements, e.g. adding dark mode functionality, a Jira ticket could act as your handoff document. A designer can put the objective, context, design intent, and acceptance criteria in the summary and issue description, and use an app like Figma for Jira Pro to embed a locked-in design. The app offers a bunch of options for displaying designs and how devs can inspect and download them without the need for a Figma license. Interactions between developers, designers, product owners, and quality assurance (QA) engineers can all happen on the ticket in comments.
For bigger projects such as a new login process, your handover could take place in Confluence, since a Confluence page offers more room for describing the context and intent of a design. You can also include information such as end user profiles, project roles and responsibilities, and any technical limitations you’re aware of. And you can use CollabSoft’s Figma for Confluence app to embed multiple locked-in designs that Confluence users don’t need a Figma license to access. Finally you can link to all the Jira tasks/stories required to create the new login process.
To make everyone’s life easier, use the Clear View Method for Design Handoff. It’s about giving everyone in the product team a clear view of the things they need at design handoff, and not letting your tools or an elusive/badly documented design system obscure that view.
Put these six principles at the center of how you work and we think your developer-designer collaboration will instantly start to improve.
Let’s see how these principles apply to companies working in Jira and Confluence.
As mentioned earlier, Confluence is a great place to document your design system. Confluence and Jira are already tightly integrated, which makes it easier for devs to surface the technical information they need when they receive a Jira ticket. And you can use CollabSoft’s Figma for Confluence app to embed components and assets in your design system pages. With a Confluence design system, the whole team has easy access to design assets outside of their specialized tools.
Handoff shouldn’t be the beginning or end of the process; designers should host regular meetings and check-ins before, during, and after handoff. Confluence is an ideal tool for creating design documentation to support these meetings, and you can use CollabSoft’s Figma for Confluence app to show draft, final, and updated designs on Confluence pages.
Handing off designs in Jira and/or Confluence, the tools that everyone uses, makes it a lot easier to create a single source of truth for the product development life cycle. And handing off a locked-in design using CollabSoft’s apps provides developers with stable requirements, minimizing the need for rework and maintaining the integrity of the Jira ticket or Confluence page as the design handoff document.
Practicing flexible rigidity is about not being too flexible or too rigid at design handoff. For example, Figma’s own Jira and Confluence integrations don’t let you add a locked-in design; all changes immediately propagate to the design in Jira or Confluence. This is too flexible. At the same time, locking in a design using CollabSoft’s apps shouldn’t mean no going back. That would be too rigid. Teams should aim to lock in a design, discuss it, gather feedback, and work on a new version—which you then lock in again.
The final principle, handing off to everyone, emphasizes that product development isn’t just about designers and developers. Lots of other team members have roles and stakes. It’s good practice for designers to include developers, product owners, support and marketing teams in the handover process. And centralizing your design documentation in Confluence and Jira allows all these teams to offer feedback, discuss concerns, and find solutions together in a familiar setting.
Overall, following the Clear View Method is about facilitating easier design handoffs while ensuring that developers still build exactly what designers intend.
The TL;DR is that you can save time and frustration for designers and developers by using Confluence and Jira for your design documentation and handover processes. It makes design delivery much simpler than if devs are forced to navigate Figma.
You can make the process even smoother with an app like Figma for Jira Pro, which enables devs to see point-in-time designs on Jira tickets without needing a Figma license. And with Figma for Confluence, you can share designs with full context on Confluence pages. Again, no Figma licenses required. This enables designers to involve other teams and stakeholders who may not work in Jira, aligning everyone on design delivery and making sure the new feature is solving the right problems.
Learn more about the Clear View Method for Design Handoff, or try Figma for Jira Pro and Figma for Confluence for free on the Atlassian Marketplace.
A former lawyer, Berry loves theme parks, has published a sci-fi conspiracy thriller trilogy called Million Eyes to rave reviews, and is a specialist in writing content for tech companies.
