The Ancient Art of UX War

Originally published on The Pastry Box Monday May 12 2014

My first year as an Information Architect, I worked a financial dashboard project for a client with the reputation of being “difficult”. The client wanted a specific but complex chart, which their support staff would have to regularly explain to the users. The users wanted a less-robust chart they could understand without asking for help, but it didn’t deliver all the information the client valued. I took the two charts to peer review, convinced that if I could get the backing of some senior IAs, I could force the client to switch to the users’ preferred chart.

Instead, my leaders and mentors viewed the chart problem as minor. “You have a huge gap in your structure in this other area,” they pointed out. “You need to get the clients to agree to fix that first.”

“But the chart-” I objected.

“You have to pick your battles,” one of them told me. “This is a minor problem they’re willing to deal with. That is a labeling and content strategy issue that will affect the whole design. The chart is not the hill to die on.”

Every design project requires striking a balance between user needs and business goals. As User Experience professionals, we’re responsible for representing the messy world of users. We land in adversarial situations, where what we recommend as the best approach conflicts with what our clients or sponsors prefer. Sometimes this happens because our clients don’t understand what we do or the research that backs our recommendations. It may be that we’re unaware of business goals or needs. It can be a result of bad communication. Sometimes we just don’t like each other.

The first step in resolving the conflict is to decide how big a conflict you’re willing to fight. Where is your energy best spent? How can you best represent the users’ needs? You can battle with clients over every detail, or you can choose to work with clients for the things that made the most sense.

You have to decide which disagreements represent a hill to die on.

A few years ago, I created a set of wireframes for a tool redesign project. My proposal made the front end easier to understand by tenfold, but made the back-end more complex (and expensive) to develop. The interface was critical to success. We were in agreement on almost everything else in the project. This was definitely my hill to die on. I researched. I prepped. I rehearsed. I made sure I could tell the story about why this would be money well-spent.

As soon as the meeting began, I charged forward with data-driven and effectively presented ammunition, only to have my legs cut out underneath me immediately by my client’s declaration that there was absolutely no way we were going with that design. End of story. She even called my manager to tell him to tell me we weren’t doing it.

As I lay on that hill that I chose to die on, I found myself wondering how with all my preparation work, I had landed there.

I later learned my client had just arrived from a meeting where the project budget had been slashed for the third time. She felt powerless and frustrated and angry. It didn’t matter that the company was making the hard but correct choice. It didn’t matter that the client actually agreed with me on the project needs. The client felt disrespected, and she weren’t going to take it any more. If I had asked for a quarter for the soda machine, I was going to get mowed down that day.

It wasn’t her emotional state that caused my failure. It was my lack of empathy. I landed on that hill because I had neglected to ask, “How are you?” and “What’s new?” before I ramrodded my opinion down her throat. I forgot that my client was a person. I saw her as a dramatic foil against which I was going to reflect my enlightened Design opinion. Had I asked, I would have better understood the business problem, and we could have worked out a compromise or I could have simply asked for time to do a more appropriate (if not as effective) design.

You don’t have to just pick your battles, you have to make sure you’re choosing a good day to take on the challenge of climbing that hill. It doesn’t just have to be the right hill, it also has to be the right weather.

I had a project that went poorly early in my career, mostly because I am slow to learn when to keep my mouth shut and which hills are worth dying on. Years later, I was assigned a project for the same business client. He was working in a new department and so was I. We had both grown in out soft skills and we were both much more professional than our initial meeting. I wasn’t even working with him directly — I worked with the project manager who reported to him, who I got along with famously. It didn’t matter. When I presented at the first tollgate, I was grilled to within an inch of my life on details that didn’t matter, issues that didn’t exist, anything he could do to try to trip me up in front of the team.

I’d like to say that I was the consummate professional. I wasn’t. I took the bait, and the meeting became a verbal sparring match. I came out “victorious”, if such a thing existed, only because the development and project team backed my designs. It was not my shining moment.

As the second tollgate came around, we knew we had a problem. Some of the work we were presenting would be a hard sell for our budget in the best of cases. The team believed in the work, and didn’t want to change our approach just to avoid conflict. Even though the project manager had never given a design presentation before, she volunteered to present the work.

I hesitated. This was my work, it represented my research, and it was my responsibility. If it needed explanation I felt I was the most qualified to address the questions. If it was lacking, or the sponsors didn’t approve it, I felt I was the one who should take the fall.

But my project manager had been at every major decision point, understood the logic and research behind the decisions, and “got” design. The only thing standing between a guaranteed bad presentation and a possibly good one was whether I was willing to give someone else the responsibility I felt only I could shoulder.

Ultimately, a friend pointed out that my battling with the client sponsor didn’t actually benefit the project. It didn’t benefit my project manager’s relationship with her supervisor. It certainly didn’t benefit me. It was, in short, not in the best interests of my users.

My project manager gave a fine presentation and we were approved to go to the next step even with the hard-sell design.

When you’ve picked your battle and you’ve ensured it’s the right hill to die on and the right weather to do it, make sure you send in the right general. There comes a time for each of us when we may be the most qualified to do a job, but not the right one to do a job. We owe it to our users to ensure the right decisions are made, even when that means we have to hand over the reigns to someone else.