How I established an effective process that improved design handoff

As the primary designer for the Cash4 module at Treasury4, a treasury management software system based in Spokane, Washington, I established a clear, effective handoff and process that was adopted by other teams within the organization.

Pain Point: Communication and handoff between the design and development stages of the product was inefficient and often unclear.

Previous Process: The prior handoff involved adding screenshots and notes to the 'acceptance criteria' inside of a story within Jira. While this helped communicate most aspects of a design, many nuances were lost, as was the larger picture of the feature and product as a whole. Unless time was spent looking into each individual story, an engineer was only able to see a fraction of the work at hand.

With the support of the engineering team and their willingness to try a new way of receiving designs, I became an early adopter of Figma's 'Ready for Dev' feature that was still in Beta at the time. As I learned more about my team, what worked, and what they needed, I was able to create a more effective and efficient handoff experience.

My personal workflow that inspired it all

As I design, I separate my work into labeled 'sections.' This structure helps me organize and document my ideas, quickly reference various aspects of a feature, and allows for easy collaboration within my files.  

Why couldn't I use this same structure to create a more effective handoff?

My process that creates an effective handoff

Create a 'Safe' Landing Space

I start the handoff process by creating a designated page for work that is 'Ready for Dev.' This helps separate and clarify what is ready for development and what is still being worked on. By placing this page at the top of the page order, it creates a 'safe' landing space for all stakeholders to be when they open my Figma file.

Separate UI into Sections

Inside of the 'Ready for Dev' page, I work with the product owner to create Jira story 'sections' from the mockups that relate to the acceptance criteria. Section headers display what story the UI is for (e.g., MC-774, MC-806), as well as what it relates to (e.g., 'Create' or 'View'). This allows the engineer to see how various stories piece together to create the larger picture.

Add Detail via Notes

Relevant UX or UI information gets added to notes inside of the mockups to improve clarity, efficiency, and overall communication. This is also detailed inside of the acceptance criteria, but can get overlooked if an engineer is referencing static mockups as they build.

Link from Stories

Figma creates a unique link for each section marked as 'Ready', which is then linked inside of the corresponding Jira story. This allows the mockups to be easily and quickly referenced.

Document Components / Patterns

In an effort to improve upon and maintain consistency, I established documentation in Confluence that details specific behaviors, patterns, and components that are reused throughout the product. This searchable database acts as a 'living and breathing' resource that product owners, other designers, developers, technical writers, and QA can quickly and easily reference.

Timely Communication

The design files and documentation establish a seamless handoff from design to development, but open and timely communication with the team is arguably the most important part of my entire process. Real-time collaboration, open communication, and timely solutions help prevent road-blocks and allow the team to work more efficiently.