When you hear, “Don’t fix what isn’t broken”, you probably think of some iconic luddite from Hollywood; someone who is unwilling to acknowledge or unable to see the fault in the system and has no desire to address it. Unfortunately, sometimes this describes our clients–not every client and not every time–but many of you can probably name at least one project within the last year.
This post is all about why you shouldn’t actually try to fix the things that are broken.
But before I get started, I want to highlight a few exceptions:
- If you are building something new or for the first time
- If the client starts the project by asking you to perform a heuristic audit, UX evaluation, or to address the user’s experience
- If the client has a history of responding well to change
- If you have a phenomenal rapport with the client and they will listen to your recommendations
If you are working within one of these scenarios, then it’s much easier to sell the research and activities you need in order to create successful experiences and there may be large portions of this post that do not apply.
For the rest of us…
Imagine, a client approaches you with a simple redesign, a product integration, or an update to some smaller aspect of the product. In these cases, the client has an existing product and they also have a clear “ask”; and most of the time that ask does not include a UX overhaul. But we can’t help ourselves, as soon as we start looking under the hood, we begin to make a list of things that need to change to improve the user experience.
The Minefield
I won’t say you should never try to fix the experience, but what I’m saying is that you should be aware you’re entering a minefield. When the client has a specific ask and it doesn’t include UX by default, trying to address the user’s experience in the project can often lead to failure. Why? Because existing products have product managers and stakeholders and the longer these people have been involved in the product, the more entrenched their views on that product will be. Unless you are intimately familiar with the political landscape, you’re going to need to find a win elsewhere.
The Scenario
A B2B client has asked you to integrate two Enterprise Resource Planning applications with a Customer Relationship Management application. At the moment, all three of these exist as entirely separate products: they were built at different times, with different code bases, and serve entirely different purposes.
During Discovery, you immediately uncover bad interactions, confusing experiences, and ways that you could improve the product. For example:
- There are over 30 distinct user roles with different permission sets
- The user flow required to complete many transactions is unnecessarily long and arduous
- Related sets of information are located in opposing sections of the application and cannot be viewed at the same time
Naturally, you recognize that merging these systems exactly as they are will only compound the user’s problem. So, you begin testing the waters with questions like, “What kind of feedback have you gotten from your users?” and, to your surprise, they respond, “Our users love this! They think it’s really easy to use!”
Don’t Fix What IS Broken
As much as it pains you, you shouldn’t try to fix any of the things you’ve just identified as problems. You’re going to have to resist the temptation. Why? Because the client doesn’t view them as problems and they do not believe that the user views them as problems either. That would be similar to being hired as a line cook at a restaurant and within your first week, you start telling the Head Chef about everything that’s wrong with his menu. He didn’t hire you to evaluate or make recommendations on his menu and he won’t respond well to you trying to tell him how to “improve” it.
I’m not saying you shouldn’t fix broken code or technology and, any time you are doing an integration, you’re going to have to fix at least some of the experiences/interactions in order to make the products work with each other.
But what I am saying is that you have to recognize where you can and cannot win. The client didn’t ask for you to perform a UX evaluation or to help them solve an experience problem, the client believes that users are happy with the product, and you probably don’t have your finger on the pulse of the client’s political landscape.
If you did decide to try to fix the user experience as part of this project, you will essentially be solving for a problem that does not exist–at least in their minds–and it will almost certainly end in one of two ways:
- If you managed to stay under budget, then they are, at best, apathetic about what you’ve changed.
- On the other hand, if you went over budget to solve a problem (that doesn’t exist for them), then the client is now upset with you for charging them more than you agreed; or you’ve just eaten your margin.
Neither of these are ideal. We need our clients to see the value in UX is (as a discipline) and what it can do for their products, users, and business.
How do you create a win?
If you want to be able to fix the broken experiences, you have to first win on the original ask. In our scenario above, the easiest win would probably be navigation. When integrating large, legacy systems into a single application, navigation is going to be a problem. Maybe you emancipate the front-end with a dashboard and create some really intuitive widget access to the underlying functions. If you do this well, then the disparity between the dashboard experience and the underlying experiences will be obvious and you will have earned the right to challenge the other problems you identified earlier.
Sometimes you won’t be given the opportunity to tell someone their baby is ugly until you’ve shown them how “beautiful” the experience could be somewhere else.