How to Collaborate Without Killing Each Other

At Counter, we often find that there is a language barrier between the technologically savvy development team and the creatively driven design team when working together on a project. Designers will scribble out intricate designs in their notebooks and expect developers to be able to derive font, font size, margins, scaling, and mobile views. Conversely, developers will break design systems down into strict hierarchies of classes and components–often losing the nuance of the designer's vision in the process. This leads to a lack of cohesion which is especially detrimental to a project such as a website.

The designer/developer relationship is fundamentally about compromise. Designers want one thing, but developers can only implement another. The solution lies in the middle. Practical design is all about having the entire team subscribe to the desired outcome and work through the trade-offs together.

One way in which we smoothed out this relationship was to invest some time in learning the basic methodology and workflow of the “opposing” team. William, our web developer, has been slowly immersing himself in Adobe Suite, taking on basic photo and video editing tasks rather than relying on a colleague. Luke, our creative director, has begun taking introductory web design and programming courses and aims to build a personal website from scratch. Learning a little about each other's roles has smoothed out discussions and eliminated misunderstandings that would otherwise cause delays and confusion.

Keep in mind: we’re not saying that designers and artists need to drop everything and sign up for a million coding boot camps, or that developers should give up on coding and become the next digital Picasso. The helpful understanding can be achieved through a day of reading, or perhaps a few YouTube videos. Spending just a little time can be worth a lot.

William learned that just because a text element is aligned on the DOM, that doesn’t mean it’s aligned visually. “It’s aligned!” he would persist, pointing to the perfectly matched boxes in his developer tools. “The top of the text doesn’t match the top of the image!” Luke would retort. Of course, both are correct–albeit for different reasons. We learned to understand that just because two elements are mathematically aligned it doesn’t mean that it will always be reflected visually, and that “aligned” to a developer is not the same as “aligned” to a designer.

For Luke, he began to understand that “just changing this small thing” can sometimes be far more difficult than might be expected by someone unfamiliar with the development process. Browser limitations, mobile-friendliness, and load times are all things that need to be considered when designing a website. A mockup might have videos and images scattered all over in a beautiful visual masterpiece. But if the website takes thirty seconds to load, then nobody is ever going to see it.

We have to overcome the frustration of being told no. Instead of being defensive and closed, “no” should be answered with, “Why not?” “How could we make this work?” or “Could we do this instead?” Understanding the abilities and limitations of those we work with allows us to compromise effectively, and create the perfect website where design and development meet in the middle.