If you've ever got into a conversation about the biggest problems plaguing web and digital product development today, you probably heard someone refer to the 'design-development gap'. At the mention of this, several heads probably nodded sagely, and then you all moved on, content to observe the problem without necessarily resolving it. After all, there's probably a tool for that, right? Maybe we just haven't found it yet?
In reality, there are several tools to bridge the design-development gap. And, as with most problems, numerous other possible solutions exist. I'll talk about several of those here, but before we solve the problem, let's make sure we understand it, shall we?
What is the design-development gap?
Put simply, the 'design-development gap' refers to what's missing in communication between designers and developers during the product development process. The problem proves most daunting in companies where waterfall processes dominate, when a designer simply 'throws the design over the wall', dusts off their hands, and says, 'Well, I'm done with that!'
As any vegetarian who's tried to order a burrito sin carne can attest, a lack of a shared language can lead to big problems
In such a scenario, the gap leaves developers interpreting the designer's intent on their own. Which leaves plenty of room for off-brand animations, links that go where they shouldn't, and rounded corners that are just a pixel or 50 off the mark. No biggie, right? Sure – as long as you're not the person looking after the bottom line, squinting at the project hours in the quickly fading hope that, if you look at them funny, those numbers will fit the project budget.
Of course, the design-development gap doesn't just plague waterfall teams. After all – in the absence of experience and sustained, mutual effort – designers and developers speak different languages. And as any vegetarian who's tried to order a burrito sin carne can attest, a lack of a shared language can lead to some big problems.
The problems
Of course, the problems that emerge from the lack of an available translator aren't the only things that make the design-development gap problematic. To get more specific, some of the more common issues teams run into include the following.
01. Designers creating 'impossible' designs
Anyone who's wrangled a little CSS knows it can't do everything. But designers who don't know the ins and outs of CSS and are looking to push their creative boundaries can easily create designs in Sketch or Photoshop that can't be brought to the web (easily, or at all).
For this issue, bridging the design-development gap means ensuring that designers understand the capabilities of CSS enough to avoid designing impossible solutions.
02. Time-consuming documentation
One of the most common tools used to bridge the design-development gap is documentation: redlines, spec docs, component diagrams, and so on. Whatever your team calls them, they all amount to documentation, and they mean a significant amount of time is spent working on something no end user will ever directly experience. Of course, that's not to say they don't have values – most digital products can benefit from design, language, and development documentation.
But questions of their value aside, redlines and other forms of documentation take a long time to create, and aren't especially fun for anyone. For this issue, bridging the design-development gap means finding faster and easier ways to communicate specifications.
03. Prolonged feedback cycles
Feedback is inevitable, even when your designers create with CSS in mind and put together detailed documentation. And it's always valuable. But it can become a drain on resources and significantly impact employee morale when the loops go on too long. Contradictory feedback from one cycle to the next crops up, stakeholders muddy the waters with interpersonal disagreements, and everyone loses sight of the overarching strategy.
For this issue, bridging the design-development gap means finding ways to cut out unnecessary feedback loops.
How to bridge the gap
Now we understand the nature of the design-development gap, and the issues it can introduce to the process, let's talk about solving the problem. There's software designed to help – and for that take a look at my list of 5 tools for bridging the design-development gap. But there are also some so-called 'soft' skills that can help. Because, hey, we can't expect apps to solve all our problems, right?
While the modern workplace relies on digital tools to tackle most problems, there's often no replacement for good ol' interpersonal skills – especially when the core problem is essentially one of communication. With that in mind, let's take a look at three absolutely free methods for bridging the gap between your design and development teams.
01. Communicate early, often, always
Designers and developers working on a project should always be working together. And that means a lot more than commenting on the same GitHub tickets or working from shared Sketch files.
Ask how the development team would like you to communicate designs
It also, and much more importantly, means talking. So, designers: talk to your devs about how you're tackling your current challenges. Verify that your solution is feasible from a technical standpoint. Have them look at your designs and call out areas where visual elements can't be reproduced. Ask if flowing in real data will break the formatting. Find out what the best way to name your design layers might be – from the people who have to work with them.
But most importantly: Ask how the development team would like you to communicate designs, interactions, and so on. Once you understand their preferred formats for communicating specs and changes, you'll instantly be communicating more effectively.
02. Be agile
Now, I'm not a process policeman, so I won't tell you that you have to be working in agile manner, or that you need to adopt GV's sprint format. But to my mind, there's one part of the agile methodology every team can borrow. Namely, its emphasis on cross-functional teams – including people with a variety of specialities in the process.
That ensures regular and consistent collaboration between design and development, nipping potential problems in the bud. I'd also personally recommend involving your friendly local content strategist or copywriter in your cross-functional team from day one, but that's another story, for another post.
03. Speak each other's language
When proponents of the 'designers should code' philosophy speak up, one of their core arguments tends to be that it'll help them better understand what their dev colleagues do, as well as what's feasible for the web. Which I wholeheartedly agree with! However, I'd point out that you don't have to be able to write code to understand what's possible with code. Same goes for design.
For example, I'm not much of a visual designer myself – but I voraciously consume anything I can learn about it. And that's got me to a point where I can talk about design principles and best practices with my design colleagues and feel, if not fluent, then at least conversant. I've also worked in the digital design world long enough that I can usually gauge what a dev could do with an interface, and make recommendations on what would be best from a user experience standpoint.
Also, not being a practicing coder doesn't stop you from my one stupid-simple trick for gauging feasibility: asking someone. It's crazy how far a simple question will get you.
Related articles:
