How to Choose Your Battles in UX

We’re gonna start this out with a friendly anecdote that we can all relate to. Let’s say that you’re well into the design process on a given product, and have excitedly shown it off a few times (to rave reviews completely devoid of any critique, of course – I’m assuming you’re pretty awesome.) Everything is going well until you get that Slack message from one of the senior engineers on the project. This gal knows her stuff, so when she sends you the note, you pay attention.

Then it happens. “We’re working on [your pet epic here] and we’ve got an issue. Creating [your pet feature here] is taking way too long, we’re gonna drop it and use [a loathsome alternative] instead. Just a heads up.”

It doesn’t always go down exactly this way, of course. In the above case, it’s a time constraint. Other times, it’s a cost restriction – the feature you want to build would be too expensive to maintain, for instance. Or maybe it’s day one of a kickoff, and you disagree with a belief that’s important to an executive in the room. Regardless of the situation, your toddler-of-an-app is getting a haircut you didn’t ask for, and you’re quite certain it’s gonna be a mohawk or something. 

How do you respond? There’s a number of options, of course, but sometimes the obvious choice isn’t clear. I’ll summarize your options in three buckets. 

There are times when you may actually agree with the decision to adjust the design. In this case, you’ll actually advocate for their route. It may not be that your design was flawed, it may simply be that you now have a deeper understanding of the technical/market/financial/etc constraints. In other words, in your eyes this is simply an improvement to the design as a whole. This is the happiest path of our three options.

This means tolerating a decision from engineering, finance, etc., that you wouldn’t generally agree within a vacuum. That last part is important: you wouldn’t go this direction in a vacuum.But you’re not in a vacuum, are you? Design is messy and challenging, and so is engineering, marketing, finance, etc., so there are times where it’s actually beneficial to let something go for one reason or another. More on this later.

This is how we generally might tend to react, right? Natural as that may be, however, a knee-jerk reaction isn’t going to benefit you, your business, or your user, so be intentional and measured if you need to disagree with a decision. This might mean sleeping on it in order to convey a clear response, gathering evidence to show why you believe what you believe, etc.

Ready for the cliche, annoying answer? You’re smart, you already knew this was coming. It’s this: there is no answer that’s always right. Things are simply too complex in our industry (heck, in our world) for it to be that simple. But bear with me, because I think I can give some general principles which help you choose one of these bird’s-eye-view options.

First, let’s presume the design change stemmed from a benefit to the business, as it usually does (otherwise it wouldn’t have been proposed). In other words, it saves time, money, or annoys a crabby engineer less (and thus improves morale.) This leads us to our principal for agreeing with a change of this sort: if the business benefits and the user benefits from this new decision, then you need to agree with it. Pretty straightforward, right? If the change to the design is a win-win, you need to swallow your pride and admit that this new change is beneficial, regardless of whether or not it was your idea. In fact, you should become an advocate of it at this point. 

That being said, if the business benefits but the user doesn’t directly benefit, then you’re going to need to look at your two other options.

Tolerating a detrimental adjustment to a design can be difficult, but there are times when it’s the right choice. Honestly, we designers need to grow up and accept that we don’t design in a vacuum. And yes, that means things don’t always turn out as well as we’d hoped. Trust me, I don’t like it either, but hey, c’est la vie.

So let’s say that in this situation, the design alteration is not a direct improvement for the user. There’s one overarching principle that can help you decide when you need to tolerate it nonetheless: when the impact on the output (the user’s benefit) is improved. What does that mean? It means that if the user base as a whole will benefit from a worse design, then you need to tolerate that worse design.

I know what you’re thinking: “Whoa whoa whoa, why in the world would a user benefit from worse design? What kind of traitorous UX article is this?” Put simply, I’m talking about pragmatism in UX, and firmly stand by the fact that there are times a worse design will benefit a user base. In fact, this happens every day in a bazillion different design endeavors. 

For example, a 2021 Tesla Model S is clearly an overall better vehicle than a 2005 Chevrolet Impala. But for a large demographic, the Chevy is the better car for them, simply because it’s far, far more affordable. They would sacrifice so much to attain the Tesla that their experience as a whole would be far worse if they owned it. In this case, the financial sacrifice for a “better design” would be prohibitive, and thus the “worse design” is actually more beneficial for the user overall.

Likewise, perhaps the feature you want would increase costs substantially enough that many of your target users would no longer be able to afford the end product. If they can’t use the product, they can’t benefit from it, and thus for them, the improved design is a worse experience, holistically speaking. This means that it’s not just the business that benefits from cost-cutting: users often do as well! Look at businesses like Costco, for instance: the sparse decor, bleached lighting, and limited selection may not be the ultimate design choice in every sense, but insofar as those choices save users money, they’re exactly right nonetheless.

While I’ve used cost here as an example, I want to note that it’s not the only variable that might negatively impact a user. If you constantly push back against every decision an engineering team makes, you’re going to be seen as a difficult, immature colleague, and your ability to intercede for the user will likely suffer as a result. If you ignore the timelines a business sets for itself, you may fail to line up with a critical marketing push that will allow your product to hit critical mass and actually make a difference in the world. 

You get the idea, but suffice it to say that there are many instances where a designer may need to compromise to actually enhance the user’s ultimate experience.

Now that we’ve covered agreeing with design changes as well as tolerating design changes, we come to pushing back against them. At the risk of stating the obvious, I’ll say that pushing back is what you’ll need to do when you can’t agree with or even tolerate a change to a given design. In other words, the user will in no way benefit from a design change, so you have to stand up for them by standing up for the better design.

There’s a few things we should keep in mind about pushing back, however.

1. Pushing back takes resources: it takes time, uses energy, and usually creates at least some professional/personal friction amongst team members. Take this investment seriously.
2. We designers need to make sure we don’t consider ourselves to be the only voices of reason in our organizations. Our colleagues are generally intelligent, resourceful, and hard working, so let’s give them the benefit of the doubt when they want to adjust our designs – their ideas are *gasp* sometimes actually good!
3. Integrity and faithfulness to user advocacy does not mean stubbornness. While it sucks sometimes, know that even when you strategically choose your battles, you still may lose, even when you’re in the right. You’ll need to know when to put up a white flag and accept that – whether rightfully or not – you’ve been outflanked, outmanned, and outgunned.
4. This kind of thing requires trust and respect. You need to trust and respect your colleagues, and if you want your opinions to carry any significant weight, you need to earn the trust and respect of others around you. You probably don’t want to start World War III at your company the day after you join.

If you’ve considered your other options, and have soberly taken into account the ramifications of the battle you’re about to start… then start it! Design deserves a seat at any organization’s table, so I say push back whenever it’s right to do so. A healthy organization will thrive off of team members sharpening one another this way.

Be earnest, honest, and come with facts – not just feelings. Nothing annoys an engineer more than you pining away about how you feel about a given design; that looks like nothing more than emotional attachment and will likely get you nowhere.

Whatever you do, I want to impress upon you once again that your primary job is to advocate for the user as much as possible. We’re here to help people, so let’s do the best we can… bringing the user’s banner into every battle we have to fight.