9 ways to improve collaboration between developers and designers

Stereotypes aside, the fates of designers and developers are forever intertwined. Here's how to get everyone on the same page.
341 readers like this.
Collaborative agenda setting


This article was co-written with Jason Porter.

Design is a crucial element in any software project. Sooner or later, the developers' reasons for writing all this code will be communicated to the designers, human beings who aren't as familiar with its inner workings as the development team.

Stereotypes exist on both side of the divide; engineers often expect designers to be flaky and irrational, while designers often expect engineers to be inflexible and demanding. The truth is considerably more nuanced and, at the end of the day, the fates of designers and developers are forever intertwined.

Here are nine things that can improve collaboration between the two.

1. First, knock down the wall. Seriously.

There are loads of memes about the "wall of confusion" in just about every industry. No matter what else you do, the first step toward tearing down this wall is getting both sides to agree it needs to be gone. Once everyone agrees the existing processes aren't functioning optimally, you can pick and choose from the rest of these ideas to begin fixing the problems.

2. Learn to empathize.

Before rolling up any sleeves to build better communication, take a break. This is a great junction point for team building. A time to recognize that we're all people, we all have strengths and weaknesses, and most importantly, we're all on the same team. Discussions around workflows and productivity can become feisty, so it's crucial to build a foundation of trust and cooperation before diving on in.

3. Recognize differences.

Designers and developers attack the same problem from different angles. Given a similar problem, designers will seek the solution with the biggest impact while developers will seek the solution with the least amount of waste. These two viewpoints do not have to be mutually exclusive. There is plenty of room for negotiation and compromise, and somewhere in the middle is where the end user receives the best experience possible.

4. Embrace similarities.

This is all about workflow. CI/CD, scrum, agile, etc., are all basically saying the same thing: Ideate, iterate, investigate, and repeat. Iteration and reiteration are common denominators for both kinds of work. So instead of running a design cycle followed by a development cycle, it makes much more sense to run them concurrently and in tandem. Syncing cycles allows teams to communicate, collaborate, and influence each other every step of the way.

5. Manage expectations.

All conflict can be distilled down to one simple idea: incompatible expectations. Therefore, an easy way to prevent systemic breakdowns is to manage expectations by ensuring that teams are thinking before talking and talking before doing. Setting expectations often evolves organically through everyday conversation. Forcing them to happen by having meetings can be counterproductive.

6. Meet early and meet often.

Meeting once at the beginning of work and once at the end simply isn't enough. This doesn't mean you need daily or even weekly meetings. Setting a cadence for meetings can also be counterproductive. Let them happen whenever they're necessary. Great things can happen with impromptu meetings—even at the watercooler! If your team is distributed or has even one remote employee, video conferencing, text chat, or phone calls are all excellent ways to meet. It's important that everyone on the team has multiple ways to communicate with each other.

7. Build your own lexicon.

Designers and developers sometimes have different terms for similar ideas. One person's card is another person's tile is a third person's box. Ultimately, the fit and accuracy of a term aren't as important as everyone's agreement to use the same term consistently.

8. Make everyone a communication steward.

Everyone in the group is responsible for maintaining effective communication, regardless of how or when it happens. Each person should strive to say what they mean and mean what they say.

9. Give a darn.

It only takes one member of a team to sabotage progress. Go all in. If every individual doesn't care about the product or the goal, there will be problems with motivation to make changes or continue the process.

This article is based on Designers and developers: Finding common ground for effective collaboration, a talk the authors will be giving at Red Hat Summit 2018, which will be held May 8-10 in San Francisco. Register by May 7 to save US$ 500 off of registration. Use discount code OPEN18 on the payment page to apply the discount.

Jason Brock is a lovely fellow with a glorious beard and dark glasses. He wears a lot of plaid for some reason.
Jason Brock is an experience and visual designer based in Austin, Texas. As part of Red Hat’s Middleware Engineering Services team, he has developed branding systems and web experiences for many of Red Hat’s upstream community projects including WildFly Swarm, APIMan, & Arquillian Cube.


1 Comment

Everyone involved must have a "can-do" attitude. If there is a need that the designer has then the developers need to figure that out and if there is a requirement that the developers have then that must be communicated so that the designers can re-design around it. Simply saying "no" "we can't do that" "we don't have time" or anything like that does not make any progress for anyone. Say "we can work it out" "we can do it" "let's design and develop something great together."

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.