How to work well with developers
I started working at a startup when I was 19. I was originally in the marketing department, then, after a year, in the product department.
Learning on the job and designing for an app with a steadily growing number of users was scary enough, but what most terrified me were the developers. Our developers were very talented, had years of experience, and were extremely vocal about their opinions.
Every time I had to lead a product design review meeting, I’d feel a ball in the pit of my stomach, knowing that my hard work was going to be scrutinized by them. There was also a mutual departmental disdain; the developers felt that we were dictating the company direction from our ivory tower, and we felt that they were unfairly antagonistic.
It seems that strained relationships between developers and UX designers, as I was experiencing, is a common issue in companies. As I grew into my new role, I decided that my job would be much easier if–instead of trying to assert control (something hard to do as a 20-year-old just starting in his job)–I invested in maintaining good relationships with them. Just befriending developers made all my interactions with their department so much more collaborative, pleasant, and less scary. I also still keep in touch with a lot of them, so I’d say on a personal level it was worth it, too.
While good personal relationships with developers may help, keeping your departments as a whole on good terms is harder, and it’s important to understand where these tensions come from in the first place and how to diffuse them.
On more than one occasion, an argument ended because we realized that we had been saying the same thing for the last ten minutes and just weren’t properly listening.
What are the sources of this animosity?
There are a lot of reasons these two important departments can find themselves at odds.
In my experience, these were the critical issues that were causing the rift.
Developers want a seat at the table
I’ve often heard that programmers feel they have no say when it comes to the product they’re working on. Being handed features as a fait accompli, they have no say over what makes them feel like a cog in a machine, not a valued coworker.
This is also a problem that can be baked into company culture. Not emphasizing teamwork or maintaining rigid divides between departments only deepens this divide.
Working on things developers don’t like is awful
Coding takes a long time. Coding a feature you don’t like takes much longer. Having to stare at each line of code that comprises something you didn’t want to build in the first place just creates resentment towards the designers and the company.
When the product department feels like a black box, and you have no context for why these features are needed, you’re basically doing grunt work.
UX designers don’t always react well to criticism
There are a lot of healthy (and unhealthy) disagreements between the teams, which can be hard not to take personally. For example, I realized that a lot of the anxiety I had around running product design review meetings was that, when the feature I had worked so hard on was critiqued, it would feel like a personal offense. As a result, I’d get defensive.
When working together, many disagreements are often escalated or unresolved because neither side is willing to consider the other’s case. Sometimes, we’re so invested in being right that we aren’t able to listen. On more than one occasion, an argument ended because we realized that we had been saying the same thing for the last ten minutes and just weren’t properly listening.
In what ways are companies impacted when designers and developers are at odds?
It’s easy to shrug off interpersonal relationships in a company and say that not everyone has to get along. It’s true: We don’t have to be friends with everyone we work with.
However, tensions in the workplace can hurt the company by decreasing productivity, and strained relationships between product and development specifically can hurt your product in many ways.
Developers are less likely to be flexible to product needs
However our workflows are structured, there’s always going to be a small change that was overlooked, some copy or pixel tweaks we want to get in after development has started. I would often get told to ask developers to add product changes in as a favor.
This is one of the places the product department can hurt the most from strained relations because developers are well within their rights to say no to these (and they often do), if they were not in the original scope of the project. Sometimes, these changes can be important, and, if your developers haven’t warmed to you, it’s very likely you’ll get the cold shoulder, sending your changes to the backlog.
Handing off features is harder
Most people would rather not work with people they don’t like. Developers are no different, and given the already tense product-dev relationship, this can make things even more difficult. Product design review meetings can be derailed by pointless arguments and detail nitpicking.
Instead of asking for direction when realizing a scenario isn’t covered in the spec, they could decide on a solution and implement it themselves. In small ways, they can undermine the UX designer’s control over the feature.
It’s bad for team building
Teams are important, especially in startups. While startups can’t compete with large companies when it comes to salary and benefits, creative people often gravitate towards them anyway for the community, the vision, and the ability to get in on the ground floor and help shape the product.
Having a committed team is critical because startups ask more of their employees. Sometimes, it’s staying late to fix a critical bug; sometimes, it’s flying to another country to meet with a partner company on a moment’s notice.
Startup employees need to make sacrifices in their personal lives in service of a greater goal. We all need to be invested in the success of the company and the relationships we build. Otherwise, when these critical moments come, no one will step up to the plate.
How to bridge the gap
In order to repair relationships between departments in a company, you have to acknowledge that the problem is usually on a systematic level as well as a personal one. Once we started addressing these issues, our teams started to come together organically. At the end of the day, we’re all working on the same team, towards the same goal. Sometimes, we need to remember that.
Our job as UX designers isn’t necessarily to always have the best idea; it’s to identify what that idea is, regardless of where it came from.
Learn how to give–and ask for–constructive feedback
This is a simple step, but one that needs to be consciously remembered and applied. It’s very hard to listen to ideas when they’re harshly construed.
It’s very easy to speak constructively: Point out elements you think are good, be polite, and phrase your opinions in “I” statements, so they aren’t interpreted as facts.
For example, “I like this design a lot. I think that the button might make more sense at the top” is a lot easier to be receptive to than “The button should be at the top!”
I had a lot of unpleasant interactions before I learned that a really easy way to make them better is to explain what you’re feeling. I would say, “I’d like to hear your idea, but it’s hard for me when you’re approaching me like this. Can we try again?”
It’s honest, humanizing, and very effective.
At the end of the day, we’re all working on the same team, towards the same goal. Sometimes, we need to remember that.
Listen to developer’s notes on product; don’t dismiss them
Working in a creative department is difficult sometimes because a lot of what we do is subjective. We usually don’t have the time or means to granularly test every concept we have while designing, and we have to apply our own judgment on some level in the design process. Working in both marketing and product, as opposed to development departments, I noticed that it’s very easy to critique our decisions, looking in from the outside.
For this reason, creative departments can become cliquey and not want to listen to outside opinions. I realized I’d been guilty of this at times, feeling that, since I focused all of my time on design, I knew better.
But developers are creative, too, and it’s worth listening to their input both because it helps make them feel involved in the product and they have good ideas. Our job as UX designers isn’t necessarily to always have the best idea; it’s to identify what that idea is, regardless of where it came from.
Explain the design process and how you reached conclusions
When you’re presenting a feature and debating with developers (constructively!) on the design of a feature, it can be helpful to explain the design process for context on how you reached the design that you have.
It’s not necessary every time, but sometimes, it can save time to work through the different design considerations, so that you’re all on the same page and can work together on resolving any issues.
Identify when you’re reacting reflexively and take a step back
It’s very important to work on self awareness, especially when a very important part of your job is interacting with other people. Even under the best of circumstances, discussions can get heated, and we need to know when to stop and calm down before further escalating the argument.
Take a deep breath, step outside, get a drink, whatever helps you. Keeping a cool head will keep meetings on track and relationships unscathed.
Don’t be precious about your ideas–kill your darlings
Some things you work on aren’t going to get into the product. Sometimes, entire features that have been designed and have fully fleshed out specification documents will be scrapped or stuck in the backlog, never to be seen again.
It’s upsetting, but we have to be okay with this. If you go into any meeting unwilling to move on your design, your features and your relationships with your coworkers will be worse for it.
Write specs developers love
When I first started working in product I asked a coworker in the Android team for input on how to write specs.
He said, “Always write like you’re explaining to a four-year-old.”
I’ve always found that to be great advice. Write clearly, and don’t assume anything is a given without explicitly stating it. Using mockups as a framework for writing (I work from the top down) is also very helpful because it makes your document easier to read, and you can scan them as you’re working to make sure you aren’t missing any elements. This cuts down on the back-and-forth clarifications that can get people on edge.
Take an active part in high-level conversations on implementation
It’s easy to check out when developers are talking about things you don’t entirely understand. If you do make an effort and ask questions, not only will developers appreciate it, but you’ll also start to understand more about how the backend of things work.
I found that, after attending a lot of technical design review meetings, I was able to better estimate development times, avoid designs that weren’t executable, and even pitch ideas for implementation in brainstorms.
Work on projects together
I’ve seen firsthand how much time both product and development teams save when developers are giving UX designers feedback during the design process.
Designing with implementation in mind helps avoid a lot of the interdepartmental ping-ponging that happens when the design requirements include things that are technically infeasible or would burn too much development time.
Developers also appreciate being included and will gladly be a sounding board or another pair of eyes.
Conclusion
As UX designers, part of our responsibility is to create a collaborative space that harnesses the creative ideas of all our team members. If we treat our relationships with our coworkers as part of our job, both our work and our time spent in the office will improve.
While it is important to hear opinions from other departments, remember that you are the product gatekeeper, so you’ll always have to balance listening and knowing when to put your foot down. I try to weigh every idea or criticism of a feature I designed as objectively as possible before making a decision, and, if I decide that I don’t agree, I explain my thought process. If you can’t defend a decision, you’ve either made the wrong decision or have made the decision for the wrong reasons.
When things get heated, we can easily get lost in the weeds of a debate or get swept into petty department squabbles. We forget that we’re all on the same team, working towards the same goal. Even if we disagree on how to get there sometimes.
