One of the most critical — yet often frustrating — stages in the development process of a digital product takes place when a design or prototype is ready for developers to implement.
The traditional workflow saw designers work in silos, between the discovery phase and development, to create pixel-perfect mock-ups based on a brief. Then, after client sign-off, they’d throw them over the wall to the developers.
This process is fraught with problems. Ideas aren’t shared as much with stakeholders to solicit feedback, and changes to the signed-off design can have harsh consequences. So these days designers work much more collaboratively with other teams (i.e. development, content strategy) throughout a project to bring a creative vision to life.
However, it can still be hard for developers to accurately translate a designer’s intent into a real-life feature or product. Meanwhile, designers often wonder why the finished product differs from their designs. Both teams also need to be a lot more adaptable and prototype rapidly, test and iterate interactive versions of what they’re working on. And so the designer-developer handoff is unfortunately not always smooth. It can be very time-consuming, costly, and sometimes it even leads to the failure of the entire product.
In this article, we’ll explore the main reasons handoffs tend to be problematic and some of the best practices and strategies both parties should follow to bridge the disconnect.
Common pitfalls during the designer-developer handoff
“Communication and alignment on the expected end result is by far the biggest challenge in the designer-developer handoff,” points out Harish Narayan, a product manager on the Adobe XD team. “Both designers and developers spend an inordinate amount of time and effort on trying to close the gaps.”
Collaborate, don’t hand off
One of the problems might actually lie in the terminology. “I believe that ‘handoff’ connotes that the design is handed to the developer, and it’s now the developers responsibility to bring the product to life,” Harish explains. “However, I think the design is not complete until the product is used by users. Therefore, it’s imperative that designers and developers communicate throughout the design and development phases.”
Bermon Painter, innovation and strategy lead at EY wavespace, agrees that ‘handoff’ is a tricky word and has found that work is rarely handed back for clarification or improvement. When he worked with a large financial services company, the business would define requirements and hand off to the content and marketing team to create a content spec. That team would then hand off to the information architecture team to create wireframes, who would then hand off to the UX team to create high-fidelity mockups, who would then hand off to the development teams.
“This level of one-way communication reminds me a bit of the game telephone,” Bermon sighs. “Every handoff loses a percentage of the context and knowledge at each subsequent step. By the time you get to the end, the message is a mutated version of the original. This same issue perpetuates with the concept of a designer–developer handoff. By the time the development team is provided with the various handoff documents, the message isn’t quite the same, and they must interpret any specs they receive. Context is lost, and intent is often misinterpreted. The end result is often a set of features that don’t fully serve their intended purpose.”
Don’t over-specify or be over-protective of your work
Designers and developers also inherently approach things from different points of views, Harish Narayan believes, which means there is often a lot of back and forth to clarify specifications, absorb changes, and reduce diffs. Designers are not always aware of existing or intended reusable components and tokens in design either. In the absence of a design system, teams therefore end up doing a lot of redundant work that leads to inconsistencies, which delay the time to market.
“Designers who rely on over-specifying their work, without working through potential edge cases or limitations often find themselves frustrated,” adds product strategy consultant Gretchen Anderson, author of Mastering Collaboration, a new book on making working together less painful and more productive.
Gretchen Anderson has written a handbook for those who wrangle people, processes, and products.Some of the don’ts to keep in mind to ensure a smoother handoff include not guarding your work, not assuming that the developers can bring to life whatever is designed, and not getting overly influenced by the developers’ feedback at the expense of the user experience.
Don’t forget to account for all the states of a design
Another perennial mistake is to not account for all the states of a design, cautions DesignOps expert Ben Buchanan.
“I don’t mean just basics like focus and hover, but things like success and failure states for an interaction,” he clarifies. “These all need designs and on-voice microcopy. If they’re not supplied, the developer will usually have to make something up so they can keep working.”
Strategies to follow to improve collaboration
So, to improve collaboration, designers need to keep the development in mind; on the other hand, developers need to keep the design and end users’ needs in mind. More specifically, designers should be technically apt enough to design effectively for the medium; and developers should know enough design theory to collaborate effectively.
“When there’s mutual understanding and respect, compromise is collaboration rather than combat,” Ben Buchanan explains. “You’re working together to solve a problem for a user, within realistic constraints. If either side is unable to be pragmatic, everyone’s going to end up unhappy.”
Designers can help by explaining which parts of a design are most important and by inviting developers to explain which parts will be difficult or slow to build, Ben has learned. “When you combine these perspectives you can work out how to hit deadlines, without sacrificing design quality. It’s also a way to demystify design and encourage developers to engage with the process.”
Harish Narayan agrees: “Designers and developers need to communicate and share work early and often. It’s best to elicit as much feedback from developers and consider platform constraints as early as possible to reduce misconceptions or gaps in understanding.”
“Devs can’t be expected to whisk a design into being without understanding the why behind design decisions,” Gretchen Anderson adds. “Taking the time to document, and more importantly, discuss the rationale for design decisions will pay dividends in an end-product that serves users, not just ticks the boxes of specs.”
Reframe requirements as assumptions
Another way to improve collaboration is to reframe requirements as assumptions that must be validated before they’re fully implemented, rather than viewing them as the final say of what should be built, suggests Bermon Painter.
“Unvalidated assumptions hold a lot of risk,” he explains. “Risk that the potential feature is something that the end user doesn’t even want. Risk that it may be designed in a way that’s not technically feasible. Risk that it may cause overruns in time, budget, and resources. Features with unvalidated assumptions — riddled with risk and unanswered questions — are the primary drivers of budget overruns and lackluster user experiences.”
Bermon recommends choosing delivery methodologies that work best for each discipline (for example a methodology based on user-centered design for designers and an agile methodology that uses sprints for developers). Then go with a dual-track approach and manage two separate but connected backlogs:
- The discovery backlog: Designers work through requirements, reframe them as assumptions, and aim to validate them. There are a couple of benefits to not forcing designers into a sprint model: It allows them to ebb and flow within the context and complexity of the requirements they’re working to validate, and it encourages support from the development team. The result is validated requirements that can then be filtered into a more traditional implementation backlog.
- The implementation backlog: This is where user stories, acceptance criteria, and the correct level of design documentation lives. Since designers and developers have decided what should be implemented together, and each requirement has been validated for both customer fit and technical feasibility, less context is lost and less rework is likely.
Create a design system
Teams should also align on standard naming conventions, set processes, and create a design system to improve efficiency and deliver consistent experiences.
“When you need to ship very quickly, try asking your devs how they would combine existing components to solve the problem,” Ben Buchanan suggests. “You may be surprised how quickly they can assemble a mockup!”
However, don’t deviate from your design system without explanation — a common mistake that Ben Buchanan has found in modern design teams.
He recommends asking yourself the following questions: “Did you intend to change the default design, is this a new variant, or should the developer ignore it and use the standard component? Or perhaps you have combined elements that make sense visually, but are technically incompatible. I think this is a key reason design tools are increasingly trying to close the gap between design and production code.”
Sit together and use tools to improve collaboration online and in person
It may seem simple but just sitting together will do wonders to collaboration. “We’ve seen many a designer and developer pair who have worked together for years become enlightened as to how the other works within the first few minutes of sitting together,” recounts creative director and advisor Dan Mall in a recent article about a collaboration approach he and Brad Frost call “The Hot Potato Process,” where ideas are passed quickly back and forth between designers and developers for the entirety of a product creation cycle.
Dan Mall’s Hot Potato Process. Image courtesy of Dan Mall.And if you can’t sit together, use video chat and other synchronous tools. Harish Narayan recommends using a dedicated communication channel, for example Slack, and Google Drive or Dropbox to share relevant images and screenshots.
Also set up regular check-ins and group meetings to ensure the end result doesn’t differ too much from the expectations.
Breaking down the barriers
So, forget the idea of the ‘handoff’ and stop working in isolation. Sit together, communicate more, solve problems together, build on each other’s strengths, and use tools such as design systems to drastically reduce the time to ship.
Gretchen Anderson concludes: “Developers and designers who pair up and explore different approaches to the big picture problems as well as more detailed UI widgets will develop trust and a shared understanding that helps them move quickly and put aside egos in favor of users.”
Here’s to a better collaboration between designers and developers! After all, it’s the foundation for building a strong product.