Asking a user what they want is a very poor decision, period. The reason for this, is because users are liars!
I know that seems like a very bold statement for an article about UX, and when I say this people are often a bit taken aback, but there is really no need to be. I don’t think users are bad people. I don’t think users have a sinister or underlying motive. I don’t even think users lie intentionally. Bias is often viewed as a bad word. Nobody wants to be biased! But humans by nature are exactly that. Whether you like it or not, psychology has shown time and time again that the human brain cannot be completely rational. In fact, there are around 100 known and studied cognitive biases. So being aware of a few of these should definitely help in your research. View a list of cognitive biases.
Why you should never ask the user what they want
It seems pretty logical to ask the user what they would want your product to do, right? You may think:
‘If the user tells me what they want, then they’ll certainly use that if I create it!’
The problem is, you’re asking the user to envision something completely unrestricted. The only boundary you have set is the realm of possibility. The lines between what they need, what they want, and what they can only imagine are now utterly blurred.
The user is going to think for a short while, and then lie to your face. They are going to make up a bunch of features that they think they would want in the product, and then tell you that they would use it if those were present. The reason the user will probably not actually use your product or those features, is that humans often have no insight into their own thought process. The users at this point probably have no idea what they need themselves, which makes their testimony completely unreliable.
You may try to counter this problem by thinking up a feature yourself so you can pitch it to the user. Problem solved.
‘Imagine if we built this into the product, you’d find that helpful, right?’
Again, the user will probably think for a moment and then lie to your face. ‘Yes’ is probably the answer you will hear nine times out of ten. The reason for this is that the user still doesn’t know what they need, and you are still making them try to envision something that they can’t physically see. Even if they have no idea what you are describing, they will probably tell you what they think you want to hear, because saying yes is easier. There are no awkward follow up questions after the answer yes, and they have absolutely nothing to lose; it isn’t their time or their budget that will be wasted on this utterly pointless feature.
Ok, third time lucky! We will show them something!
‘I’ll take my ideas, design a few versions and ask the user which one they prefer.’
Now we are getting somewhere. Now the design is within the boundaries of the budget, and the user can see what it will look like when it is finished. Job done. Hmm… Not exactly.
You take four versions into your testing session, and you ask the user which one they prefer. Because the user still has no idea what they need, they will simply make a decision between four things that look very similar and tell you their favourite. When presented with similar designs one after another, the human brain will have a tendency to favour the last one because it is the one it can remember the most clearly. And when presented with several designs at the same time, the brain will often favour the one farthest to the right. Now, when you press the user to explain their decisions, they will probably be able to. But again, they will be lying to your face. Introspection illusion is a cognitive bias where we will attempt to explain our decisions as if they were conscious, despite them being made completely subconsciously.
There is an interesting study by Richard Nisbett and Timothy Wilson about four identical garments that the customers convinced themselves were different. The two items on the right racked up 71% of selections, the furthest right taking the most with 40%. When asked to explain their decisions the customers said that the garment furthest to the right had the best quality, despite it being identical to the others.
So what does this mean for your research?
Before designing anything, you need to first work out what the user need actually is. To do this, there is only one thing you need to ask your user; ‘WHY!’
By asking why, you are not asking your user to envision anything or critique your design. You are simply getting to the root cause of their problem. It is often easy to identify a user need too high up the chain, in which case you are only fixing part of the problem.
For example, a person you know got caught speeding. Anybody could be forgiven for thinking some sort of speed camera detection device would be the obvious user need in this case, but just ask why a few times.
‘What’s the problem?’
‘I got caught speeding in my car.’
‘Because I was late for work.’
‘Because I slept in.’
‘My alarm clock didn’t go off.’
‘The batteries have died.’
‘Because I didn’t know they were low, so I didn’t replace them.’
If you took the above example, and started working on the fact that the user got caught speeding, you could be designing the wrong thing for an assumed user need. The user need was never to speed and not get caught. The user need was to be on time for work. As we move down the iterations of why, you can see that the need gradually shifts away from the motoring offence and ends on the user simply being unaware their alarm clock batteries were running too low.
Once you think you have established the genuine user need, you should break it down further to understand what you should be designing. I use three questions to build a hypothesis for anything I am designing.
Gather an understanding.
Q: What is the user trying to get done?
A: Be on time for work.
Analyise their workflow
Q: How do they currently do this?
A: Battery powered alarm clock
Look for opportunities
Q: What could be better about how they do this?
A: Warning / notification system for low batteries. Alternative power supply.
Ok, user need established. So what now?
Building ‘the thing’ is far easier once you have a genuine user need. Build a cheap prototype version and watch users try to complete their task by using it. This will teach you far more about your product than any other method. If you can’t physically watch your user, then make sure you have ways of tracking data to get an understanding of what is going on. It becomes very apparent where the problems are. Which parts are they finding easy? Which parts are they struggling with?
Iterate the parts the users are struggling with until they become easy. If there is a genuine user need for your product, then users will likely persevere with the bad parts long enough for you make them better. Without a user need, anything that makes the user struggle is likely to make them abandon your product forever.
Don’t build what users tell you they want. Build what you see them need.