User Research Is A Fool’s Game
Sometimes you could describe pursuing a career in user research as a fool’s errand; at times it’s a thankless task and whilst industries have wised up in the past few years to the benefits, it is still often the first thing to get cut from a budget when money is an issue (and when isn’t it an issue?!). Also, if you don’t have engaged stakeholders then you can feel like you are banging your head against a brick wall when it comes to getting people to implement your findings. But when it all aligns, it can be fantastically rewarding and no one without an inquisitive nature and thirst for knowledge would take the career path, so being foolish isn’t what we are talking about here. The key is knowing when to play the fool.
You should do this when you aren’t the expert. This is the case in a lot of formative research, particularly when you are new to your company/client/domain/project. Good explorative research involves ridding your mind of assumptions and opening yourself up to learning. One ethnographic method is contextual inquiry, and an established way of conducting this is by using the master-apprentice model [1]. Ultimately you are trying to learn from your participant, and to get them to explain their task/activities in a natural way by teaching someone to do what they do. Here, you should play the fool. The less they think you know or understand, the more they’ll explain, and often give some important details that they’d otherwise gloss over. Playing the fool creates a space for asking lots of questions. In user research we tend to have to ask a lot of things, and one of our challenges is to do this naturally, and without leading participants. This approach is worth trying.
On a lot of projects, it’s likely that you’ll end up conducting usability testing on your product or service. You might have conducted testing with countless people, you probably act as a pseudo SME in the time you spend out of the lab, or possibly even been closely involved in designing what you’re testing. You probably almost know a little too much about what you’re testing but nevertheless, each new testing session can add value. To ensure that you don’t unbalance the control in the session and make the participant feel like they are on trial and have to give the ‘right’ answers you should play the fool. It helps to coax participants to tell you more and can help you avoid asking leading questions.
Whilst we sometimes have to act the fool with our users, when it comes to stakeholders we are often expected to know everything. “You’ve spoken to the users…” “You’ve visited their workplace…” etc. This probably isn’t the time to play the fool! But if we don’t know or if we haven’t got the information then we shouldn’t pretend; any researcher worth their salt should be quick to admit when there isn’t enough information to give an informed answer to the question. It’s usually important to be able to give a plan or approach to answer that question though! That’s your opportunity to be smart.
Stakeholder pressure can be tough though, and at times we can feel foolish when we get a curveball question that we’ve never considered before. Embrace those occasions, as they are learning opportunities! If you’re on a project and you think you know it all, then you’ll inevitably become complacent. That’s probably the time to change project, because when you stop being receptive to what you don’t know, then you stop uncovering new things.
As researchers we have to be the voice of reason with product owners, stakeholders and a whole host of people that are involved. Sometimes we have to tell them things that they don’t want to hear, such as the assumption that they so doggedly stuck to in an ideation workshop was completely wrong, or that if they cut out feature X because it’s too expensive then the user isn’t likely to use their product/service at all. In many ways, this is our duty. Perhaps it’s fitting that in medieval times the only person that could speak plainly to their monarch, without fear of repercussion, was their fool.
Citation:
[1] Beyer & Holtzblatt, Contextual Design
