How to use guerrilla research to guide your project discovery phase
How to validate your value proposition with your users
One of the most important lessons I learned about user research was rejection by an experienced IBM job interviewer.
He asked me a simple question: “How would you go about doing user research in a hospital setting if they rejected your plan for user testing?” I then began to plan how I’d approach my stakeholders, try and provide them with reassurances to their fears, and win them over.
I probably failed the interview right then and there.
“Let me tell you a better way.” He said after listening to my response. “Go to a hospital cafeteria, buy a cup of coffee, and ask people if they have time to answer a few questions.”
That was my introduction to guerrilla research. But I never realized how useful it was until I found myself in a position to deploy it during Customer Discovery of a redesign. I understood and persuaded our team to modify our project goals to support our users better by doing guerrilla research. And I did this by understanding the value proposition we were offering to our users.
Guerrilla Research and the Value proposition
First of all, what is Guerrilla Research?
In her book UX Strategy, UX Strategist Jaime Levy talks about the idea of Guerilla Research. She references famous guerrilla fighter Juana Galan, in how she strategized, planned, and conducted a war against the enemy.
The main enemies for your team are probably time, money, and resources, because if you run out of them, you might never know if you’ve actually created an innovative but sustainable digital product. -Jaime Levy
Guerrilla Research may seem like other User Research methods. However, you can go straight to your users to ask questions, do testing, or do user interviews. But one of the most important (and valuable) differences is the idea of the value proposition. The value proposition is one of the most valuable things to assess early on because it asks essential questions like:
Are you targeting the correct customer segment?
Are you solving a common pain point the customer has?
Is the solution you are proposing something they would seriously consider using?
Would they pay for the product, and, if not, what are the other potential revenue models?
Does the business model work?
Some of these questions reach beyond what we would generally consider UX but are crucial for one key reason: will the users use the product? That can be an essential question to ask, especially with a redesign. The reason for this is simple: many times, users have found (and are currently) using a workaround.
The business may not like the workaround that users are using and may want to redesign the product. But if it doesn’t fit the user’s needs, they’re going to be reluctant to use it. So understanding the value proposition is vital. For example, it could be that your customer segment and pain points are correct. But if the solution that you are proposing isn’t something worth using, the users might not bother with the trouble. But sometimes, you might not get the official go-ahead to figure this out until much much later.
The need for guerrilla research during discovery
Even though I’ve been through the project discovery phase for many different projects, no two discovery phases have been alike. Typically, UX is supposed to be doing things like conducting stakeholder interviews, workshops, and other stuff like exploratory research. But sometimes, we don’t have the resources to do so. And it’s not always for the reason that you’d expect. Sometimes, you have the budget and resources for UX: it’s just that your stakeholders may be reluctant to spend it at this point. For example, the organization has the budget for UX to conduct three rounds of user testing with iterative design prototypes. In that case, why should they invest the time and effort to conduct research now when you haven’t even built a prototype/established what they want?
Keep in mind that they’re often working through feature backlogs. These list out the things that the product should do, the features they will build, and part of the product during this time.
We can significantly improve these things with user feedback, but you might get a lot of pushback if you want to run studies or interviews at this point.
This scenario is where guerrilla research can be beneficial, in the truest sense of the word. We’re seeking out user feedback around our value proposition and approach before the organization fully forms a ‘rigid’ set of features and goals over the course of several meetings. This way, we may have a better chance of changing their minds since they may not have invested so much time just yet. But you don’t have to conduct a huge research effort to do that. Guerrilla Research tends to be small in scope, quickly collected and focused only on a few things.
So let’s talk about understanding and validating the value proposition through Guerrilla Research.
Steps to conduct guerrilla research
Photo by Sammy Williams on Unsplash
The most important thing to know about guerrilla research is that it’s not a replacement for user research. if you have the chance to push for more rigorous user research methods, you should do it. The other important thing to note is that guerrilla research can be applied to nearly every research method, with mixed results. However, what we’re trying to do here is to validate our value proposition with our users.Here are the five steps we can take to do so with guerrilla research:
Step 1: Define your primary customer segment.
Who are you designing for? You may not know the exact users, but you’re developing for a particular customer segment.
We will refine this knowledge over time through working with your team. However, you should have a rough idea of who you’re building for based on the project goals and documents.
Knowing this is important because you may need to narrow down what data to focus on or collect.
Step 2: Identify your customer segment’s (most extensive) problem.
What do you think is the main problem that your customers face? Your team is likely to know this from a business perspective: it will reflect in the metrics if something is not performing well.
This problem may be one of the reasons why the project was chosen to be redesigned.
But metrics don’t capture the whole story. There may be signs (from user research) that there is a larger problem at stake.
For example, based on the average time on page metric, it might seem like users spend a lot of time on your home page without doing anything. But this may speak towards a large problem: your users can’t read the text on your website, so they’re not sure what to do next.
User research will uncover this more along the way, along with project documents such as goals. But it can be good to hypothesize about this.
Step 3: Create provisional personas based on your assumptions.
Personas should be pretty familiar to you, but you must get your assumptions down on paper. The typical mix of this includes:
Name and snapshot/sketch
Description
Behaviors
Needs/Goals.
As a side note, these are considered provisional personas because you haven’t done any user research beyond the basics. You will update this as you continue with your research.
Step 4: Conduct customer discovery to validate or invalidate your solution’s initial value proposition.
This is where you conduct your guerrilla research.
Within an organization, this usually takes three approaches:
Google Analytics (or other analytics tools)
Quick tests (like the 5-second test)
Conversations with previous test participants
Google Analytics
If your organization uses it for your project, Google Analytics can be handy to examine at this point. It costs your organization next to nothing to provide you with a log-in and once you learn how to filter out metrics that don’t matter, you can answer a lot of questions by yourself.
Analytics can answer questions such as:
Who are our users?
What do engagement metrics suggest may be the most and least visited pages?
How do users navigate throughout the site?
Do behaviors vary between devices, locations, or demographics?
Are there warning signs based on analytics tools such as page load speed calculators and accessibility checkers? Site performance and metrics sometimes provide us with improving our factors in our redesign work.
Once you learn how to read this data, this can be a gold mine of insights about your users and what may be the most extensive problems. This data serves as a snapshot of what users currently do, and can serve as an argument to investigate why users are running into these issues.
Quick tests
Quick tests, such as the 5-second tests, can benefit qualitative feedback when you can’t deploy a complete usability study. While limited, they also answer critical questions at this process, such as:
Do visitors like the brand look-and-feel?
Are landing pages catching the user’s attention?
Can users remember the important details about your page?
Do people understand the product’s value proposition?
One of the most important things that UX can teach your team is that users don’t read: they scan. If they can’t figure out what the value proposition is right away, then they may not explore the page further.
Conversations with previous test participants
User interviews are great if you’re able to swing it. But with guerrilla research, you might not follow the methods of interviews exactly. Instead, you might have a conversation with previous test participants.
Previous test participants usually are easy to talk with about projects, especially if you’ve built up a relationship through user testing. These may be the exact user segments you’re targeting, and it can be easy to ask them about certain aspects you have questions about.
But these conversations might not have the same rigor as an actual user interview: you’re talking with a biased sample of participants, to start with. Even though you should prepare like you’re conducting an interview, your research may not have the rigor necessary to call them ‘research findings’.
However, what you’re doing instead of contributing to the discovery process through exploratory research is trying to understand the problem space, framing the problem to be solved, and gathering evidence as to if our approach is correct.
So keep it small and simple in scope. However, the previous steps may provide some guidance as to what we might want to ask about:
What are the main problems that the user is facing with the current design? Are these different from what you might have expected?
If only a single thing changed about the current design, what would be the most important thing to address?
If we’re testing out a limited scenario or concept, what are the most important tasks to get feedback on?
How do users feel about this solution that you’re presenting?
What types of emotions (positive/negative) do they feel regarding the process?
Keep in mind that the point of having this conversation isn’t to test hypotheses or solutions: all we’re doing is trying to understand if our approach is going to be useful. But what we find out can often be incredibly beneficial to the discovery process.
Bringing initial user impressions to the discovery phase
If the people you work with don’t want to do customer research, do it for yourself. Do it on the sly without waiting for permission from your boss, the client, or any naysayers. What is crucial is that it is attempted. — Jaime Levy
The more projects that I’ve been on, the more I’ve come to realize that your team will likely be appreciative of the research you collect, even if they’re not quite sure of signing off on it.
This is where I like to think of two Jakob Nielsen quotes when he talks about Usability: “Any data is data” and “Anything is better than nothing.”
Guerrilla research is often polarizing because one of its downsides is that it can lack the rigor, methodology, and scope of a user test. As a result, it may not provide as accurate data as standard research, it’s not as useful for sensitive topics, and may not represent the targeted user base. But sometimes, getting your user’s input, especially during the early stages of product discovery, can significantly impact understanding whether your value proposition will fly with users. I’ve had coworkers who’ve gone through the entire process of designing and building a product, only for our users not to use the product at all. Preventing that sort of mishap and seeing how the value proposition tests with your users can be beneficial to find out in the discovery phase of your product.
You might have to go guerrilla to find that out.
Kai Wong is a UX Specialist, Author, and Data Visualization advocate. His latest book, Data Persuasion, talks about learning Data Visualization from a Designer’s perspective and how UX can benefit Data Visualization.