How to Win the UX War Within Your Organization

May 1st, 2012
Published on
May 1st, 2012

Companies who don’t care about their end user’s experience create equally apathetic products. Although everyone can agree that software should be intuitive, user-friendly, and aesthetically pleasing, many managers aren’t willing to invest the time and resources it takes to build something compelling. A large part of our job as UX advocates, then, is explaining design’s impact on the company as a whole. Determining which battles to win and which battles to lose – even intentionally lose – can help you win the UX war.

A scene from the movie 300

The war within your organization is probably not this obvious.

The nature of the battlefield depends, in part, on your company’s business model. I work in a business-to-business (B2B) organization which means that the products that my employer sells are primarily targeted toward other businesses. Business-to-consumer organizations, on the other hand, sell their products directly to consumers. They can obtain actual feedback from actual users.

In general, B2B organizations don’t receive as much feedback from consumers as business-to-consumer (B2C) organizations. For example, consider point-of-sale (POS) software systems used in restaurants. When selecting POS software, procurement departments for these organizations likely have very different sets of purchasing criteria such as cost, maintenance fees, existing vendor relationships, etc. Usability may not be an important priority when selecting the software outright.

And olde-time cash register

Cash registers are often sold to businesses, not consumers.

The problem here is that cashier feedback is at least two degrees of separation away from those who need it most. Without strong and consistent feedback from end users, it is unlikely the organization designing the POS software will recognize their own problems.

Another challenge that B2B software faces is that new software typically draws inspiration from existing software in the given industry. It is incorrectly assumed that because the current products are “getting the job done,” that they are models to be followed.

Every organization is different. The challenges you face in your company may not be the ones I face in mine. But hopefully my experiences in dealing with some of these complex issues might help you be better prepared for similar situations.

Battles you can (and must) win

In order to make an impact in your organization, there are certain key principles upon which you can’t compromise. Be confident and assertive when dealing with the following issues, but be sensitive to people’s perspectives as well. Remember that you need to build strong relationships with stakeholders now to support your cause in the future. As Howard W.Newton once said: Tact is the art of making a point without making an enemy.

Convince stakeholders that the problem exists

Sometimes business stakeholders are completely unaware of the issues that exist with their application’s user experience. Maybe nobody explained the application’s problems to them in detail. Or maybe someone did but it wasn’t very convincing or the consequences were not well understood.

One surefire way to prove a problem exists is to record users while they use the application. This technique allows candid feedback from the users, as you can see how they use the application first hand. Sometimes the results may surprise you.

If the user takes a different route – to go to a given page or to complete a certain action – instead of following the designed workflow, analyze why the user chose to take this path. Was the existing workflow not obvious? Was it cumbersome? Was it just easier to do it this way? The answers to these questions will help you gain insight into your users’ behavior & expectations. Some popular tools that can help capture this kind of feedback are Jing, Screenpresso, CamStudio, and Silverback.

Next, get the project team – including all stakeholders – in the same room and play the recorded user sessions. As a group, take note of various usability issues. What do they struggle with? Where do they make the most errors? Do they find the workflow confusing? Documenting even the most mundane problems in an application can get your stakeholders to pay attention to the application’s user experience.

Coming up with an agreeable solution

So you have demonstrated the problem exists; now prove a solution exists. Again, you cannot compromise here. Pick a specific part of the application that needs a makeover and build a high–fidelity prototype to demonstrate how it could be better. Be sure to communicate the difference between the complexity of the existing design and the simplicity of your new design. Some of the popular tools that can help in this area include: Balsamiq, Mockingbird, MS Sketchflow, MS Visio, and Hotgloo.

A wireframe

Help stakeholders visualize your solution by wireframing it.

Next, see if your end users like your redesign. The last thing you want is to get approval on a design that your end users don’t really care for! If possible, talk to a user or two to see what they think of your design and refine it as necessary.

Finally, present it to the team. This is a much better way to show the stakeholders how things can be improved from the current design and thus, get their buy-in easily.

Garnering support from the sales & support teams

In many B2B companies, the most knowledgeable people to talk to about real user feedback is the support team or help desk. These teams deal with angry and frustrated users every day, and can probably list the top five customer complaints off the top of their head! Be sure to incorporate the feedback from these groups in your design when possible.

