The Developer’s Fallacy of Close Collaboration with Designers
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!
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.
Figure: To work together you don’t need to sit on another’s lap. (Copyright King Features Syndicate, Inc., distr. Bulls.)
I’m Jens Oliver Meiert, and I’m an engineering manager and author. I’ve worked as a technical lead for Google, I’m close to the W3C and the WHATWG, and I write and review books for O’Reilly. Other than that, I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have questions or suggestions about what I write, please leave a comment (if available) or a message.
Have a look at the most popular posts, possibly including:
Looking for a way to comment? Comments have been disabled, unfortunately.
Perhaps my most comprehensive book: The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.