Designers. Developers. Birds of a feather—or oil and water? The best answer, really, should be “peas in a pod.” But this isn’t always the case, and the two sides can still have a hard time even getting along. This is why the designer-developer relationship remains a constant source of commentary—from memes to books to podcasts.
The conflicts run small or large, common or unique. A designer thinks the developer failed to capture basic specs (color, proportions) laid out in the comp. A developer discovers that the designer’s “perfect” layout didn’t leave room for dynamic content. Designers promise a client a delivery-time that developers can’t make. Developers learn that a designer’s background images won’t tile. And so on.
Of course, an optimal designer-developer relationship brings countless benefits. It can save time and elevate earning potential. It can improve the product and uplift team spirit. With this in mind, we’ve made it easier for you. We’ve boiled down the secrets to mutual satisfaction with “The Four Cs.” Ignore even one “C,” and you’re asking for trouble—or at least frustration.
Heed them all, and you’re on the path to maximum productivity. Everybody wins.
The 4 Cs for a Better Designer & Developer Work Relationship
Coordinate: Build a mutual work-plan to start
Communicate: Monitor each other’s progress
Calculate: Jointly estimate all key project choices
Collaborate: Understand each other’s roles
Coordinate
Your process must stand on firm foundations. Before starting a job, designers and developers should make an actionable plan to stay connected throughout the build. This commitment will ideally stretch from kickoff to QA to beyond. You can start by setting a regular meeting—and sticking to it no matter what. You should also create a centralized hub, always accessible to all, where everyone can track each part of the process. The right platform—enter Wix—will streamline the movement of materials, putting it in one place and eliminating the need for standard wireframes and mockups.
No doubt, every agency has its own particular workflow. But sometimes everyone needs to assess if that flow is, well, flowing. Bringing on developers later into the process, which still happens regularly, can be a step in the wrong direction. Agencies might in fact be better served taking developers to the earliest meetings with clients.
Communicate
Communication is the heavy hitter of the “C”s, appearing constantly on the subject of the designer-developer relationship. These days, as crossover learning gets more common, each side often comes with some basic grasp of the other’s trade. But the dialogue still gets strained. A seasoned designer might not understand the nuances of an “open-source CSS framework.” A veteran developer might not intuitively envision a cascade-effect that a designer wants.
So, instead of just “learning each other’s language,” you should think about building your own mutual language. Sometimes this is literal: Start with a style guide, and make sure everyone signs off on it. Create a glossary clarifying all key terms. From there, find and cultivate access-points to mutual understanding. A developer might not be able to explain PHP, but he or she can explain that a particular animated effect will require 100 lines of new clean coding. This way, instead of speaking at each other, you’re speaking to each other.
Calculate
This is a byproduct of building that common language. Bottom line: You’re always working against the clock, and most tension emerges from time/money and design/cost challenges. On each side of the spectrum, the practical must go with the theoretical. A novel optimization technique isn’t optimal if it’s taking too long to pull off.
As a rule, designers tend to think big-picture. But they should avoid expecting to “get” everything from their developers at once, or even with unrealistic speed. They’re also not likely to get everything they envision. Often, certain effects or ideas just can’t be executed given your timeframe and resources. Meanwhile, developers should avoid getting married to any specific piece of code, and never lose sight of the whole, striving for good performance instead of settling for the functional.
COLLABORATE!
All roads lead here. Ultimately, designers and developers are not adversaries or even frenemies, but partners, and are best served by framing the relationship in those terms. Often this issue comes down to ownership. The designer delivers the vision—and a vision can very much feel like a personal stamp. But it takes teamwork to bring that vision to life. For best results, everyone needs to feel like they’re on the same page.
Sure, each project has its own demands, just as different teams mesh in their own unique ways. But remember your “Four Cs”—coordinate, communicate, calculate, collaborate—and you’re on the right track. You’re primed to avoid problematic “C”s—conflict, complications—and to nail that ultimate “C”: creation.
