Hello and in this episode of the UX tea break I look at identifying assumptions in user research.
This question comes from Mariam. And Mariam asks: "Could you give a more detailed explanation of 'assumptions' in user research and how to identify them?"
I wanted to pick this particular question because I found it interesting. Because many years ago, back in the day, when I was first doing user research I wouldn't have said that we really spoke in terms of 'assumptions'. I mean we went out and we did research and we tested things; but I never actually thought of myself as going out and 'testing assumptions'. But more recently, with the advent of Lean, we've got this approach to doing user research kind of based on the scientific method — or at least the experimental method — where we find assumptions and hypotheses that we need to test or validate one way or the other.
I think generally it's probably a good thing: I think it certainly made people think more in terms of why user research is important. But for the purposes of user research I'm going to define an assumption as: 'a belief that the product team hold about users, their goals, or about the context of use (the environment that the users are in)'. And by 'belief' I mean something that the product team believe is true.
Now three things make those assumptions testable I think. The first place to look is to check whether or not the assumption that's being held is actually based on any data — or at least based on strong data. If it's based on anecdote or if the belief is based on some focus group that's been run or if it's based on some opinion data, then the chances are that that's an assumption that needs to be tested — because it's not based on solid data. And that almost always means from a user research perspective, the kind of data that you want to use to prove an assumption as either being true or false is it's going to be field research that you've done in context with users. Or it's going to be usability testing of a particular product idea — depending on where you are in the lifecycle.
The second way of checking whether a user whether an assumption needs to be tested in user research is to ask whether or not… could the opposite of that assumption be validly held? Here's what I mean by that. Imagine that we were working on a new kind of home entertainment system — some kind of new Smart TV. And the product team believe that users will be able to download and install an app on their phone which will then allow them to configure this device that they've bought. Now somebody on the team could equally hold the opposite hypothesis or assumption. They could say, "Well I don't believe users will be able to do that. I don't think… I think that's kind of one step too far for them." That would be an example of a good assumption to be tested because we can hold it one way or the other. In contrast, if the product team hold an assumption like 'Our users need a product that's easy to use'. If we cast that as the opposite, would somebody logically be able to say, 'Our users want a product that's hard to use'? Obviously not. That would be a bizarre thing to say. That doesn't mean that we don't want the product to be easy to use. But what it does mean, is it's not a particularly useful assumption. It's not something that we can easily test. We need to be much more specific than that.
The third aspect of the assumption that makes it testable is to ask, "If the assumption's wrong, would it encourage us… or would it mean that we need to design a very different kind of product?" What I mean by that is some assumptions that the product team hold aren't that important. So for example they might think that their users are between 35 and 50 without any kind of evidence to back that up. Or they might believe that their users earn thirty thousand a year or something. So those are assumptions that they hold. But I'd argue they're not that important because they're not going to have much of an impact on the use of the system. In contrast, something which is focused on users' needs that we've got wrong is a much more important assumption to test. So for example, let's say that we were designing an app for chess players and this app… we have an assumption that users need to be able to save lots of opening moves in chess games so that they can use those to learn how to play chess better. Well, if we actually did our research and we discovered that chess players aren't interested in that, but they do have a need for something that allows them to record all the moves in the games that they've lost so that they can review them afterwards — we've tested an assumption and found something else out to be true. Which then means we need to design a completely different product. So if the assumption is wrong will it cause us to design a different kind of product? That's another example of an assumption there that needs to be tested.
I hope you found that useful. If you did, please give the video a thumbs up and subscribe to my channel — and even better ask a question below and I'll get around to it in a future video.