5 Strategies for Bias Busting Your UX Requirements
In our last article, we looked at the “framing effect”, a type of bias that can have you completely barking up the wrong tree with your design strategy. Framing occurs when you make choices based on how information is presented, rather than the information itself. It’s especially dangerous at the requirements stage because if you define the wrong problem, then you’re almost certainly going to end up with the wrong solution – wasting resources, missing opportunities, and reducing your odds of project success.
With this in mind, here are five things you can do to stop framing bias from messing with your UX efforts. They will help you cast the widest possible net for potential solutions and give your design team the information they need to crack the right problem.
#1: Implement a Gating System
How many times have you gone down one path only to realize in hindsight that you should have gone down another? If the answer is more than once, you may need to introduce a gating system into your process. Gating ensures that only those ideas that meet specific predetermined criteria make it through to the next stage. For instance, you might only investigate products where the pain for users is significant, and users are wasting time trying to work around the problem with current, non-ideal solutions.
Here’s an example. Suppose a senior manager at your company decides to give iPads to the company’s field staff, believing that this is the quickest and most efficient way for them to communicate, collaborate and share information. On paper, it’s a great idea. But in reality, the team can’t climb ladders with a tablet in their hands, meaning iPads would never pass a gating test on user adoption or usability. So, this idea is culled, allowing other ideas the space to develop.
The beauty of gating is that it allows you to gather more context before you define a clear path forward. So, instead of greenlighting the first idea, you create a budget for exploration where you can ask tough questions and get a clear idea of the need. All companies have limited resources for UX projects. The gating approach helps you catch any biases early on to avoid them snowballing into bigger problems later down the line.
#2: Ensure Testing is a Team Sport
As designers, we often fly solo on user interviews because it’s our job to understand the user. But we prefer it when several members of the client’s team are in the room. That’s because the idiom is true – seeing really is believing. When team members observe the usability sessions, they are much more likely to accept the usability findings, even when they go the opposite way to what the person wants or believes to be true.
As a busy professional, sitting in on live usability sessions may seem like time that you cannot afford to waste. But it can help the project in a number of ways:
Credibility. Because you hear what users think straight from the horse’s mouth, you are more likely to trust the insights even if they go against your own personal opinions or preferences.
Empathy. Seeing good people struggle with your design is a powerful motivator to abandon your idea and get the requirements right.
Buy-in. When you observe the testing, you are more likely to buy into new solutions you may not have thought about before. In our experience, when clients see feedback first-hand in the field, they go with it. That doesn’t always happen when information is fed back in a report.
#3: Be Hungry to Switch Your View
A design that doesn’t fit your eye is not necessarily wrong. In fact, it’s important not to give in to that snap judgment that says, “We need to do it like this!” If you can see beyond the initial framing and analyze the problem within its own context and on its own merits, you will be one step further on your path to open-minded design.
It’s not always easy to switch your view. For example, there will always be industries or companies where certain legacy systems and workflows cannot be changed, whether that’s for safety, regulatory or other important reasons. But instead of saying “we can’t do that,” dig deeper. There will be some things you can’t do, some things you can do, and some small incremental changes you can make, little by little, to get the results you need. It won’t be a one-slice solution – but great things can happen when you come at the problem with an open mind.
How do you cultivate an open mind? Well, it isn’t enough to say “I want to be more open-minded!” You need to put systems in place that encourage you and your team to seek out different perspectives – restate the question, reverse it, look at different data, play devil’s advocate, get a second opinion and proactively ask for different points of view. A plant manager will always have a different idea of what the software needs to do than individual operators on the ground, so explore these gray areas. This will help you become more self-aware of how you are framing the problem; hopefully, you’ll be able to identify two or three alternative frames you could use to phrase the same requirements.
#4: Make Sure One Hand Knows What the Other is Doing
One problem we see again and again in UX requirements is the desire to design for some 'ideal' future state, even though your users need a solution right now. This usually comes down to a disconnect between the design team, who are focused on long-term viability, and the delivery teams, who need to get things done in the short term.
Now, shooting for the stars is not a bad thing. But there's a point of return in every project where you need to start sacrificing ‘perfect’ for ‘a live application that does what you need it to do. Even the great Elon Musk made the mistake of being overambitious when producing the Tesla Model Three. Striving for 100% automation, he got to 95% before realizing that the final 5% was going to cost around a billion dollars and an additional three years of development time – how many sales would Tesla have lost by sticking to Musk's original vision?
The message here is to communicate, communicate, communicate. Make sure everyone is on the same page from the start and you have a shared understanding of what the project's objectives are. Once you've established that, it will be much easier to prioritize which requirements need to be delivered now and which can wait for later.
#5: Outsmart the Bias with Data
By this point, you've done almost everything in your power to overcome your own bias. But that doesn't mean that you got the framing right. The only way to truly know is to test your hypothesis as many ways you can. This refinement loop should be as rigorous as anything scientific since you’re after the hard numbers that you can use to back up your decision.
This is where data comes in. Data, both qualitative and quantitative, is not biased. Only once we spend time with the data can we begin to see useful insights from it and identify patterns that are not obvious on the surface. Data helps stakeholders see the situation exactly as it is, not how they want or perceives it to be – which is the exact opposite of framing bias.
The bottom line? Don't trust yourself. Trust the data. Instead of making a decision based on what you think you know, with all the biases and preconceptions that are feeding that, wait until you have enough data to make an informed decision. It might take a little longer in the short term, but it will save you a lot of time and frustration in the long run.