Dealing with close minded developers


#1

Hi fellow designers,

I’m in a very tough situation and want your advice.

Currently, I’m working in a small startup (12 people) doing complex, b2b workflows. Things move quickly here and I find enough UI/UX work to indulge myself.

However, 7 to 8 months into my job, I’m hitting a wall. You see our developer is a very stubborn guy (low in agreeableness in Big5 traits). So every time I ship off a design, it get modifies in ways that do not meet my initial design goals.

As a very agreeable person, my tendency is to shirk off the changes and move on to the next thing. Although I have confronted him a few times, every time it ends up in a nonsense argument.

This prevents me from creating better designs since there is no easy way to discuss problems.

I’m well aware that this developer is not only confrontational, but also sees “being right” as extremely important (whereas my value is excellence).

To make matters worse, this developer happens to be the CTO & co-founder of the company, which means he built up the whole platform from scratch. It’s very hard for me to change his mind.

===

I really want to be constructive here.

To further my UX skills and bring the best UX practices into my team, I really want to use usability testing as a tool to resolve our conflicts.

Do you think it’s reasonable for me to talk to the CEO about this, request a budget for usability testing and plan a better way to cooperate with my CTO?

Have you been in a similar situation? What would you do?

Thanks,
Scott


#3

Hey Scott,

What are some of the changes or requirements from the designs that aren’t getting implemented? Are they major issues or are we talking about pixels out of place? Were the designs shown to and approved by the CTO earlier?

If the CTO is responsibile for general production than he/she may have come to the conclusion that the ROI wasn’t there.

Either way, I would personally try to sit down with the CTO and have a honest conversation then going to the CEO. He/she could feel like you’re going over their head and not a team player.


#4

Thanks for your reply, Greg.

  • In some cases the changes are simply elements being placed in a different location; in others the entire workflow is improvised and strays from my initial design entirely.

  • Designs are approved by the CEO, but usually get implemented differently by the CTO.

I’m well aware of the ROI and business needs. It’s not the actual changes that bother me, but the fact that there is no communication when these new decisions override mine.

I suppose you’re right about talking with the CTO directly, and believe me I’ve tried. It’s almost certain to end up in a non-productive debate that gets everyone upset. (I’ve already lost my cool twice because our debate went in circles and failed to articulate the precise problem.)

Maybe that’s what I have to do? Bring up the uncomfortable conversations every time, even though they’re not welcome — it’s unsettling.


#5

Hey Scott!
I feel your pain, and it’s one that many of us share (or have shared at some point).
I can see 2 ways of fixing (or at least improving) this situation.

I’ll start with a recent case I had with one of the designers in my team.
He was in the exact same position, where a developer had a “UI developer” job title that in his eyes gave him full authorisation to just ignore parts of the design he was given, and go with his own solutions.
We fixed that one by having the whole product team (Product owner, Scrum master, designer, developers, testers, etc…) together and discuss things. I wasn’t part of that team so I called for it and acted as an external moderator.
This partly fixed the issue, and both parties understood the other side of the story better.

The best thing for me is to involve the developer (or any stakeholder posing this kind of problem really).
By making them part of the design process give them ownership of the agreed solution.

I can see 2 great opportunities:

  • Design Thinking workshop or Design Sprint: really good ways to involve your stakeholder and product team in outlining the problem you want to solve, and how you solve it.

  • Usability session: taking part in the observation (or even the facilitation) of a usability testing session is the best way to see the impact of a design decision. Witnessing first hand a user struggling with an interaction, a piece of content is the best evidence that the solution isn’t right.

I gave a talk on how we brought usability testing in our company (Centrica) and how we got to involve stakeholders.
It really works here. It can be an eye opener, even for high level stakeholders who think they know best.

The keyword here is teamwork. Involve your team, your stakeholders. Designers don’t have all the answers.