Bias is an inevitable part of the design process – but is it always a bad thing? Nadine takes us through the five most common types of bias to watch for and when to use them to your advantage.

More and more of us are trying to live life judgement-free. The problem is, our brains don’t want us to.

The brain is clever. But it’s also pretty lazy. And when it sees a shortcut, it’ll take it. For instance, if you see a Rottweiler, your brain might not want to go through the effort of determining whether this particular dog is friendly or not. It much prefers to take the easy, low-effort route, which is to fall back on what it’s already heard about this type of dog breed.

These forms of unconscious bias are everywhere, including in your product design and testing

Where do biases come from?

Unconscious biases come from our own experiences, the experiences of others around us, and even through hearsay. In product testing and design, they can come from a huge number of sources, such as:

• Designers: They know what designs have worked well for clients in the past
• Product Team: They’re shaped by their previous successes and failures
• Clients: They have an idea in their head of what a product will look like
• Users: They might have always done things one way and don't see the need to change it.

When we’re building products based on past experiences and ingrained expectations, we’re designing for the past and optimising for ourselves. We’re not designing the best product in the here and now. This is why building products around solid, objective research is the best way to design effectively and deliver fantastic outcomes. But – and this may come as a bit of a surprise – some types of unconscious bias could help product design, too.

Let’s take a look at 5 of the most common types of bias I see most often in design and testing…

1. Confirmation bias

Confirmation bias is when you expect certain things from your design or testing and happily overlook any ideas that conflict with these expectations. It can mean you’re not exploring all possible options.

This is probably the most common type of bias I see in my job, and it’s clear why. By the time you arrive at a point where you’re designing your product, you’ve already thrown out a tonne of other ideas that haven’t emerged as the best options. You’ve ‘confirmed’ the best idea to put forward and develop. It can be really tricky to go back and reconsider any alternative options or different points of view.

The best way to overcome this is to have a framework in place that helps you gather and analyse data when testing your product at the prototype stage. Something that gives a very clear cut ‘pass’ or ‘fail’, rather than bringing subjectivity into it. There should be no room for interpretation. It should simply be a case of considering ideas against a very well-defined set of criteria.

Case Study : Where's my number?

Recently, we were testing a concept, and one of the questions we asked was ‘where would you find your membership number?’. It was right there on the homepage, but 80% of people failed to find it. This really surprised us.

Users simply didn’t expect to see it where we had put it. So even though we thought exposing the number was the best solution, we were proved wrong time and time again.

Users had a preconceived idea of where it would be on the page and when they didn’t see it, their brains ‘confirmed’ what they thought they knew: that the number simply wasn’t there.

This was interesting and a useful reminder to me that, if you approach it in the right way, bias plays an important role in product design, namely – applying the familiarity principle.

2. The familiarity principle

As the title would suggest, this is the tendency to prefer things that feel familiar. This form of bias can be helpful when you use it deliberately within design patterns.

As we discovered in the example above, most of us expect to find things in places we’ve seen them before. For example, if we’re looking for an organisation’s address, we might scroll right down to the footer to look.

Of course, there’s some criticism of this, with many people (including us!) beginning to ask if all websites are starting to look alike. How do you differentiate yourself if we’re all using the same styles?

But in some ways, being different for the sake of being different is a bit pointless. If an out-there design is going to mean a user spends more time trying to find something, chances are they'll get frustrated.

So for me, bias isn’t necessarily something we need to shy away from completely. Take things like calendar functionality for example. Apple, Outlook, Google – these are things people are using daily. They know how to use these calendars. They don’t want to learn a new way of doing it.

Of course, there’s always room for improvement in the way some features operate. There are times where we should differentiate ourselves, particularly to create moments of delight in design. But at the same time, there are moments where we’re actually better off following familiar patterns.

How do we know when to use a familiar pattern and when to disrupt it? By bringing the user into the design process from the start. This can also help you avoid another form of bias, the ‘sunk cost’ fallacy.

3. The sunk cost fallacy

The ‘sunk cost fallacy’ is a well-known bias, in which the brain will fight to justify continued investment in a solution, despite evidence suggesting it’s probably the wrong choice.

Whether it’s persevering with a crap book, movie or event because you’ve already invested your time in it, we all know how hard it is to walk away when we’ve committed to something. In product design, this bias can occur when you’ve neglected to consider user needs properly at the start and built something based on stakeholders’ demands only.

