The worlds of software design and engineering intersect and frequently intertwine. The partnership is critical, and yet we often hear stories about how the two disciplines come into conflict.

Over lunch recently, our integrated teams reflected on the ways that designers and engineers work together at Lab Zero. The gaps they perceived, and how those gaps are addressed here, might surprise you.

The Time Gap

“Design happens first, then development.”

Yes, designers finish a design and move on before development has finished building a design. In order to have the right perspective when we need it, we structure our timelines so that:

1. developers are available ahead of the design review to give preliminary feedback (sometimes it’s just the lead developer, not the whole team)
2. designers are available after the design review, during development and testing, to refine designs or fill in gaps that are discovered as the team discovers extra use cases.

The Values Gap

“Developers focus on function, whereas designers look at the human experience.”

It’s true: designers more often ask themselves the question, ‘What’s going on with the user?’ and developers more often ask themselves the question, ‘How can I validate this user input?’

We don’t hate this gap. A team that doesn’t take stock of the system requirements and constraints they have to work with will fail. And a team that doesn’t account for the needs of users in their lived experience will fail. We leverage this difference for higher productivity by committing to value each other’s perspective and respecting their judgment.

Note: It’s interesting that the developer often is the first person to actually evaluate the real user experience and know when it's really bad (at least until our prototyping tools improve). Long wait times; frustration over complicated forms; the system not remembering things for you — these are things developers notice early. 

The Detail Gap

“Designers focus their time on the critical paths. Developers have to handle every path.”

It’s natural for design to focus on the ‘most common experience’ (when there actually is one). But we don’t want design to go too far down the path without committing to address the edge cases.

LZ designers bridge this gap by showing the developer the design for known critical paths, and then asking them what’s missing. Sometimes a developer can lead the way to devise a solution that the designer can then incorporate or refine.

On the other hand, designers have a keen grasp of visual details and interaction patterns. The developer may not notice the way the design’s type sizes or grid supports hierarchy and reduce cognitive load. The two disciplines preside over different realms of detail, and they each leverage the sensibilities of the other discipline to make sure nothing is missed.

The Transparency Gap

“Designers get to know the user. Developers get to know the data.”

Designers meet users more often than developers, but developers tend to have more access to actual user data.

We address this in the following way: designers publish direct observations as well as conclusions associated with each user insight. For their part, the developers offer hard data to support or refute conclusions or point towards one design approach over another. And we’re always on the lookout for tools like Adobe XD that make it easier to incorporate realistic (if not live) user data during design exploration.

The Certainty Gap

“Designers are always testing a hypothesis. By comparison, at any time developers are working toward a known, fixed goal.”    

Good designers treat each design output as an input to test a hypothesis about what the user needs. In design reviews, it can come across that they hold many plausible outcomes at once. By contrast, developers operate in a state of greater certainty. They view the design as a goal in itself to be achieved through code that operates predictably and reliably.

The certainty gap is healthy in design + dev collaboration. We view this as a division of labor. It’s hard to focus on solving specific, technical problems if you have nagging doubts that you’re building the right thing. At the same time, somebody on the team needs to be open and tuned into the signal that’s coming back from the users.

Patterns for Addressing a Gap

In examining our own patterns for addressing these gaps, it seems that we often find a way to bridge the gap, by bringing designers and developers together earlier and later in the process, and encouraging them to stretch their own domains into a state of overlap.

And other times, a gap represents an efficient division of labor; a specialization; a bridge of trust where divide-and-conquer make us more successful.

How Do Design and Dev Work Together in Your Organization?

Are your developers and designers eating lunch together, or are they in separate silos? Can we help you build successful interactions, and make your team a better functioning whole? Please get in touch!