Getting Along with Developers: Tips for Better Understanding

October 10, 2016

A good developer is possibly one of the best allies a UX designer can have. Given that designers and developers spend a lot of time working closely together on projects, it seems inevitable that they would develop close relationships with one another. However, while these relationships should become powerful alliances, struggles often occur between these team members.

As designers, we may find it difficult to see a developer’s point of view, which is ironic because we constantly strive to put ourselves into other people’s shoes and see things from their perspective. We are obsessed with doing usability testing and user research to understand users and customers, but, for some reason, we don’t always apply the same approach to understanding our teammates.

In recent years especially, there has been a lot of talk about having empathy for the user. Strangely, developing empathy often doesn’t extend beyond users and homeless kittens. What about having empathy for the people we work with on a regular basis? Applying the same approach to your teammates will go a long way—especially when it comes to developers. This may seem like a daunting task, but as with most things, you can break it up into smaller steps and develop understanding and empathy over time. Here’s what you should start doing.

Champion Advertisement
Continue Reading…

1. Learn what developers do.

Many designers have no idea what developers do. The stereotype is that developers think differently from designers and live in a world of undecipherable code. So, when a developer says something cannot be done, too many designers tend to accept that and move on. Instead, as a designer, you should ask why something can’t be done and find out whether there are ways around the obstacles.

It is even rarer for designers to truly understand what developers do and actually know how to code. While there is no need for you to become a developer yourself, learning the basics can take you a long way. First, this results in superior design solutions because you’ll have a better understanding of what is possible and what isn’t. Second, you’ll be able to communicate better with developers about their work. Third, and probably most important, it will improve your professional relationships with developers because you’ll gain their respect.

How often have you talked with clients who only had a vague idea of what you do? They tend to be the ones who come up with the most unreasonable requests—not because they want to be difficult, but because your work seems like some sort of voodoo to them. This probably frustrated you and made your work even more difficult.

At the opposite end of the spectrum are clients who know exactly what your job is and how you do it; clients who ask you about your personal process, the problems you’ve encountered, and your reasoning. Those clients are probably a joy for you to work with.

Why would this be any different for developers? Like everyone else, they’ll work harder and better if they know someone’s paying attention.

2. Ask developers for their thoughts—and listen.

It’s becoming more typical to involve developers from the very beginning of a project. While this is a great idea, “involve the developer” sometimes tends to be interpreted as “just have the developer in the room.” People may ask for their opinion and thoughtfully nod their head, then just move on. Not to mention, they mainly ask developers for their opinions on development, not user experience.

This is a big mistake. Many developers have coded just about every type of Web site. So they may have a vast amount of knowledge that no one is tapping into. Just because developers are not UX designers or members of your target audience doesn’t automatically mean that their insights are irrelevant. Often, unexpected and brilliant insights or solutions come from developers. The key is to listen. This doesn’t mean that you should run every design decision by a developer, but open the conversation by asking, “Hey, what do you think?”

Furthermore, fostering a team culture in which developers know designers value their opinion is very beneficial. The most successful, enjoyable projects are those on which all members of the team, including developers, can contribute at any point in a project and run their ideas by others, knowing that their contributions will be valued. Developers tend to be especially good at connecting the dots and spotting solutions that haven’t occurred to anyone before, but they can do that only if they know you’ll hear what they have to say. A developer is not there simply to make the designer’s vision come to life. A developer should be an equal partner on the team.

Again, think about instances when you’ve worked with a client who told you exactly how everything should be. How enthusiastic were you about those jobs? I’ll bet you prefer clients who trust your expertise and are open to suggestions. Why would developers be any different? Take their feedback on board.

3. Do not be a diva.

Some designers are notorious for being divas. If a Web site doesn’t work, it’s the developer’s fault. If the developer implements only 50% of the proposed design on the live site, the developer is the devil. If something is off by one pixel, it’s the developer’s oversight. It’s completely unreasonable to expect perfection at the beginning of development. As a designer, you go through many iterations before reaching a final design for a product. You do a rough. You get feedback. You implement. You make changes. You iterate these steps several times. So why give a developer only one shot?

One thing any developer would tell you is that what they code will never be exactly what you’ve designed. Pixel perfection is impossible simply because different browsers render pages differently. Plus, the software that designers use renders differently from browsers. What developers can do is code the front end as close to the design as possible—close enough that most people won’t notice the difference. Doing this is an art in itself and requires both time and adjustments to ensure consistency.

Nevertheless, designers often expect developers to implement both the functionality and the visual design correctly in one go. This is almost impossible. So be patient and understanding. Nobody wants to work with a talented jerk.

4. Connect with developers on a personal level.

This advice holds true for everyone in your working environment. However, developers tend to be excluded from personal relationships more often than other people on a product team. Teammates tend to ask them about the world of technology, but developers have other interests, too. Try to connect with developers on a personal level, and see if you have something in common besides work. Do both of you support the same soccer team? Grow organic cabbages on your balcony? Do your kids go to the same school?

Making a personal connection will strengthen your professional relationship. You don’t have to become best friends, but if that happens, that’s great! But always remember that developers are people, too. They’re not just tools for you to use when you need them.

5. Developers are unique people.

Have you ever been in a romantic relationship with a partner who treated you the same as your predecessor? Never mind the fact that you don’t like carrots. His or her ex loved them, so you got them on your plate along with a lecture on why your current opinion of the vegetable is wrong. It kept happening despite the fact that you repeatedly said how much you dislike carrots. That relationship probably didn’t last very long.

Yet when a developer leaves a team and a new one takes his or her place, designers may behave similarly to the person I just described. A new developer may be considered bad just for not behaving exactly like the old one, get unfairly compared to the previous developer, and get lectured for doing things differently. Is it any wonder such a professional relationship would turn sour? Just as in personal relationships, you should remember than no two developers are the same. Instead of acting crazy and projecting your habits onto them, learn about them. Start all over again from the beginning!

Learn how a particular developer likes to work. Just as all designers have their own variant of the design process, developers have their own approaches. Just because you’ve worked a certain way with a previous developer, that doesn’t mean you’ll work in the same way with all developers. Start each new working relationship with a blank slate. Learn about new people, explain your process, and ask questions about theirs. Think about different ways in which you and your developers can fuse your different processes to work together.

You should consider more than just the process of collaboration. Think about your communication preferences as well. Do you prefer to communicate via email or phone? What happens if you are used to receiving a reply within an hour, but a developer checks his inbox only once a day, around noon? You can’t expect anyone to adapt fully to you. You have to find a middle ground. Compromise is key.


To sum up, a professional relationship with a developer is a partnership—or it should be. The relationship between a designer and a developer is very similar to that of a copywriter and an art director, working together on a project in the world of advertising. While each has a unique role and tasks, they collaborate to achieve the best results. The copywriter comes up with the idea and the copy, while the art director’s visuals take it to a whole different level. UX designers are similar to copywriters, in that they come up with solutions. But, ultimately, the developer’s execution may either save a mediocre project or destroy a good one. There’s no doubt that good professional relationships with your developers will improve the quality of your work. Next time you work with a developer, think of him as an art director, not a handyman. 

Senior Digital & UX Designer at CMG Worx

Sydney, New South Wales, Australia

Vera KravchukVera is a UX designer with an interest in psychology. She has written content for digital design courses, spoken at the conference What Do You Know in Sydney, and written a book on UX design that will be published in 2016.  Read More

Other Articles on Teamwork

New on UXmatters