There’s a growing school of thought that says design handoff and agile don’t mix.
Mila Cann, user experience (UX) strategist for the Canadian government, says it inherently contradicts agile principles for designers to hand off UX designs to the development team and move on. And traditional handoffs should be replaced with dynamic, continuous collaboration between designers and developers.
Shamsi Brinn, UX design manager at Cornell University, is the creator of the No Handoff Method, which promotes something similar: designers and developers iterating together on UX deliverables. She says handoffs are “a result of our stubborn insistence on siloed working patterns” and “the distance between design and production should be zero”.
And design system pros Dan Mall and Brad Frost are the architects of the Hot Potato Process. This promotes a constant back and forth between designer and developer for the entirety of a product creation life cycle.
But is the answer to better design handoffs really no handoffs at all?
No handoffs might seem like the nirvana for improving developer-designer collaboration, but in our experience it’s unrealistic and, for many teams, undesirable.
Why? Because although they may share the same overarching goal, designers and developers do completely different jobs. They don’t want to be up in each other’s business, stepping on one another’s toes, during the entire life cycle of a feature. In our 2025 survey of 500 designers, 51% of respondents said that designers and developers should collaborate “a few times during the project” and only 34% said they should collaborate daily. So, designers don’t want the constant collaboration a no-handoff approach would require.
Here at CollabSoft, we think there's an agile way to hand off UX designs. We call it the Clear View Method.
Yes, design handoffs originate from the waterfall model, but being agile doesn’t mean throwing out literally everything you used to do. Agile’s about flexibility, after all.
Handoffs are frustrating for many product teams not because they’re waterfall, but because they’re overly complex. The Clear View Method is a simpler approach that aims to give product teams a clear view of everything they need to successfully deliver a design.
Let’s take a closer look at the Clear View Method’s 6 principles.
Note that although we mention Atlassian products, the principles of the Clear View Method can be applied regardless of the tools you’re using for design, development, and work management.
This is super important. Many handoffs are too long and complicated because the design system is inaccessible, incomplete, or missing altogether. This means designers have to provide relevant components and guidelines to developers with every handoff. And often they don’t cover everything a dev needs, triggering discussions about components that shouldn’t be happening when you’re handing over a new design.
The lack of a design system can also lead to both designers and developers creating things by mistake, e.g. the wrong font or button, or recreating components from scratch that already exist.
The key to solving these problems is making sure you have a properly documented design system that designers have created in full collaboration with the development team.
And properly documented means publishing it in a tool that everyone is using, like Confluence. Not in a tool that’s meant for designers or developers only, like Figma or Storybook. It should be in a documentation tool, again like Confluence, which offers a structure, formatting, and collaboration options suitable for creating design systems. You can also integrate Confluence with Figma to embed Figma components and assets in Confluence pages.
Although we don’t recommend a perpetual back and forth like the no-handoff approaches, we do acknowledge that agile handoffs shouldn’t be one-and-done. To make truly great products in an efficient way, it’s important to have regular meetings and check-ins throughout the life of the project, not just at handoff.
A project kickoff meeting enables designers to outline the problem to be solved and get feedback and ideas from others. Another meeting once the design process has started is good for ensuring user needs are being met by the proposed designs. And during development, further meetings let developers advise on problems encountered during coding so that the team can find solutions together.
Designers can use Confluence to create documentation for these meetings, and CollabSoft’s Figma for Confluence app to show draft, final, and updated designs on Confluence pages.
Some companies hand off UX designs in Figma. But Figma is a design tool that, to a developer, is messy and chaotic. I’m not a developer, but I, too, remember the horror of trying to navigate Figma when a graphic designer once asked me to review an image there.
Difficulty surfacing specs or making sure you’re working on the correct design aren’t even the worst thing. It’s the fact that you have to buy expensive Figma licenses for developers who will use it only when they have to.
Design handoff should take place in a neutral, central space that your designers, developers, and the rest of your team already work in, like Jira and Confluence. This makes it easier to eliminate silos and create a single source of truth for product development and everyone who has a stake in it. Your design handoff document can be a Jira ticket or Confluence page, on which you can collaborate using comments and @mentions, and track progress using Jira fields, action items, Confluence and Jira reports, and your agile board.
You can also integrate your Jira and Confluence with Figma and display UX designs on tickets and pages, which devs can review and download without having to log in to Figma.
No developer wants to work on a design that keeps changing. Developers working in sprints follow a defined scope and scope changes can affect the team’s efficiency and morale and jeopardize their sprint goal. It can also lead to rework if developers have to rewrite and adjust already completed code.
Therefore, a designer should hand over a final design that’s “locked for editing” to provide developers with stable requirements that help them plan and structure their work. This will foster trust and accountability between the two teams.
So, if you hand off UX designs in Jira or Confluence and embed Figma frames in your tickets and pages, be careful how you’re doing it. Figma’s own Jira app only embeds a live design and all updates in Figma will propagate to the Jira ticket automatically. To hand over a “locked” design, you’ll need CollabSoft’s Figma for Jira Pro or Figma for Confluence Pro.
This, together with principles 2 and 6, is how you can make your handoff process agile without eliminating handoffs altogether.
Flexible rigidity means not being too rigid or too flexible at design handoff. The old waterfall way of handing over a final Photoshop file and that’s it, no going back, is too rigid. Products and customers suffer when designers aren’t free to make necessary changes.
Equally, handing over a live design using Figma’s Jira and Confluence integrations—which is liable to change while a dev is working on it and offers no version history for the rest of the team to track and understand—is too flexible.
With CollabSoft’s Figma for Jira Pro and Figma for Confluence Pro, you can achieve flexible rigidity by selecting a fixed Figma frame to appear on your Jira ticket or Confluence page. Even if the design is updated in Figma, the frame in Jira or Confluence won’t change unless the new version is selected. That way, designers and developers can discuss and agree any changes to the design first.
Agile promotes cross-functional working, which is why you can make your handoffs agile by handing over to everyone. There are other team members who can offer valuable input on how to meet user needs, not just designers and developers. It’s a good idea to include product owners, customer support staff, and marketing and sales teams in your handoff meetings, because all these people can offer a unique perspective on the product and how customers experience it.
Centralizing your design documentation in Confluence and Jira is ideal for handing off to everyone, because they are the digital hub sitting between all the specialist tools.
It’s clear that design handoff used to be a lot more rigid and waterfall-y than it is now. We’ve come a long way since those days of having designers and developers and never the twain shall meet.
But no handoff at all? That’s too much. The proponents of those approaches would likely favor developers working on live designs rather than fixed ones, because then there’s no real handoff, and that makes you truly agile.
But does it? Because avoiding scope creep—that’s an agile principle too.
Like so many things, we think the truth lies somewhere in the middle: flexible rigidity. And that’s what the Clear View Method is all about.
Learn more about how you can simplify design handoff with the Clear View Method and Atlassian tools.