When you begin projects, you need to have the user’s voice in the room to understand the problem they’re trying to solve. Not just your own voice or the voice of other stakeholders. Without the user’s voice, you’ll probably end up creating a very different product, but you’ll be convinced it’s the best solution because it’s exactly what the client has asked for.

Inevitably, there will always be pretty big differences between the way customers use the product, as opposed to stakeholders and product teams. If you discover this too late, it will take huge effort and expense to backtrack and redo things from the user’s perspective.

The way to overcome this is to build a user-centric culture across the organisation. This means your team puts the user first as a natural, normal part of processes, bringing them in from the very start. It means you aren’t progressing with such a singular, narrow view of what the product needs to be. You’re designing from a more open-minded position that allows you to meet a wider variety of needs – and test your assumptions along the way.

However, doing user testing well means deliberately removing all bias from the process. We’ll look at how to do that next...

 

4. Courtesy bias

Courtesy bias is the tendency to provide an opinion or give feedback that doesn’t entirely share your thoughts or beliefs but is more socially acceptable. It’s a bias that helps us avoid conflict.

A common example in research is users saying they love a product or service because they think that’s what you want to hear… even though deep down they think it’s pointless and would never use it in real-life.

Obviously, it’s a natural human response to try and shy away from conflict and confrontation. You could be led to believe that it's a British thing (or in my case, a very Canadian thing), but it happens time and time again – and across borders.

In terms of product design and user testing, it’s incredibly easy to influence decisions through our own actions and emotions. A simple look of relief can trigger a different kind of response in a user. They can see from our behaviour what actions make us happy, and what actions make us more concerned. As we explored above, the danger here is that you end up with a product your team loves, but that ultimately fails because it doesn’t truly meet your users’ needs.

It’s not an easy bias to overcome, but there are a few ways to help reduce it.

Explain the objective of the exercise thoroughly. For example, we always explain that we want real people, real customers, real users to try a prototype, and that we’re interested in their own experience.

Encourage all feedback. We will quite literally say to people, “You can be as brutal as you want!”. We want our users to know that we’re open to all forms of feedback – the good, the bad, and the ugly.

Keep an eye on your body language. It’s a tricky one, but even the smallest glimpse or gesture can deliver a message that changes a user’s behaviour. Try not to distract them from what they’re there to do.

Likewise, being mindful of how you speak can help you avoid both confirmation bias and the final form of bias we’re going to look at – the framing effect.

5. The framing effect

The framing effect is a concept that says that the brain purposely words things or puts things forward in a way that makes another person behave in a certain way. How we frame something shapes actions.

A real-life example would be saying, “Your glass is half empty, would you like a refill?” Well, sure! But if you were to say, “Your glass is half full, would you like a refill?”, the answer would probably be different.

When it comes to testing, it’s important to be careful about how you word things. It’s about making sure that you’re not putting together some very loaded questions that will impact your results.

Again, framing is a tricky one. But I do have a few tips that help you to avoid it:

Remove any positive or negative sentiment within your questions, and instead leave them open. Using the example above, it would simply mean asking, “Would you like a refill?” In testing, we wouldn’t ask what a person liked or disliked about a product, but rather what they thought about the product.

Go into testing with a clear script, in the same way that you’d come in with a plan for how you’re going to evaluate the results. When you have a solid script in front of you, it’s less tempting to go rogue. You’re less likely to start incorporating your own language and questions that may force users into one corner or another.

As above, be mindful of any non-verbal cues you might be giving off when asking questions. Keep your tone of voice as neutral as possible.

Easier said than done? Maybe…

Although we don’t like to make judgements without all the evidence, we can’t overlook the fact that bias exists for a reason. It’s a survival technique that can stop us from doing silly things.

So, I’m not going to sit here and tell you that you need to eradicate bias from your product design and user testing. Getting rid of it completely is likely to be very challenging – perhaps impossible – to do. And there are times when it can even help us to design better.

A better approach, in my experience, is simply to be aware that bias in design and testing does exist. Be on the lookout for ‘blind spots’ that can be created by biases from yourself, your team, your clients, and your users. When you’re aware of it, you can take steps to overcome it – and use it to your