You’ve Been Framed! The Hidden Trap in Your UX Requirements
In Starck Explications, a manifesto published in 2003, industrial designer Phillippe Starck tells the story of a prank he pulled on a client who wanted to commission a boat.
“Have you thought about this properly,” asks Starck. “Do you really need a boat?”
We can only imagine the client’s response. Maybe he wants the idea of freedom, of being out on the open water. Perhaps he waxes lyrical about the space and the calm, the refreshing water and invigorating sea breeze.
“Have you tried swimming?” says Starck. So the guy goes swimming and later, he comes back to thank Starck. “You have done your job as a designer,” he says. “I had forgotten how good [swimming] was. I do not need anything else.”
What does this story tell us?
It tells us that we don’t always know what we want, and we’re not as rational as we think. The human brain is full of biases that trick us in ways that we don't expect, and that we don't intend. Left unchecked, these biases can lead to disastrous results – like wasting millions on a boat when all we want is to swim in the sea.
What is framing bias?
In the context of UX design, the biggest and most essential bias is framing. This is the tendency to make decisions based on whether the options are presented in a positive or negative light. For example, more people choose a yogurt that is described as being “90% fat free” than a yogurt described as “containing 10% fat.”
This example may seem trivial. But science shows that we apply the same level of framing bias to ultra-important decisions as we do to everyday decisions – things like choosing investments, plea bargaining in criminal trials, and even situations of life and death.
In one groundbreaking study, participants were asked to choose between two hypothetical treatments for 600 people suffering from a deadly illness. Treatment A was predicted to result in 400 deaths – a 66% mortality rate – yet seven out of 10 participants chose it when it was presented with positive framing (“saves 200 lives''). This number dropped to just two in 10 when the same information was presented with negative framing (“400 people will die”).
How does framing impact UX design?
Framing bias flows through the design process like a lazy river, but the most common place we find it is in the wording of questions during user interviews or usability tests. Nielsen Norman Group gives the example of a usability test where the outcome was described in two different ways:
See the difference? When Nielsen Norman tested both versions, 51% of designers opted for a redesign when presented with Option A, compared to just 39% of designers who saw Option B.
Long story short: Beware the evils of framing, as it can negatively influence the decisions you make in the best interest of the product.
How do requirements ‘get framed’?
It isn’t just designers who fall victim to framing bias – clients and companies do too. This shows up in the project requirements and it’s a critical problem. Because if the brief is off, everything that comes after it, no matter how good, is fundamentally tainted.
There are four main reasons why requirements ‘get framed’:
1. They come from the top down
Requirements are often written by senior executives who are several layers of management removed from users on the ground. This introduces a ‘false-consensus bias,’ which is the tendency to overestimate the number of people who think the same way that we do. When false consensus is in play – and it is almost always in play – the people writing the requirements will assume that everyone sees things through the C-suite lens, and they will be completely blindsided by other opinions. You are not the user!
2. Office politics
Almost everyone in corporate life has an agenda, whether that’s a product they want, a budget they want, or the desire to impress an important stakeholder. While most agendas are hidden, the way they show up is in a form of confirmation bias – when we see an example of something that appears to fit our agenda, we’re poised to swing at it, even if it means rejecting any evidence that proves our opinions wrong. When confirmation bias seeps into the requirements, they end up being framed to give the answers that you already know and want to hear. What value are you getting from that?
3. Sunk-cost fallacy
The sunk-cost fallacy is our tendency to keep pushing through with an endeavor that we’ve already invested time, effort or money into, regardless of whether the costs outweigh the benefits. It’s why we drag ourselves to a concert that we bought a $50 ticket for, even though we feel sick, the trains have stopped running and we have to drive for two hours through a blizzard. We bought the ticket, so we’re darn well going to attend!
Now, you might think that the sunk-cost fallacy only shows up late in the UX process, perhaps when the designer has spent weeks creating pixel-perfect UI mockups and is not going to abandon the design just because a few users say it’s awful. But that’s not true at all. Clients invest a lot of time pre-roadmap – discovering they have a problem, empathizing with users, noticing what competitors are doing, wrangling a budget – and they’re not rational. They’ll keep going with these ideas even when the frame is wrong and the return on investment is not available anymore.
4. Bandwagon bias
Bandwagon bias is a type of groupthink where you take action simply because others have done so. For example, you might have an idea to move all your paper-based processes to iPads because you’ve seen this work in other industries and feel you must "jump on the bandwagon" and have it in yours. Problem is, your users have no idea how iPads would improve their day-to-day – their work is too collaborative, they don’t all have unique accounts, people need to log out before others log in etc. Framing from the bandwagon is a recipe for disaster since it almost guarantees that you’ll be throwing money at the wrong problem.
Bottom line: Don’t build solutions in search of a problem!
David Dylan Thomas, author of Design for Cognitive Bias, recommends a bias-busting technique called ‘Red Team, Blue Team.’ In this exercise, the Red Team’s job is to uncover all the hidden flaws and harms that the Blue Team missed because they were so in love with their idea. Simply, their job is to unpick the frame.
So, next time you find yourself getting frustrated because your design team is pulling your requirements apart and asking tons of questions, understand that we are your Red Team. It’s our job to say no, challenge your perspectives, uncover your biases, play devil’s advocate, and refine your ideas until we are certain that you are solving the right problem. Only then can you avoid the pitfalls of developing products that no one wants or needs, and go swimming instead.