Get hands-on practice in all the key areas of UX and prepare for the BCS Foundation Certificate.
It is a truth universally acknowledged, that a project team in possession of a UX budget must be in want of a research question.
Surprisingly, many customer and user studies do not begin with a considered research question. Instead they are motivated by uninteresting and superficial objectives such as the need to "do some research", "get some insights", "hear the voice of the customer", or "find some user needs."
These goals are not only uninspiring and reflect a lack of genuine curiosity, they are also too vague, too broad, and too unfocused to form the basis of an effective investigation. They are guaranteed to result in poor quality 'throw away' research that returns mostly obvious findings.
The first step of any research endeavor should be the development of a research question that will provide the central core around which an investigation, its methodology and its data analysis, can be developed.
By 'research question' I'm not talking about lists of questions you might generate and expect respondents to explicitly answer, either in an interview or in a questionnaire. I'm referring, instead, to the underlying question that describes the purpose of the research, and that guides the design and focus of a study.
For example, your question list may well ask a respondent, "Do you like coffee?" or "How many cups of coffee do you drink in a day?" or, "What's your favorite brand of coffee?" but your underlying research question is, "Does drinking coffee affect employee productivity?" This is not a question you can directly ask of anyone and get a useful answer but it is the focal point and driving force behind your investigation.
Without a specific research question, studies lack the ability to penetrate a problem. They skim the surface and risk becoming purely method driven. Instead of exploring new territory, they simply retread the same worn pathways, collect the same old user responses, and culminate in the same tedious research presentations that are guaranteed to put your design team to sleep.
In contrast, an effective research question will:
"Going beyond the obvious" means pushing limits, asking new questions and venturing into new territory, or venturing deeper into territory you may have only tentatively visited before. We've talked previously about thinking like a detective, but at this stage of research planning we must think like an explorer — and as an explorer, you need to break new ground, otherwise you're doing it wrong.
We're often so eager for answers and solutions that we overlook the importance of a strong research question. But it is the question - not the answer - that is the most important part of research. As Jonas Salk put it:
"What people think of as the moment of discovery is really the discovery of the question".
We can avoid recycling the same old questions simply by shifting the starting point for our thinking. I'd like to describe one way to do that.
In a recent article, David Travis used an interesting analogy to differentiate field visits from traditional interviews. Here's what he wrote:
"A field visit is much more than a pop-up user interview in a coffee shop. To use the analogy of animal behaviour, an interview is like a visit to the zoo whereas field research is like going on safari. With field research you observe real behaviour: you see what people do, not listen to what they say they do. In short, you go where the action happens."
It's a good analogy. What's more, it leads us to an interesting way of shifting our research thinking.
Imagine trying to learn something new and interesting about a particular animal by observing it in a zoo. Stripped of its need to fight for survival or hunt for food, it will probably be either pacing its cage or sitting motionless for hours, or sleeping in a corner. Worse still the animal may have developed abnormal behaviour, sometimes called 'zoochosis' repetitive, invariant behaviour patterns that have no obvious goal or function. Any opportunity for observing natural behaviour is lost because the animal's natural environment is missing.
That's why you never see Sir David Attenborough on his hands and knees observing animals in a zoo.
The same is true of interviews. Just like in a zoo, you typically remove the respondents from their real world environment and put them in a room where their unrepresentative 'made up' behaviours can be observed from a distance.
In contrast, on safari there are no constraints placed on the animals and they are running wild. They are in their natural environment with all of its pressures and dangers, and their natural behaviours and reactions to all kinds of situations are on display. The same is true when we conduct user research and observe people going about their real world activities.
So, the zoo vs. safari analogy works well. But what if we push this analogy a step further? What if we acknowledge the self-evident, though seldom voiced, fact that all customer and user research is actually the study of animal behaviour.
I sense a few raised eyebrows. But let's agree that this at least puts a different spin on things. Now let's see where it might lead…
In 1963, Nobel Prize winning zoologist Niko Tinbergen published, 'On the aims and methods of ethology' in which he outlined four questions (sometimes referred to as Tinbergen's four problems).
He argued that, far from simply recording any specific behaviour and taking it at face value, the behaviours of animals (including humans) can be characterized by answering each of the four questions. Professors Paul Martin and Patrick Bateson summarize Tinbergen's questions in their own book, 'Measuring Behaviour' (a 'must read' for any user researcher, by the way). As I can't improve on their summary I'm going to paraphrase them here:
These seem like very good questions, and it is clear that they will help us avoid easy, quick and superficial explanations, and guide us towards a more thorough, insightful and detailed understanding of a specific behaviour. But, before we consider how we might use these questions in our user research, let's apply them to a specific everyday behaviour and see how they produce different kinds of answers.
Because it's the law. The answer is obvious and not very interesting. But what would the answer be if we explained this behaviour in terms of Tinbergen's four questions?
I want to avoid causing an accident, being injured or injuring someone else. I also want to avoid being pulled over by a cop and getting a ticket.
I perceive a visual stimulus that excites my colour receptors and I process this information in my central nervous system, which triggers a specific response. The response results in me taking my foot off the accelerator pedal and pushing it down on the brake pedal.
I learned this rule by reading the Highway Code, and from my driving instructor, and by noticing that other cars, including cars on TV and in movies, also stop at red lights.
Historically, a red light has come to be an almost universal signal for controlling traffic at road junctions. They were first used in 1868 in London and involved gas lighting and semaphore arms. The first electric traffic light was employed in Salt Lake City in 1912.
All of these answers are correct, all of them are valid, but all of them are different. The resulting explanations complement each other and reveal facets of the specific behaviour that we may otherwise have missed. The four questions are logically distinct, and one way to think about them is as a set of four new tools (tools for probing, lenses for looking through) that you can use to approach a topic from new and different directions.
Behaviour is complicated and it follows that simplistic, trite, unimaginative and uninteresting questions leading to obvious answers won’t do. Tinbergen's four questions can give us a way of revealing insights that we might otherwise miss.
These four questions fit nicely into our field research toolbox. Now, instead of focusing primarily on just observing and recording behaviours, we can get more focused and start to 'unpack' a given behaviour or user interaction, and collect data that our previous 'blunt' questions could not detect.
Let's take a look at each of the four questions again, but this time in the context of a field visit in which the behaviours of interest now include specific product or system interactions.
This is the closest to the kind of implicit question we typically ask.
This question invites us to ask:
This question requires us to understand how the behaviour came about.
We can often move our understanding forwards by first going backwards, and this question invites us to do just that. Thankfully, we don’t have to worry about geological time scales, but we can certainly go back decades, if necessary, and discover the evolutionary history of a product or system and the origin of a behaviour.
Try including these four questions next time you carry out your field research. Ask them of each example of user behaviour you identify. Use them as a framework around which to design a study that avoids mundane 'top of mind' questions, banal answers, and uninsightful insights not to mention mind-numbingly dull presentations.
Tinbergen, N. (1963). "On aims and methods of ethology." Zeitschrift f'r Tierpsychologie, 20.
Martin, P. & Bateson, P. (1986) Measuring behaviour — An introductory guide. Cambridge University Press.
Dr. Philip Hodgson (@bpusability on Twitter) has been a UX researcher for over 25 years. His work has influenced design for the US, European and Asian markets, for everything from banking software and medical devices to store displays, packaging and even baby care products. His book, Think Like a UX Researcher, was published in January 2019.
Gain hands-on practice in all the key areas of UX while you prepare for the BCS Foundation Certificate in User Experience. More details
Our most recent videos
Our most recent articles
copyright © Userfocus 2021.
Get hands-on practice in all the key areas of UX and prepare for the BCS Foundation Certificate.
We can tailor our user research and design courses to address the specific issues facing your development team.
Users don't always know what they want and their opinions can be unreliable — so we help you get behind your users' behaviour.