Published on March 17, 2016
Designers are a precious and proud people. I’ve met a few who would rather have pixel-perfect builds than let their colleagues work normal hours — that’s not a collaborative process, it’s a dictatorship.
The expectation that developers ruin the hard work of us designers is poisonous. Developers are doing a tougher job than people give them credit for. Instead of complaining, designers should figure how to work with them to make this difficult job easier, and how to work with them to create the most efficient process for everyone.
If this ruffles your feathers, then you might be the one who’s treating a developer unfairly.
I can’t work on a team where people don’t have respect for the work and skills others have. All of our jobs overlap. UX Designers, Visual Designers, Developers, and Project Managers each have skills the others do not, but they also overlap.
This isn’t just an empty ‘Hey, I respect you’ and a thumbs-up, it’s allowing people to take ownership of their own work, and giving them control over your work too. Even though they’re a developer, they may be okay designing something from a quick sketch based on your visual language without any design input!
Mutual respect gets rid of the us and them mindset. It helps develop better relationships with your colleagues by fostering a happier environment.
Design is about communicating something in the most effective and appropriate way possible. Fuck this nonsense about it fixing the worlds problems. It doesn’t.
When working with developers, this means reaching pixel-perfection on that new Halfords site is a low priority. The highest priority is making sure the message you wanted to convey is conveyed in a way that doesn’t look broken. That’s it. Getting miffed about kerning is just going to make you angry, and the developer frustrated.
My development critique is a two-step process:
If the answer to #1 is ‘yes’ and the answer to #2 is ‘no’ then it’s okay for that to go live. That’s not to say I’m flimsy about the details… Rather, I think it’s more important time to sweat the big picture stuff instead of worrying about the border radius of that text input in the footer of a website.
The highest priority is making sure the message you wanted to convey is conveyed in a way that doesn’t look broken. That’s it.
Development is a rigorous process. It requires lots of planning, tools, and applications to help it flow smoothly. I’m not saying us designers have it easy, but I’ve never seen a visual designer have to work until midnight on a Friday because the recently deployed application doesn’t work on some obscure mobile OS.
By saying ‘yep, I’ll create a GitHub issue in that branch’, you are making a developers job easier with very little effort. This is the environment they are used to, and it’s easier to figure out how to create a Jira ticket with an attachment than it is for a developer to find the exact folder where my most up-to-date designs are.
I’ve never seen a visual designer have to work until midnight on a Friday because the recently deployed application doesn’t work on some obscure mobile OS.
I’ve worked with designers who assumed their time was the most precious on an entire team, but it wasn’t true. I’ve been busy, but I don’t think I’ve ever been as busy as a developer, so I trust that the thing that they’re doing is going to get done.
To help this in the past myself and developers have sat down together and gone through the list of tasks — bugs included — and prioritised all of it. It provides an opportunity to understand what takes time in development, figure out whether a feature is worth the effort, and for us to negotiate the importance of tasks.
Developers can be their own time managers, they don’t need a looming designer asking them when that typographic hierarchy is going to be fixed.
What’s worse than being dropped into a project at a crucial stage? This is when many developers in an agency environment are called in. Designers should be proponents of collaboration, getting developers included at an early stage.
This isn’t just inviting them to planning meetings, it’s involving them in workshops, sketching, design critique, and anything else you are doing.
A developer’s insights are valuable from the start, and the feeling of involvement from being present will make them respect and love the project even more.
We’re not an altruistic species and I’m not going to pretend to be either. I don’t do the above for selfless reasons, I do it because it makes life better for me. By making developers more design-aware, by making our processes more efficient, and by having a happier team, it makes my life easier.
If I adapt to their processes, they adapt to my processes. If I respect their time, they respect my time, and if I get them involved, they’ll get me involved too. It works both ways. We all win.
Did you enjoy this post? I'd love to hear from you on Twitter.