How To Work Better With Developers as a Designer
I frequently get asked by fellow designers: How do you work with developers?
The question used to sound so strange to me. It kind of feels like we put “developers” in one box and “designers” in another and the boxes are far apart from each other. Aren’t we both just people working on the same project together… ? What’s with the “us” and “them” mentality?
At the same time, I do understand why designers ask me this. I know that these relationships can become strained due to competing priorities and conflicting values.
I also know that I genuinely enjoy working with developers; one of my favorite aspects of my job is being so collaborative and building positive relationships with my co-workers. (Whenever I share this with either designers OR developers, they chuckle, stunned. Really? Yes, really. 🫢)
Below, I’ve deduced my thoughts down to what I believe are the most important steps in cultivating a collaborative working environment between designers and developers. My goal with this list is to give you some actionable, concise steps so you feel better guided when approaching working relationships with your developer co-workers.
Cultivate an appropriate sync cadence
How often are you meeting with the developers on your team? Do you mostly work synchronously or asynchronously?
I highly recommend regularly scheduling to meet with your team’s developers. At a minimum you should be performing these tasks together for each project: feasibility, developer handoff and design QA.
During a feasibility meeting, you should be running through the project at hand (preferably with a PM) so that the developer gains a sense of whether the client’s ask can be implemented or not. At this point, the developer has already been included in the project details but they haven’t seen designs yet. This is a chance for you to explain how certain interactions and features work. It’s also the time for the developer to ask you questions.
Developer handoff is when you pass your completed designs over to a developer so they can implement them. At this stage, your designs should not be a surprise to the developer. Hopefully, you’ve had communication throughout your process so they know which things have changed due to feasibility limitations, design adaptions or client expectations. This is your chance to go through any last questions before the developer starts implementing your designs. Here are two great YouTube videos going into more detail.
Design QA is performed once your designs have been implemented. I recommend doing this until you feel that what the developer has implemented matches your designs and the designs match what is implemented—to a T. That could be one session, two, or even five. It depends on the scope of the project. I’ll also add: I prefer to look at the developed product asynchronously so that I can write notes on what needs to change. Once my notes are solidified, then I meet with the developer to discuss what I found. Your process may be different from mine.
If you’re not doing these—or you’re doing these asynchronously—simply having these meetings together will strengthen your working relationship. Start advocating for increased synchronous communication between design and development if you’re not meeting regularly already.
Have a design system in place
A design system will make your work more consistent, easier to implement, and therefore easier to hand off to a developer. Things like margins, padding, font styles and color styles should all be set in stone — unchangeable — from project to project, unless you’re doing a rebranding.
If any of these are ambiguous or inconsistent, these foundational components are going to make a developer struggle to execute your work. They’ll be busy guessing whether you want the padding between two elements to be 29 pixels or 30 pixels because it’s inconsistent throughout the design.
For some designers, auto layout may come into play here so you don’t have to manually adjust an article grid whenever your copy becomes longer than anticipated. For other designers, you might just need to develop a more meticulous eye.
If you’re not sure where to start when making a design system, this is a great resource.
Know how to communicate well—and be curious
Design to developer talk probably doesn’t come to you naturally. It didn’t for me at first, and I still sometimes struggle to communicate myself. To know how to communicate to a developer better, listen to them more.
What are they working on? What are they concerned most about? What problems are they fixated on solving?
By listening to them and understanding their perspective on the projects you’re a part of, you’ll start to anticipate their questions, conundrums and goals, which will all help you communicate with them.
This may not be your jam, but I personally became interested in learning how my designs were being built. Even though I’m not a coder by any means, I try to code because I want to see what it feels like to implement the thing I designed. It continues to make me a better, more holistically trained designer.
I know it can seem like a daunting task: you want to improve the relationships you have with developers but you’re not sure where to start because the problem seems so vague and dependent on the situation.
If that’s you, you’re far from being alone. When I started my design career, I often felt like an imposter, afraid that I’d get called out for not being knowledgeable enough. But it’s possible to turn things around. These are things that I’ve discovered through trial and error. I hope they prove helpful for you too.
If you’re a designer who has positive relationships with developers, what has worked for you? Do you agree with me? Disagree? Or if you’re a developer … 😬 What are you doing here?
Anyway, see you in the next one!
