The First Rule of Design Handoff Is ... There Is No Design Handoff

Designers and developers are integral to the success of digital initiatives. But how do beautiful designs become well-functioning finished products? We asked the experts: leaders of our user experience, development and product management teams.

Q: We are gathered today to talk about design-to-dev handoff –

Dan: Let me stop you right there. There is, or there should be, no “handoff.” Design and development should be collaborative, iterative and ongoing.

Q: Which is the opposite of the “waterfall” approach.

Dan: Right. Waterfall is a series of handoffs. When the design is “done,” the designers roll off the project and the devs get started. But here’s the thing: What if the design didn’t solve for all the requirements? Or it solved today’s requirements, but it’s too brittle for potential future evolution? Maybe by tweaking the design we could make the codebase easier to work with, which would facilitate ongoing innovation.

Claire: It’s not like once the design is “done,” the designers are finished with the project. Digital is never done. No design on its own addresses every question a developer needs answered to build the solution. The developer and designer need to talk through the user experience – what happens here, what if this, what if that, did you consider ...? And the designer may need to make adjustments once the developer is actually building.

Design needs to be informed by knowledge of the medium. And developers need to care about design concepts.

Sarena: I’ve been in situations – not lately, thank goodness – where you basically take the design file and throw it over the wall to the tech group and next thing you know, surprise! It’s done – only it doesn’t reflect what you sold the client. That can happen when you don’t collaborate.

Dan: Not collaborating guarantees frustration. Because developers don’t get enough context, designers don’t understand why their design got messed with and clients are frustrated that the end result doesn’t match what they thought they bought.

Q: So waterfall is like an assembly line. Just to play devil’s advocate ... The automotive assembly line was considered a great innovation. But the hubcap team doesn’t collaborate with, say, the carburetor team.

Dan: Well, for starters, cars no longer have carburetors or hubcaps, but as to your assembly line analogy, you’re actually making my point. Because the assembly line is where the final assembly happens. By the time the car rolls off the assembly line, there’s already been years of collaboration among product designers, engineers, supply chain specialists, human factors, finance, you name it.

Q: All right, so collaboration sounds good – but doesn’t it add time and cost?

Sarena: It actually saves both. The designers and devs get to the point where they don’t need to sketch each page, because they’ve already created the components. As a UX designer, I work with the developers to make sure the design concept is solid, even in edge cases like lots of text, or no text, or whatever. Then I document various states, colors, buttons, type hierarchy, micro-animations, etc. So it’s easy to apply to new pages and functions.

Q: All this collaboration sounds like a case for agile development.

Sarena: It does. Agile means working in short sprints. So the huge task of building a complex web product gets broken down into little chunks. The whole team takes part in daily standups. That facilitates collaboration.

Claire: Here’s an example: On a big website overhaul, we’re doing planning for UX design, tech and content. We have daily standups. So even though dev isn’t on the hook for anything right now, the tech lead can start to prep for what’ll be coming up.

Q: Do developers in a sense actually need to be designers, and vice-versa?

Sarena: No, but design needs to be informed by knowledge of the medium. And developers need to care about design concepts.

Dan: You need designers who understand what makes good UX for the user and also for the developer.

Sarena: Design isn’t flat or static. Designing requires thinking through how a user will interact with that design, and what it will take to build and maintain and extend that design. So you need both the designer and the developer perspectives.

Q: What other benefits come from design-dev collaboration?

Claire: Accessibility. We’re very attuned to making a site accessible. Designers and developers both need to be aware of accessibility standards and guidelines. It’s much easier for the developers to ensure a site is accessible if the site components are accessible to begin with. And the best way for that to happen is – you guessed it – collaboration.

Q: So to wrap up – should CMOs ask their agency partners how the design and dev teams collaborate?

Dan: I think CMOs or anyone in charge of hiring an agency needs to be confident they understand exactly how the work will get done. Not for them to micromanage it, but to confirm the agency has the appropriate mindset and right approach to do great work that is buildable and expandable and repeatable.