(Originally published on Product Coalition)
User research studies give valuable information that product teams can use to inform and evaluate the work they are doing. The new book ‘Building User Research Teams’ covers all of the steps to integrate user research into a product team’s work, reducing financial risk and getting to better decisions quicker. This extract from the book explores why recognising how decisions get made is the first step to achieving that.
Every company makes decisions about what they should build or do. Some companies come up with ideas for new products or services to build and make them happen. Others iterate on an existing product, deciding which features they should add, or what future updates should allow users to do.
Those decisions are informed by a whole variety of sources. Some of those sources are trustworthy, such as using analytic data to draw conclusions about what people are doing currently. Some of those sources are less trustworthy — such as the CEO reading an article about blockchain whilst on a plane and deciding that it is the future.
The goal of a user research team is to improve the quality of those decisions by providing accurate information about user behaviour that informs and evaluates the work and assist everyone in doing a good job.
However, it is not as easy as ‘start running studies and good things will happen’. Many organisations are unaware of the consequences of their current inefficient development process and are happy with the status quo. Building the case for how user research can help improve development is essential groundwork required before research can be truly embedded in how things are made and prevents the findings from research studies being dismissed later.
How design happens
To recognise how research can help decision making, it is important to first recognise what the decision-making process currently is. There are a lot of different ways in which the ‘design process’ has been explained before, and models from GDS’s ‘Discovery’->’Alpha’->’Beta’->’Live’, to the Design Council’s Double Diamond which has the steps ‘Discover’, ’Define’, ’Develop’ and Deliver.
At the core of every model of how design works is a process that involves:
- Defining and refining the problem, from a vague idea of what the domain for the problem is, to a clear ‘this is what we want to fix’ decision.
- Creating and evaluating potential solutions that fix that problem.
- Refining one (or more) solution until it’s ready to be put into the world.
These models seem very sensible, and when followed lead to the development of appropriate solutions to problems that exist in the world — design is second only to ‘luck’ (and possibly ‘marketing’) as a factor that will lead to creating something successful. They are applicable to broad topics, such as the creation of an overall product or service, and on a smaller scale for the development of individual features for an existing product.
Even companies that don’t explicitly describe their design process probably follow steps very similar to these. A start-up pitching a new app for ordering toast by post should start by exploring whether there is a need for people to get breakfast items delivered to them. Having established that there is a need, they would then test whether ‘toast by post’ is the right method — perhaps ‘grilled pike by bike’ would be better for delivering appropriate items in the correct way. Only with the confidence that they are solving a real problem in an effective way would it be sensible to then proceed with making and marketing an app that does this.
This process also crosses sectors, even to industries that would describe their process as creativity — a game designer looking to teach players how the inventory works within their game will follow the same steps of defining what it is they want to teach, trying a method of tutorial that will teach it, and then testing to see if it works as intended.
A ‘good’ solution will consider multiple dimensions — whether it is possible to create within the time, budgetary, and technical constraints that exist, what the ethical impact of that solution is, whether they have the expertise required to build it. However, one of the most critical things when assessing the suitability of a potential solution is understanding its impact on users — is the solution being proposed dealing with a real problem? And does it work as intended for the people using it?
Because of this, a successful design process is very reliant on understanding the users of a potential product in order to land on creating a good solution. This is where user research fits in.
Where research fits in
Let’s return to the model of how design happens:
And then look at the bits where understanding users better can help.
Early in the development of an idea or feature, understanding the audience it is for will lead to better quality decisions about what to do. By developing a shared understanding about user’s goals, their context when acting on those goals and the issues they have currently, smarter decisions can be made about what should be made, and how it should work — for example, if we learned that most people requiring breakfast items in the morning already have cereal in the house, but are frequently out of milk, a new start-up may realise that creating an app to manage a daily milk delivery is more likely to be successful than toast by post.
Later on in development, the product team will have come up with some ideas about what to build. Research can help evaluate those ideas before they have been baked in and can no longer be changed, allowing the team to change course if needed and refine the implementation of their idea.
In real life, projects do not follow this process linearly, and there is a lot of movement between these types of research — for example, while evaluative research is looking at the implementation of an idea for a product, new spikes of activity to add features may require new discovery research about the audience and their behaviour to occur. This means that all kinds of research will likely be occurring throughout the development of the process — it is just the frequency of how often that type of research occurs that will change.
The challenge for organisations that don’t already have a research team is helping them recognise their existing design process, and how research fits into how decisions get made. The book ‘Building User Research Teams’ goes in depth on some of the methods for achieving that and give a step by step guide to building a new user research team.