The Developer’s Fallacy of Close Collaboration With Designers

Published on October 1, 2019 (↻ May 10, 2023), filed under Development and Design (RSS feed for all categories).

It’s a popular sentiment: As developers, let’s work close and closer with our designers. It’s an old idea: We’ve wanted this in 1999 as much as a decade ago as much as today. And it’s a great idea: Working together makes sense and is awesome!

The benefits are substantial, indeed, as, following others, I could only repeat at my talk at WWRuhr #44:

For one, when we work closely with designers, we improve the understanding and relations between the two disciplines. No more wondering what the intent behind that mock was, or the use cases for that graphic.

For two, following from one, we work together more efficiently. No more editing of graphics a designer shared in the wrong format, or uncompressed, and no more extra turns after we received the latest Sketch file.

But (reflecting the theme of respective talk I gave), there are also good reasons for not working closely with designers.

The biggest reason is to avoid constraining and limiting the designer, inadvertently curbing or even killing creativity. (Think design potentialities!) “No, here and there we do it like this.” “We already have this element in Bootstrap, so let’s not reinvent the wheel.” Or, the coffin nail: “We can’t do this.”

We like to think of ourselves as totally rational, well-intentioned champions of the user and the enterprise when we do this, but there’s a fine line to becoming overly comfortable and mutating into rather domineering developer-heroes.

Another reason is to challenge ourselves, to turn design creativity into development excellence. We can’t do this when we push our designers to follow dull and boring design patterns (no?) just because that is consistent, easier to develop, and maybe even faster. These are good reasons, yes, but as suggested with the “fine line” it can also backfire, as consistency is not everything, there may be something even easier and faster to develop, and we may well hone and improve our skills in the process, all the while allowing the designer whole reign over their own domain.

Now, I’m not going to dissect this further, for the point is this: When we developers opt for, ask for, insist on close collaboration with designers, the matter is not nearly as clear-cut as it always seems.

What does that practically mean, then?

First, the matter is more acute at the edges of our fields. If we have a team of world-class designers we definitely don’t want developers to determine the design agenda, because that would lead us to waste our designers’ potential (and maybe our designers). On the other end of the spectrum, if we have a team of junior designers, developers, especially senior ones, may certainly guide them.

Second, as the first point demonstrates, it depends. (The inconvenient truth in our field, too, is probably that much “depends.”) It can make sense to pull our designers close. It can make sense to leave them all the freedom in the world. Just here, too, we have to look at the situation, think, and decide, for it’s a fallacy to think that close collaboration with designers was a must.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)