When I graduated from university I did what most graduates do: I went in search of a job. At that time, all I could get were a few unpaid internships so I sustained myself by working part-time as a waitress.
Because I was new, I got lumbered with all the odd-jobs.
I went in between posts depending on where they needed me that day.
Some days I’d find myself at the bar, pouring pints and attempting to banter with the local punters.
Other days I’d be waiting tables, hoping they liked me enough to give me a tip.
Most of the time I was in the back making ice cream desserts and nabbing the odd bit of chocolate.
I got to interact with the bar staff, the wait staff, the chefs, and dishwashers (that is people who wash dishes, not the machinery).
What I always found amusing was the complaints coming from all of them.
The bar staff would say, “Why do the chefs always come out here and demand we make them drinks when they can see we have a full bar? Why can’t they just get their own drink?”
The chefs would say, “Why are the waiters so rude to us? Don’t they understand that we’re half the reason for them getting their tips, while we’re in the back getting nothing?”
And the waiters would say, “Why don’t the bar staff get our tables’ drinks ready fast enough? We get so much crap from customers when it’s them who are being slow”.
They were all right in their gripes. But they were also very wrong.
What the bar staff don’t see is that the chefs are always busy. They never get a break, and if they do it’s just about long enough to get a drink to sustain them through the heat and pressure of a kitchen.
The chefs didn’t see that the waiters are the ones who bear the brunt of customer complaints if the food is cold, or the meat isn’t cooked right. They’re treated like it’s their fault and the chefs hear little of it.
And the waiters don’t see that when the bar is full, the bar staff have to prioritise the people standing there giving them the death stare over the tables’ drinks because, well, the wait staff could easily come around and make their own.
Thankfully, those restaurant days were short and I’ve been fortunate enough to make a living as a designer for the last 8 years. But that experience taught me a lot about the difficulties of having different specialists working towards a common goal.
Because the food industry isn’t alone in its conflict between job roles.
I’ve worked with many developers who have a few gripes with the design folk:
- “All they care about is making something pretty. They make interfaces that are impossible to code!”
- “They always give us the ‘best case scenario’ with content. They don’t think about edge cases, empty states or interactions”.
- “They get all the glory. Everyone ooh’s and aah’s over the pretty interface but nobody cares about the amount of work I put in trying to code the thing”.
And, you guessed it, it works the other way around too:
- “Developers don’t care about the visuals, I spend so long on the details and they just ignore them”.
- “They tell me the way I’ve designed this is impossible, but I know it isn’t — they’re just being lazy and using my lack of technical knowledge as an easy way out”.
- “They won’t use their initiative. If I don’t provide something it seems like they deliberately make it look like crap to prove a point”
And just like in the restaurant, both sides are right in their gripes. But they are also very wrong.
So where do we go from here?
Well, since this article is speaking to developers, I’m going to address the problems you have with designers and what you can do to help overcome them.
This is not me saying that it is the developer’s job to fix the issue. If I were speaking to designers, I’d focus on the other side of the coin.
O.K., with that disclaimer out of the way, let’s see what we can do to help fix the issue of designers and developers working together.
1. First, let’s try to change your mindset
I went to design school for 5 years and then worked in a design agency. So I get it, some designers can be a little, well… annoying.
You have designers who think design can single-handedly change the world. And then you have designers who think fussing over a few misaligned pixels is a better use of time than designing new features that you can implement.
However, I’d argue that this can be a good thing. Designers should strive for the best-looking design they can. They should strive for the most seamless user experience.
Just like developers should strive for clean, maintainable code, or proper stress testing before a launch. Just like they should strive for cross-browser compatibility and baked-in accessibility.
It doesn’t mean all of these will happen. In reality, if both sides aim for perfection, you’ll meet somewhere in the middle. And that middle will be a far better product than if both sides did the minimum that was required.
Teams that have designers passionate about design and developers passionate about development get the best results. As long as both sides respect the work the other is doing and don’t pass it off as fluff or not important.
In teams like these, the designer can push for those little details that make something look super polished. The developers can then push back with concerns about degrading the website’s performance. And if you have an open dialogue between the two teams, you can always find a compromise that can be beautifully functional, without affecting the overall performance.
So instead of seeing designers as frivolous beings who only care about websites at a superficial level, see them as people who can help you become a better developer by pushing you to find solutions that you wouldn’t have otherwise.
And yes, it works both ways. But by changing your mindset, you’re one step closer to more effective collaboration. And remember, people tend to replicate how they’re treated by others, so start with you and the rest should follow.
2. Set expectations at the start
You’ll be amazed at how just having a conversation with a designer at the start of a project can help. If we start with the mindset of “designers/developers are annoying, I bet they’re going to screw up the project” it’ll become a self-fulfilling prophecy.
That’s why it’s really important to clear the air before a project begins. A positive mindset from both sides will help the project run much smoother.
You can talk about things like:
- How you both typically work on projects. Share your experiences with past projects, what worked, what didn’t and see if you can find any common ground.
- Ask if they’re ok with you being involved in the design process. Developers play a vital role in the design process. Every single project where I’ve worked closely with a developer from the start has ended up being a much more stable, usable product.
- Give designers permission to push back on any decision. The goal is to come up with the best product as a whole and you can only do that with an open dialogue.
- Reassess the goals of the project and make sure you’re on the same page. This will help when you’re debating the best way to do something. It’s not You vs. Them, it’s which solution is closer to the goal.
If you give designers permission to push back and make them feel like they can talk freely and openly with you, they’ll extend the same courtesy to you. You’re both solving very real and very different challenges so there’s no room for defensiveness or an over-inflated ego on either side.
3. Communicate often and strive for discussions over orders
Designs are often seen as the ‘single source of truth’. Whatever the designer has chosen should be the final decision because a designers job is to, well, design.
In reality, the design is simply a designer’s most educated guess on how a product should look and function.
When it gets into development, things should change. As a developer, you have a unique perspective on usability and functionality. You should speak up when you think there’s a better way to do something, rather than just blindly copying the designs.
But at the same time, if you do deviate — make sure you have a conversation about it beforehand. If you don’t, how will the designer know if you’ve done something different because of a genuine reason, or whether it was simply a mistake?
You can start the conversation by saying something like “I’m not sure about this, because XYZ, what do you think about doing it this way?” This will go a long way to viewing the project as a collaboration, rather than a production line.
And at the same time, by framing it as a discussion rather than saying you don’t like something with no context, it will help the people you’re working with see it as a constructive comment, rather than an attack on their work.
If you assume the best intentions of everyone you work with, it’ll help you frame your feedback in a positive, constructive way, rather than a passive-aggressive dig on their abilities.
Remember, there’s a lot of pressure in the tech world to be perfect. Designers should code. Developers should design. Every website needs to be fully accessible to everyone. If a colour fails the contrast checker you’ll hear about it with a swarm of emails, twitter mentions and comments. Every decision should be able to be justified in court.
We’re a passionate, opinionated bunch and while I applaud the efforts towards achieving perfection (see point #1), sometimes we need to cut each other some slack and look towards teaching instead of berating.
If a designer forgets a hover state, or doesn’t consider how something might work on mobile, instead of assuming they’re out to get you and then going and ranting about ‘ruddy designers’ on Twitter, try asking them their opinion.
“Hey designer, what do you think these buttons should do on hover?”
“Hey designer, I’ve got a few questions about the design, mind if we schedule a call next week so I can get your opinion?”
It’s a simple change and will lead to a far better outcome and a far more pleasant experience.
Assume the best intentions of everyone.
4. Learn the basics of design
And finally, consider learning the basics of design to help you communicate better with designers.
You don’t need to become a designer, but knowing a bit about how design works and what a designer’s job entails will help you be more compassionate and do a better job during the development.
How? Well, you’ll notice things you didn’t notice before. Those little details that you didn’t see before will now be glaringly obvious. You’ll understand how some minor tweaks in the visuals can make a huge difference to the overall feel of a website or a product.
You also won’t need to rely on a designer for every new feature, or every hover state. With a small amount of design experience, you can get really far.
Remember at the start of this article when I was talking about doing all the odd jobs at the restaurant? What if when everyone started at the restaurant, they had to do a job like mine. They had to try each core job role. It would give them a better understanding of how the company works and how everything fits together. They’d be more empathetic to each other and efficiency would likely go through the roof.
The waiters might make their own drinks if they see the bar is full. The bar staff would prioritise tables that had been waiting a long time for drinks. The chefs might grab their own glass of water if they can spare the time.
If everyone just tried each other’s jobs, they’d see the hardships they have to go through on a daily basis and likely be far more considerate to them when making their demands.
And it’s exactly the same with designers and developers.
Designers don’t need to be developers, but they’ll be able to work more effectively with developers if they understand a little code and the issues developers face on a day to day basis.
And developers don’t need to be designers, but learning the basics of design will help them feel more confident when faced with any unknowns, and you’ll be more empathetic to what a designer is being judged on in their job.
But at the end of the day, communication is about empathy and understanding. It’s not about being competitive, or being a hero, it’s about assuming the best intentions and working as a team.