Alec Baldwin says 'Always. Be. Closing.'

Sales people frequently have a unique perspective on your business.

The sales and marketing teams typically have a large influence on product design and development. Talk to them about the findings from the user sessions and the feedback from the support team. If you can convince them how your application’s poor UX is affecting customer adoption and is creating negative experiences with the product, they will join your cause. It’s hard for management to ignore a sales team that says Our product’s design is keeping us from meeting our goals!

Winning the numbers game

The higher up you go in the chain of command at an organization, the less they care about esoteric product details. Managers usually want to know how much will this effort cost them, how much will it save them, and how long will it take before they see results. These are not unreasonable questions to ask, so you’ll want to phrase the benefits of good UX in terms they’ll understand: dollars and cents.

Poor design inevitably impacts a product’s development and support costs but often this can be difficult to quantify. As a consequence, design is often seen as “subjective,” when you and I both know its manifestations are anything but. Luckily, there are several articles out there that can help you quantify the effects of user experience on the bottom line: Usability cost benefits evidence, Constructing a User Experience: The Cost-Benefits Compass, and Calculating ROI on UX & Usability Projects. Take a look, spend the time, and make the case for improving your application’s design in a language your stakeholders will understand.

Battles that are okay to lose (even on purpose)

So far we’ve discussed battles you have to win – but everyone knows you can’t win them all! Any strategist will tell you that knowing which battles to lose is imperative to winning the war. Let’s look at a few.

Finding someone to blame

Some people in the team will always point the finger at someone else – nothing is ever their fault. If the design sucks, it’s somehow the Project Manager’s fault or the Business Analyst’s responsibility. Or they weren’t given enough time to come up with a better design due to tight project deadlines.

An angry, finger-pointing monkey

Pointing out who’s to blame for the product’s poor UX will get you nowhere. In fact, doing so is counterproductive and can only lead to distrust. Instead, focus on persuading the team to join you in a fight for a redesign. Let them know that their opinion matters.

Looking for progress

Change is hard for most people to accept – especially when they’re skeptical about its effects. Yes, you’ve been fighting the good fight in the name of UX, but don’t expect everybody to get on board so quickly. It may take awhile for your colleagues to see the value in building applications with better UX.

Be patient. Gently ease your team into the process of taking the user-centric approach. Make sure the team doesn’t lose momentum. If they do, act quickly and step in. Help your team see the goal (separate the forest from the trees).

A tortoise, slow and steady.

Slow and steady wins the UX race.

Remember, you need everyone’s buy-in for this to work. Even if they are slow, as long as they’re steady and making measurable progress, you’ll win the war.

Becoming “that” guy

A badge that reads: Hello, my name is 'That guy'

Although I received overwhelmingly positive feedback on the UX initiative I started at my company, I also received some snarky remarks from a few folks. The truth is, I made a conscious effort to avoid highlighting any specific product or team because I wanted this initiative to be a positive experience for everyone.

Not everyone sees it this way, of course. Tell your colleagues that you appreciate the fact that they take pride in their work and acknowledge that you’d be upset too if somebody implied you did a poor job. Help them understand that you are just there to help.

Defining yourself

Hopefully your effort will be an eye-opening experience in your organization. Even so, that doesn’t mean that management will champion a UX team right away. They still may want to see how this will pan out in the long run. So in the short term, you may need to do some of the work “for free” on projects just to show them how things are done.

Get out of your comfort level a bit to take on a new role that you had not signed up for. It’s okay to lose the battle of defining yourself.

Don’t be afraid to wear a different hat if you have to. If you’re an IA being asked to do Visual Design, do it. If you’re a designer being asked to do some requirements gathering or user interviews, do it. If you’re a developer being asked to do interaction design, do it. Never forget that your ultimate goal is to win the war!

Win the war

In the end, it’s all about perspective. When you find yourself fighting any of the aforementioned battles, take a step back and try to figure out whether it’s worth the fight. Consider what’s at stake. What matters the most is that you don’t lose hope or momentum. Once people see the benefits of your effort they’ll start asking for more, and then quickly realize that they’re going to need a bigger team to handle all requests moving forward. And that is a good problem to have.