This post is part of the series Four Collaborative Working Modes Take Digital Strategies to Consumer Reality.
Mode #1: User Research and Discovery
User research and discovery is not a task, deliverable or team, it is a series of important experiences that will drive your work long term.
Even the greatest user research document can only be read and experienced as a story in contrast problems you’ve seen and heard resound vividly in your mind and fuels the engine to find a solution. Information directly discovered from users by all individuals who will touch the experience will keep what really matters in focus throughout the work.
Listen and learn
In The Four Steps to the Epiphany Steve Blank keeps it simple in his proposal for Customer Discovery.
The goal of Customer Discovery is just what the name implies: finding out who the customers for your product are and whether the problem you believe you are solving is important to them.
To do this, you need to leave guesswork behind and get “outside the building” in order to learn what the high-value customer problems are, what it is about your product that solves these problems, and who specifically are your customer and user (for example, who has the power to make or influence the buying decision and who actually will end up using the product on a daily basis.)
You’ll see in this approach that there is nothing to weigh you down or suggest who is allowed to do it or how exactly this need be done, no certification, no approvals needed. It is simply about listening and observing, something everyone on the team can do.
Another simple tool to add to customer discovery that makes the output even better is The 5 Whys. The 5 Whys serves as a reminder that the first answer is not the answer that there is often a motivation, an emotion or a root cause behind it.
As Eris Ries, a big proponent of 5 Whys and ‘The Lean Startup’ author, says
“behind every seemingly technical problem is actually a human problem waiting to be found.”
Here is an interesting example from isixsigma.com.
Why did your car stop? Because it ran out of gas.
Why did it run out of gas? Because I didn’t buy any gas on my way to work.
Why didn’t you buy any gas this morning? Because I didn’t have any money.
Why didn’t you have any money? Because I lost it all last night in a poker game.
Why did you lose your money in last night’s poker game? Because I’m not very good at “bluffing” when I don’t have a good hand.
Use the 5 Whys to go down the rabbit hole. If you stopped after the first question it is clear the person just needs gas, problem solved, but after you are one or two whys deeper the complexion of the solution changes dramatically. It’s as simple as asking “why?” it doesn’t even need to be five times. Anyone can do this, and you’ll be amazed how much more you learn.
# “Listen and Learn” Assignment
Give everyone on the team the assignment to gather our raw materials, to get out of the office to a different place across town, find two or three potential users and bring back evidence on why that person is a potential user and a catalog of that user’s high-value problems. Emphasizing use of the 5 Whys when capturing the problems will only make the outputs of the exercise richer.
Fanning out the research in number, location and in background of your researchers will by it’s nature bring new information to the table that would have been left unseen. It is important to be aware of bias here, someone with a visual design background may see a missing beautiful interface, a developer may see a new technology needing to be installed, sometimes if you have a hammer everything looks like a nail but we can be careful to account for that when we review.
Our next step is bringing back the information into an informal white boarding session and keeping the discussion of your findings in the terms of problems not solutions, the more detail from the “whys?” the better. Coming out of this session you will have a strong depiction of who your user might be and the problems they have at the cross-over of your researcher’s stories. Capture this information any way you can, quotes, stories, sketches, mind maps, venn diagrams, whatever works for you. Document this digitally and share across the team as you’ll come back to this goldmine of information often.
Hypothesize and test
Now is an important time bring the team together on a handful early hypotheses for solutions and leverage our user researcher to ensure they are testable. If your team is struggling to create hypotheses bring them back to junior high science and remind them to follow “If… then… because…” and you will be many steps closer to a testable hypothesis. Researchers are well trained to create questions against hypotheses that decipher what people say they’ll do from what they’ll do or in their terms attitudinal contrasted against behavioral.
A few well constructed but brief participatory design sessions, field studies or crude prototypes can make a lot of sense here in response to the teams findings and hypotheses giving strong jumping off points for the next phases of the work. Christian Rohrer in his article “When to Use Which User-Experience Research Methods” describes methods to testing the context of product use even in this early stage.
For example, participatory-design methods allows users to interact with and rearrange design elements that could be part of a product experience, in order to discuss how their proposed solutions would better meet their needs and why they made certain choices. Concept-testing methods employ a rough approximation of a product or service that gets at the heart of what it would provide (and not at the details of the experience) in order to understand if users would want or need such a product or service.
With your user researcher now in the lead keep the rest of the team involved here as arms and legs, building paper prototypes, executing a field study guide or even just taking notes helps keep the work moving and the information top of mind for everyone.
Ongoing testing and optimization
Ongoing testing for the full product life cycle is a critical enabler of success. It extends from the information gathered here and returns to the methods of this mode. We’ll discuss this in more detail in future posts.
-Ben