In their shoes: designers understanding developers
This article is a follow up of my Should designers code… or should developers design? article and an extract of my talk given at SwiftConf’17.
For a long time, developers and designers have been considered like two creatures coming from different planets or, even worse, enemies. But truth is, designers and developers are not so different from each other. Having a better understanding of what the other does can really play a huge part when it comes to building products together. At the end of the day, we all develop and we all design something.
Do designers understand what developers do?
There’s a bunch of designers out there who don’t really have a clear picture on how things are built or how complex and time consuming they can be from the implementation point of view. They might as well spend countless hours producing some awesome designs and Disney-an interactions only to be told by the development team that what they’ve done can’t be built.
The frustration that follows this behaviour contributes to the poisonous thinking that developers simply don’t get it and love ruining our perfect creations.
Instead of blaming the developers because something isn’t doable or the final design looks nothing like what we originally produced, let’s start applying the same empathy we use with our users to our colleagues.
N.B. Everything can be built, but it may just be out of the current scope, take too long for that iteration, or needs prerequisites that have to be built beforehand.
How to improve software development understanding
Let’s step into the developers’ shoes for a moment and try to understand what they face in their day to day tasks.
No, I’m not saying designers should code. But it won’t hurt to know just enough to be dangerous.
I’ve been learning front-end development for the past few months and it completely shifted my mindset. Getting my hands dirty by digging into code has helped me understand better the medium I’m designing for as well as creating more empathy with the developers.
For example, there have been occasions in the past where I’ve been blaming developers for not fixing things as I thought it was just a two minutes fix. Spoiler alert: in general, there’s no such thing as a two minutes fix.
Once I dug into the codebase myself, I realized that every little piece of code is like a small tassel into a bigger domino game.
Understanding how things are built can help you make more informed decisions. Every time you’re not sure about something, don’t be afraid to ask a developer for help. They’d be more than happy to discuss technical constraints with you as well as helping you out by setting a development environment if you wish to contribute with code.
Learning the platform you’re designing for not only makes you a better designer but can also earn you respect from the developers in your team 😉 .
Introduce tools and practices to help bridge the gap (and improve your design workflow)
Lately, the design world is experiencing a sort of Renaissance thanks to movements like Brad Frost’s Atomic Design — that borrows concepts from object-oriented programming — and the introduction of ever evolving new design tools that let us move away from the production of old static PSDs.
Atomic design
For those of you who are not yet familiar with Atomic Design, to summarize it really short, it’s an effective methodology for creating design systems based on building blocks known as Atoms, Molecules, Organisms, and Templates.
“We’re not designing pages, we’re designing systems of components.”
Stephen Hay
I invite you all to actually read the book. It’s really insightful and can open your mind, maybe even set up a book club with your colleagues like we did at carwow. In fact, after the book came out, all together with developers and product managers, we decided to gather every week to discuss a chapter and then take actions.
Lucky for us, we already had a live styleguide in place, but Atomic Design has helped us breaking down our design language into a cohesive, hierarchical system that enables better maintenance, faster prototyping and ideation, and above all gives everyone a clearer picture of what the current state of our design is.
Also, the co-creation of a style guide is an example of great cross-disciplinary exercise as it helps both the designer and the developer by promoting understanding of each other’s job. The act of creating the style guide together is what is most valuable to this relationship between designer and developer, not necessarily the end product.
Sketch
Since its appearance on the design market, Sketch has become the de facto tool for designing digital products. This is because of its intuitive interface as well as the ability to reuse UI kits and its components across multiple projects and the overall structure that mirrors a front-end coding mindset.
In fact, the thinking behind the creation of symbols, for example, is very similar to the thinking of a front-end engineer when it comes to implementation.
Sketch also allows you to make your design responsive thanks to the object settings which helps you getting immediate design feedback within the design tool.
These similarities show how lines between designers and developers are becoming more and more blurry.
Abstract
As already said before, design and engineering workflows are slowly creeping towards each other. Abstract is helping to redesign the design process.
This tool can be considered the GIT for designers which enables version control, files tracking and the best feature for a designer: being able to visually compare changes in a Sketch file. All of this without having to open Terminal and use command line and Github.
Replicating GIT workflow is something completely new for designers. Branches, commits, merges… these were all terms related to just developer’s word. But now, thanks to these emerging tools, we’re finally part of that world too.
Conclusions
Designers and developers have so much in common and, only by learning each other’s process and quirks, we can definitely produce better work.
Thanks to the power of collaboration, designers can have a better understanding of how things work, while developers can understand better the reasoning behind certain design decisions.
The more we understand what our colleagues do and the more we learn from them, the higher the chance of creating a better solution. Let’s learn how to appreciate each side for what they contribute and we’ll all be the better for it.
You can also read about the counter article: In their shoes: developers understanding designers.
If you enjoyed this article, please show me some love by clapping 👏
Follow my casual thoughts on Twitter
See my collection of pixels on Dribbble
