Handoff from Design to Development [Design in Agile]

This article is part of a series of Design in Agile. Here I address some approaches to this question: How should Handoff (Design → Developer) work in an agile organization?

Work Illustrations by Storyset

What is design handoff?

Design handoff to developers refers to the ceremony event or process of communicating design requirements to the engineers who build them. Usually this involves communication between a product manager and/or product designers, and the executing team of front-end or full-stack developers. This can take place in a meeting in person or online, and usually involves some artifacts both written and visual.

The process question is tightly coupled with broader handoff processes in the organization. Specifically, how in general are product requirements handed off from PMs/designers/architects to developers? Who is there, and what events or ceremonies take place? What documents diagrams and medium are used? Etc.

Here I can describe what I’ve seen, what’s worked better and what worse. Here, too, I do not portend to have achieved ultimate and unimprovable work processes.

Handover that cupcake, and some requirements. Photo by Charles Etoroma on Unsplash

The answer: grooming session with business context, all relevant stakeholders, artifacts, and followup.

The short answer is: a grooming/handover session that provide business context, do the handoff together with the full functional team, provide sufficient artifacts, and expect more detailed followup sessions.

I’ve heard that ‘Grooming’ may not be the politically correct term, and I hope this does not offend anyway. By this I mean a session (meeting), wherein the PM or PO or designer(s) explain the business context and goes through the requirements, so that the dev. Teams can begin to work on the solution.

1. Business context. This part is easy to overlook. Sometimes, developers give the impression that they are not so interested, but I have seen high variability between developers, even on the same team. By business context, I mean: why is this feature/product being developed? Who needs it? Why? What value will it give the users? A word about competition? How does it fit into the strategy of our company? Why do we need it now. What is the minimum development that will deliver value? How do we measure value and outcome (not output)? Basically, why am I asking dev. Teams to invest time and energy in it? Sometimes for this it’s really important to explicitly state the NON-goals, like what we do NOT care about. This is because it can save a lot of dev. Team, and get the developers aligned on NOT building part of the feature or functionality. If these non-goals are omitted, sometimes responsible devs will ask to develop this part that was omitted from requirements, or assume that it has to be developed and go ahead and invest time and energy in it. When they understand why NOT to build something (part of roadmap and we want to deliver value earlier, too complex for this stage, or simply because customers will not use it even if it sounds like a no-brainer), then devs. Are happier to save dev. Time on not building something, rather than feeling like it’s a cheap way of cutting corners, or that the PM is doing a shoddy job. This part is actually the same whether handoff is for FE team or full-stack or even solely a BE team. We don’t want developers to be code monkeys, or to feel that they are code monkeys, blindly developing something just because it is written in the requirements. Indeed, sometimes when the business context is explained well, the developers can push back on the solution. This is true for UX/UI solutions. It takes a mature PM or designer to honestly listen to feedback from the developers. Earlier in my career I was not mature enough to be authentically open to the suggestions of the developers. I heard some terribly suggestions, and felt it was a waste of time to have to explain and prove why some ideas are bad. But as I matured and developed and gained confidence, I was counter-intuitively able to better listen, and even embrace suggestions by developers. I realized how stupid I had been to not be able to truly listen. Now my approach is more collaborative. Some solutions I propose (whether UX/UI or Product) are better researched and grounded, and others are frankly best guess in order to be able to move forward. I try and be more explicit about these, and explain my decisions. For the decisions and requirements that are less thought out, I actively seek feedback and suggestions of other PMs and yes, or developers. Contrary to common belief, developers are, indeed, people too. Seriously, though, some have years of industry experience, even beyond their engineering skills. And they can also have years of experience working with a bunch of PMs, so they can also bring knowledge to the table. This is probably a broader topic, so let’s end this rant now and return to the subject at hand.
2. Relevant stakeholders. When doing handoff to front-end only (not full stack) devs, it’s important to me that those developing the BE are also there. For cross-functional squads, this is obvious. But if the setup of the organization involves a Front-End dev. Team, and a different BE dev. Team, it’s important that both are at the session. Since the design of the BE solution will / should be impacted by the needs of the FE development. I have seen many times when the handoffs are done separately, once with FE team and separately for BE team, and later on this leads to gaps, misunderstandings, and a lot of back-pedaling to get it right. I’ve noticed that for BE devs, having a FE really helps! Other PMs in the company have also become convinced of the value of this.
3. Artifacts. These include something visual, like mock-up/prototype and specs. Adobe XD, Figma, Zeppelin, Axure or if low fidelity than Balsamiq or even powerpoint is fine. They need to see something. This is not enough however. There usually has to be some written explanation about expected behavior. Like what happens when I click here, hover there, or drag that? You also have to provide SVGs or pngs or whatever you use. Dont forget requirements about screensizes/resolutions and responsivity, and if web-based product than you’ll need to provide supported browsers. Of course, performance requirements based on expected usage. Also explain how you expect it to be tested. And deployed. Here is the place where you make sure you adhere to accessibility, if that is a requirement too. Another note: often I have found myself struggling to explain to FE developers which APIs to use. In a complex environment where there are multiple microservices and API calls, I have found myself mapping out specific elements of the screen to API calls. Like, for a list of EntityAType, I wrote: ‘Use microserviceName.yaml GET /getListOfEntityA ‘ and for the + button to add to list, I wrote ‘use microserviceName.yaml PUT /addEntityAList’ etc. I dont view this as the normal part of the job of the designer or PM, but in some instances I found it necessary, and it saved time at the end of the day.
4. Detailed follow-up sessions. Depending on the size and complexity of the feature, you’ll probably need follow-up session where you do a deep dive. Even if the requirements are really detailed and include links to pixel-perfect specs (Zepplin, XD, Figma), you’ll still need to explain interactions, sometimes animations, conditional fields, and the underlying logic. Things that are obvious to you as a PM/Designer are NOT obvious to the developers. Of course, some FE developers have developed a keen sense of UX and UI over the years, and it is worthwhile to tap into that. But you’ll still need to make sure you’re aligned. Else, you’ll get a different outcome than what you expected. When I do detailed follow-up sessions with the FE dev(s) that are going to work on my screens, I find myself polishing the requirements again, and sometimes finding gaps in design for edge cases. You need courage to admit that even though you thought you thought of everything, you did not. And sometimes the design solution needs to be re-considered.

So we said we have a grooming session, together, with relevant artifacts, and then follow-up sessions.

There are a few more events that help keep aligned. One is the check in. Based on effort estimation, check in however many times necessary to stay aligned. The FE devs can show you progress on local dev. Environment. And then, I have a final review together with the dev., where we open the requirements together and review the screens. Sometimes some things were missed, other times they were misunderstood or not well enough explained. Other times the development was spot on, but the requirements were not good enough. Usually some fine-tuning is due even if everything did go smoothly. And finally, there’s the demo when the feature is complete. Others stakeholders are invited, technical writers, marketing, other PMs, sometimes sales, and more.

Thanks for reading.

About this Series

This is an article in a series on Design in Agile based on my experiences.

About the Author

I’m a UX Designer turned Product Manager, with experience in startups, freelance, and international B2B companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.