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 together with world-class developers, we definitely don’t want to have developers determine the design agenda, because that will lead us to waste our designers’ potential (and maybe even 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 a web developer and author. I love trying things, including in the fields of philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a suggestion or a question about what I write, feel free to leave a comment or a message.
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out some of the most important aspects of such CSS. (Also available in a bundle with Upgrade Your HTML and The Web Development Glossary.)
Looking for a way to comment? Comments have been disabled, unfortunately.