Rather, how do you tell a product owner or dev lead that their UX is bad?

Congrats on your new job! Someone has just hired you as a user experience designer/strategist, but when you start looking at the product you see lots of glaring issues with the UX. The existing product/dev team has been hard at work on this and there is a lot of emotional investment in what they have already produced. So, how do you fix the UX without telling them that their baby is ugly? Or, better yet, how do you tell them that their baby is ugly, but in a way that makes them thank you for pointing it out?

I don’t have all the answers and every situation is different, but here are some guiding principles:

• Never lead with “your baby is ugly”
  Imagine some new guy just started in your office this week. He walks into your meeting and tells you that everything you’ve worked so hard on for the last 6 months is wrong. It will not end well, even if he’s 100% correct.
• Ask for context
  It could be that this bad interaction is part of the legacy product that has been in place for years. Customers are used to it and changing it might do more harm than good. The point is, you don’t know what circumstances led them to this decision. There could have been a political clusterf*ck that divided stakeholders last year and this was the compromise that came out of it. Do NOT walk into that field until you know if there are any landmines.
• Choose your battles
  Now that you have the context, you know where the landmines are and can start to chart a course through them. Sometimes, you will have to let a bad experience be released to users. It sucks, but it is not always avoidable. Maybe the team is already 2 weeks from code complete, there’s no way they have time to build and test a new interaction. Take your time and design it right for the next release instead of rushing to get it in for this one. Other times, you might have plenty of time to rebuild the interaction, but the political capital you would have to spend to get it done just doesn’t make it worth it. If you burn bridges in pursuit of the ultimate user experience on this product, people might not be as willing to listen to you on the next one.
• Frame objections as questions
  So it’s time to have that conversation with the dev lead… How do you bring it up? Don’t bury the lead and don’t dance around it: “Hey, David. I was looking at X and it stood out to me. Could you help me understand why this interaction is/does ________?” Maybe you already know the answer, but this approach gives them a chance to articulate the interaction without feeling like they are having to defend it from attack. There’s every chance that their explanation turns out to prove that X is the correct way to handle that interaction. If that explanation still does not line up with good UX practices, then continue asking questions. Try “How would that work if…?”, “Would it make more sense to…?”, and “What would be the use-case for…?”; instead of “That doesn’t work”, “This way is better”, “No one is ever going to be in that situation”.
• Never feign ignorance or stupidity
  You’re asking questions instead of handing out absolutes, that’s good. But never be fake about it, they will see right through you. Always be genuine in your interactions, especially when attempting to get someone to see things your way.

You know how your CEO/President’s secretary always has that big, fake smile on and she’s always overly sweet to your face? But then, as soon as your back is turned, she’s talking shit about whatever you’re doing and trying to make you look bad to her boss? Now imagine she came to you and told you that your product had a real problem. It wouldn’t matter how much data she has to back it up, you’re not going to be interested in listening to her because she’s fake.

• Become an expert framer
  Unfortunately, UX strategists and designers sometimes find themselves relegated to consulting capacities, even in permanent positions within companies. When you are in a position without any real authority, you have to rely on your ability to persuade in order to get things done. But product owners and dev leads are not usually too keen on relinquishing control of their product. Therefore, you must frame every thing you say, every question you ask in such a way that it forces them to take a hard look at the decisions being made. Is this, in fact, the right user experience? Or is this new suggestion better? Guide them to your conclusion, but set it up so that they can’t help but see it from your perspective.
• Over-appreciate compromise
  Understand how loss aversion plays into this type of dialogue and use that to your advantage. Failing to recognize compromise as someone else’s concession will cause you to, inadvertently, behave in a dismissive or potentially self-righteous attitude. Do everything you can to avoid the, I’m-so-glad-you-see-that-my-way-is-better trap. Accept any compromise as a victory and accept any victory with humility. You will never be right 100% of the time, so it’s important to win with grace and acknowledge when you’re wrong. It will make these conversations easier in the future.

Real-World Example

The theory doesn’t always work out the way you want in practice. Here’s an example of one of my own attempts to fix a bad interaction:

While working at Omnega (not the real name), I ran across an interaction that immediately made me cock my head to the side like a dog hearing a strange noise. This was an iPad app for a complex relationship database. There are lots of forms, lots of object relationships, lots of data to be input along the way. Omnega was essentially porting their desktop application to an iPad native app and making very few changes along the way. The release is set to go live two months from the time I first saw it, so I have very little chance of impacting anything in this version. But there was one thing that needed to change.

Any time the user interacted with a form–and these were generally pretty hefty forms–much scrolling required–they had to change modes. There’s a View Mode and an Edit Mode. That’s not necessarily cause for alarm, except that nothing changed when you toggled between them. As far as the user was concerned, switching modes changed absolutely nothing on the page. This made me question the purpose/necessity of that interaction. The user is already viewing a form, now they want to edit a field. Instead of simply tapping on that field to edit it, they have to go up and choose Edit Mode from the top of the screen. It made absolutely no sense to me.

The first question I asked–because I figured this had to be the reason–was, “Is this a behavior that already exists in the current desktop application?” In other words, is this one of those things that got ported over because that’s “just how it was” and the users “are already accustomed to the behavior”? The response surprised me. This was a new behavior being introduced to product for the first time in this release.

This product is complicated enough to learn as it is and very little is changing in the tablet port. That means that existing users will be approaching this experience with a fair bit of cognitive fluency: everything pretty much looks, feels, and behaves the same… except when they want to edit forms. I’ve got these scenes flashing through my head of users tapping a field over and over again, getting frustrated that they can’t edit anything. As I soon found out, there was a big debate earlier that year on how to handle this new behavior, because there was concern that users might accidentally tap inside of a field as they were attempting to scroll down the form. Ok, fair enough. They identified a potential pitfall in the experience and were attempting to build a constraint to avoid it. This is generally what you should do since preventing an error is always better than forcing a user to recover from one.

So my next question: “Ah, gotcha (acknowledging that I understood their reasoning)! Ok, well how have you seen other tablet applications handle this behavior?” I was asking the guy that ultimately bullied the decision through and now he’s stuck. There is not a single thing he can come back to me with–beyond emotional and political arguments–because there aren’t any other examples of this behavior that we could find. I’m not saying they don’t exist, but we did look and we came up short. This means that, in an already complicated database app, he wanted to introduce a foreign behavior that is contrary to anything the users would be fluent with; both inside and outside of our app.

He pushed back on me, “We don’t need to rehash that!” and I let it go. Choose your battles. No good can come of taking this conversation any further, especially when we are 2 months from the go live date. But I made a note to follow-up with user interviews after the release. That would give me a chance to ascertain user impact and have real data to use as an effective tool against that bad interaction.

---

The interaction in this example is not a make-or-break UX failure. Users will undoubtedly learn the new behavior and use the app regardless. This is the primary reason I did not push the issue further. But the problem here is that the user experience is a culmination of hundreds of small interactions. Each one of those interactions contributes to the user’s perception of your product. Good UX requires that all of these individual pieces work together to help users achieve a state of optimal flow while interacting with your product. So the small things may seem inconsequential to you when you look at them in silos, but if they break flow for your user, it can make a huge impact.