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, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe of interest to you, too:
- Next: On Writing Better Markup
- Previous: Definition of Web Developer
- More under Web Development and Art and Design, or from 2019
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.