A developer's guide to working with designers
As a frontend developer, you’re bound to have a few horror stories from working with designers. Whether it was a un-implementable design tossed onto your desk, or a new screen within the app that has buttons ever so slightly different from the ones you spent hours styling, we’ve all been there.
So, how can we learn from those experiences and work effectively with designers? Fundamentally, I’ve found that most of these negative experiences come from a lack of communication and alignment. The following list contains some of the things I try to keep in mind when working with designers that I’ve found make my work easier and better.
Understand where designers are coming from
Many of us have spent years on our craft, at school, and at work. Our designer colleagues have spent years on their craft as well. While this is probably obvious to many of you, it's still worth mentioning.
We've spent the time getting better at building robust, functional, scalable software. They've spent their time thinking about how to solve specific design problems in ways that are easy to use and understand by users. It’s key for us to understand that design is not only pushing pixels around and making things pretty.
Great design, like great engineering, while taking a ton of time, skill, and effort, isn't usually noticed by end users. Sometimes teammates don't notice it either. Thus, we need to remember that a design decision that seems unimportant or frivolous to a developer may, in fact, have a deeper reason for its existence.
Get involved early in the design process
Communication is key. If you're involved early on, you'll already know which problem is being solved. If you know how to solve it from a design perspective, then you’ll be able to do some of the building before pixel-perfect designs are ready. You can get ahead of design and build out things like data structures, API methods, page layout, custom components, et cetera.
Additionally, if you're involved early on, you'll be able to flag things that look like they might be very technically difficult. If that's the case, it’s worthwhile to talk about that item and explore alternate solutions. For example, the new design might call for building a custom date-picker component. In that circumstance, you might bring up that using a pre-built component could save a few weeks of development time.
Finally, your involvement with design early on will help in exploring edge cases. These might include things like animations, transitions, hover states and error states.
Get clarity on which stage a design is at
The realization that what you thought was a pixel-perfect final design, is actually a concept, is a painful one. Make sure you understand what stage a design is at. If it’s only a concept, you may not want to start work on building out components just yet.
Keep design in the loop when building
Like how a lack of communication from design can result in issues later on, the same can happen if you only bring in design once you've already shipped. In general, developers and designers intend to ship great product quickly, so keeping in sync throughout can avoid some nasty surprises at the end.
Different channels are better for different types of communication. You might like to get bug reports through JIRA. You may like quick questions via Slack, and longer questions via email. Conversely, the designer you’re working with may want design-specific questions on Zeplin, and bigger conversations in a 10-minute meeting. Figure that out, and get it communicated.
Be clear about what kind of feedback you’re looking for
When bringing a designer into the development process, make sure to contextualize what you share with them, as well as what you’re looking for from them. For example, you might have shared the login screen to make sure that the user flow is correct. Or, maybe the reason you've shared the login screen is to get feedback on the login button hover state. Your designer won’t know which type of feedback you're looking for, and it can be frustrating to get one type of feedback when you’re looking for the other. So, make sure you’re explicit.
Understand that design doesn’t stop when development begins
No matter how thorough and pixel-perfect a design is, or how many prototypes have been created, a design isn’t the real thing. The product will always be the source of truth.
As developers, we do things like pull reusable components out of a page design, fill in different screen sizes and add in interactions, error states, and hover states. On top of that, things always change when faced with real users. This is totally OK, and we shouldn't be too miffed if it happens. Instead, develop the frontend with an eye to how it may change in the future.
Spend the time and energy to explain things
You’re on the same team, and will have to work together for months, if not years. When you invest the time to explain things like trade-offs, you’re creating the foundation for better teamwork down the line.
For example, a designer may present you with a design concept that’s super difficult to build. Instead of saying something like “that’s not possible” or “that’s unreasonable”, understand this isn't as obvious to your designer as it is to you. Instead, explain the tradeoffs involved. You might say something like this:
We can do the first option, but it’ll take 4 weeks because of X reason. However, we can do option two and that’ll take three days because of reasons Y and Z.
On the flip-side, you should also expect the same level of clarity when asking a clarifying point about a design.
Use tools to make good communication easier
An important caveat: a great process is not tossing a design, or a software build, over the wall and then using software to paper over a fundamental communication gap. Tools like Zeplin for designs and Pastel for websites help, but they’re only part of the story. That said, it makes a world of difference if you can have discussions contextually on designs and the real build, without having to tap each other on the shoulder to get clarity.
These are some of the tips and tactics for better designer-developer collaboration that I’ve picked up over the years. Keep in mind that this is an ongoing journey and that you’ll need to actively work on these things throughout your career. That said, this list should act as a good start.
Got any tips that I missed? Let me know in the comments.
A big thanks goes to Adrien Coquet from the Noun project for the incredible icons.
