Generative Research: Everything You Need to Know to Run a Successful Study
Exploratory, discovery, problem-space, foundational...generative research goes by many names. But its objective is always the same: know your users better, so you can to design for them well. Here's a comprehensive framework to get you started.
Words by Nikki Anderson, Visuals by Emi Tolibas
Generative UX research is “next level” research. It moves us beyond tactical inquiries (like we see with usability testing) and towards a more strategic user understanding. It enables us to direct the way a company innovates, and it’s a challenging method to master.
The best way to learn generative research is by doing it—which begs the question, “But how do I start?” Or for more advanced practitioners, “How do I ‘practice’ better?”
This guide will equip you with everything you need to start strategically and practice well.
Generative research is defined as research that deeply “generates” an understanding of who your customers are (as humans, not as users), and what they experience in their everyday lives. It’s a style of interviewing that allows us to dig into a person’s identity beyond their screen, and beyond their interaction with our product.
And sure. We’re still trying to understand how a product or service impacts these folks. But knowing their everyday lives should impact the way we build our product or service.
I can’t stress the importance of this concept enough. To prove my point, I’ll give you an example of a time when my team thought we’d asked all the right questions.
The product we were working on was relatively simple: it provided e-commerce companies with a social media repository. They could use it to aggregate the posts they were tagged in, and then repurpose those posts for their own, authentic, user-generated marketing efforts.
So first we asked companies how we could make the product better, and what features we could add to make their lives easier. We were product-centric, not user-centric; we acted as if the user revolved around our product, rather than the other way around. With that mentality, we missed a lot about their pain points and needs.
Finally, once we started doing generative research, we learned about our users’ lives and workflows. We found that they’re trying to put reports together early in the morning for overseas clients. We saw that some of them wanted to use their commutes to go through some of the social media in the repository.
Some of our users were trying to look good in front of their bosses during stressful presentations, so as to potentially get a raise or a promotion. Many of them had families and were looking to be more efficient so they could get home earlier to see children and partners. Armed with this knowledge, we could develop features far past our initial, product-centric scope, which helped our users so much more than we could have imagined.
This information was invaluable, but it would’ve been impossible to come by if we asked about features. Generative research, instead, gets people to tell important stories about their lives that go far beyond a product or a service. It gives you rich information about their overarching goals, needs, motivations, and the why behind their behaviors. And that why behind someone’s actions will give you the information you need to positively impact their life.
Generative research tells us why people are doing things and what they are thinking in a given moment. It takes us out of the product and into the lives of the people we are trying to help. We can easily get stuck in a box when we think about a product, and, with that, we can become quite short-sighted. We only think about things within the product, instead of the greater impact.
Generative research helps us break those boxes in order to come up with a truly delightful and helpful solution to a user’s problems. Instead of starting with a solution, and trying to work backward, you are actually entering from the problem-space.
This style of interviewing allows us to uncover the deeper motivations and actions behind why users are doing certain things. It’s really easy to look at quantitative data and see what people are doing on your website or app, but it is literally impossible to know why they are doing those things through this data. This is where the qualitative bit of user research comes in, and where generative research really shines through.
By taking the time and effort to conduct these sessions, we are able to get valuable information that paints a picture better than any standalone persona or customer journey map. This enables us to do a few very important things:
Better prioritize work
Have confidence when deciding on new features or product areas
Understand and empathize with the users’ situations
Build a product roadmap and vision
Another wonderful thing about generative research is that you can really do it at any time. I prefer to run a study at the beginning of a product’s life, or the start of a company, rather than further down the line. However, you may not always have a say in your company’s research timeline.
For example, if you get hired as a user researcher at a company that is already established, you might hope there has been some foundational research conducted—while also mentally preparing yourself to fight for generative research projects.
Although the value of generative research may be clear to some, it can take more time and effort than other methodologies, such as usability testing.
It can be difficult to get buy-in from stakeholders on something that is, seemingly, high effort when people are unsure about the return. Sometimes this can feel like jumping over hurdles. So how do you clear these hurdles? By treating your stakeholders like users.
While there are different approaches to getting buy-in, here’s one that’s particularly effective: performing user research on stakeholders by understanding the why behind the pushback.
When a stakeholder says “no” to your user research project, it can feel deflating and frustrating, causing you to become defensive. Would you ever get defensive while speaking with users during an interview? Hopefully not. So, why would you do that to stakeholders? Essentially, they are your users too. While they aren’t using the product/feature in question, they are still an audience you need to understand and cater to.
When a user gives you feedback during an interview, you ask them why they feel or think a certain way. Why wouldn’t that be the same for stakeholders? You want to create an open space, for both your stakeholders and users, in which you are able to facilitate a conversation filled with empathy and understanding. If that isn’t user research at its finest, I don’t know what is.
What are some questions to ask your stakeholders?
Why do you feel negative about user research? - This will help you understand the best ways to quell their fears
Tell me what happened the last time you did user research. - This will help you understand the fears or expectations stakeholders may have
What is your ideal timeline and approach for this project? - With this, you are able to find ways to insert user research into their timeline
What are the biggest barriers to conducting user research on this project? - You can begin to understand how to best fit research in, so it overcomes these specific barriers
If we could manage to do any user research on this project, what would it be? - Opens the conversation up to discover what they think user research might mean for this project
What could be some ideal outcomes of user research on this project? - Highlights the potential positive outcomes of user research
I’ll take you through a sample generative research project, including the different aspects and templates needed to start running your own generative research sessions. Some of these steps can be done in parallel (such as writing up the research script and recruiting).
Research projects can come from many different people: within your team, from your own previous research, from high-level executives, investors...you name it, and you’ll get a research request for it. Whenever a research project lands on my desk, regardless if it came from my own ideas or someone else’s, I have to determine what kind of research is needed in order for the project to be deemed as successful.
Within this, there are a few foundational concepts to evaluate:
How will we determine what type of research method is needed for a project?
How will we define success?
Although this may sound backward, the way I choose a research methodology for a given project is by starting with what we would want the outcome to be. If the idea didn’t come from me, this means having a meeting with the original stakeholder, and any relevant people, to determine their goals for the research.
This is even relevant when you come up with a research project on your own. Whenever I go into a meeting about an upcoming research project, I am armed with the following questions:
What questions do you want to be answered with this research project?
What types of answers are you expecting or assuming? (Great for uncovering biases!)
What is the ideal outcome for you?
What decisions are you trying to make with the insights from this research project?
Not only does this really help me in better understanding the point of the research project, but it can also guide me in picking the correct methodology, and even determining whether or not this project makes sense for user research. Sometimes, it might make sense to prioritize other projects or suggest other methods for teams to test their ideas (ex: A/B testing, painted door tests, surveys).
With this information, I can understand the team’s expectations and what they are trying to achieve in the end. Without this knowledge, it is almost impossible to choose the best methodology for the project.
Imagine you’re working as a researcher at an online food ordering service, which allows you to order takeaway delivered to your door from restaurants in your area. You’ve just started working, and they haven’t done much in terms of strategic research—it’s mostly been tactical usability testing.
One day, a project lands on your desk. A product manager wants to know how to get people to order takeaway more frequently. It appears to be a great initiative and makes a lot of sense. However, as researchers, we must use our levels of curiosity to push us past the surface level. You schedule a meeting with the product manager in order to better understand exactly what they need from this research. You have your list of questions ready to go:
Why are we focusing on getting people to order more frequently? What KPIs are we hoping to impact?
Are we looking at new customers or only active customers?
What is the current average order frequency? What are we aiming to achieve?
What additional questions do you have about this topic?
What decisions will you try to make with the insights?
What answers or outcomes are you expecting from this project?
Initially, the product manager thinks this could be a simple, tactical usability test. We could watch users interacting with the app and see where the pain points are when they try to order again. From the product manager, you learn the following:
He wants to increase retention rates, user satisfaction and, ultimately, customer lifetime value.
Primarily, he is interested in active customers (those who have already placed one order), but is also willing to look into new customers.
The current average order frequency is about 2.3 times a month, and he wants to aim for four times a month (once a week).
The additional driving questions are: why do customers not order more frequently and what makes customers decide they want to order?
We want to find out which part of the journey has the most opportunities, what the drivers are for loyalty, and what pain points stop people from continuing to order.
He would expect a final report to inform him of: opportunity areas, customer problems, and an indication of where the team should focus their efforts to improve retention.
Wow, that is a lot more information—and the hoped-for results go far beyond “how do we get people to order more.” So, with this meeting, we have gently switched the mindset away from the solution-space (how do we get people to order), and towards understanding the potential problems people are facing. We have moved from the more product-centric views toward a more user-centric view. For just one meeting, that is a really great start.
Through this meeting, you can easily see that this research is much more foundational. Here’s how you can determine that: keywords. There are common keywords that associate themselves with generative research versus the more tactical evaluative research.
Although this isn’t an exhaustive list, it demonstrates that evaluative research keywords are much more action-focused, while the generative research keywords are more focused on achieving high-level understanding. If the expected outcomes of a project leans more towards these strategic outcomes, you know the best methodology will be that of generative research.
So in this case, we have a generative research project on our hands! Now, the next step is the research plan.
A user research plan is a concise reference point for your project’s timeline, goals, main players, and objectives. It’s not always used extensively after the project has started, except to remind stakeholders of a project’s purpose, or to explain certain logistical decisions (like why certain types of participants were recruited).
Research plans keep the entire team focused on an outcome and provide an easy reference to keep “need-to-know” stakeholders in the know. Most importantly, they allow researchers (or whoever is doing the research) to ensure the objectives of the plan will be answered in the most effective and efficient way possible by the end of the project.
We have a full walkthrough for putting together a research plan here—but let’s run through the basics.
The 7 core components of a user research plan:
The background of the research project detailing why we are conducting this study
This can also include the internal stakeholders involved
The objectives and goals of the research, what the teams want to learn from the research, or what they would like the outcome to be. We should be able to answer all of the stated objectives by the end of the research project.
A breakdown of the participants we are recruiting and how we are recruiting them
How we are conducting the research, which includes the chosen research method
An interview guide as a cheat sheet of instructions/questions to follow during the research session
This includes components within itself, such as the introduction, interview questions and conclusion
The background section is pretty straightforward. It consists of a few sentences on what the research is about and why it is happening, which orients people to needs and expectations. The background also includes a problem statement (the central question you’re trying to answer with your generative research findings).
We want to understand the reasons behind why certain customers are reordering at a higher frequency, as well as the barriers encountered by customers that prevent them from reordering on the platform (problem statement).
We will be using generative research techniques to explore the journey users take, both inside and outside of our platform, when they decide to order takeaway, in order to better understand the challenges and needs they face in these circumstances.
Objectives are one of the hardest parts of the research plan to write. They’re the specific ideas you want to learn more about during the research and the questions you want to be answered. Essentially, the objectives drive the entire project. So, how do you write them effectively?
First, start with the central problem statement: to understand the reasons behind why certain customers are reordering at a higher frequency, as well as the barriers encountered by customers that prevent them from reordering on the platform.
Our research objectives should address what we want to learn and how we are going to study the problem statement.
Understand how and why users are currently reordering food on our website/app
Discover users’ motivations behind reordering, both inside and outside of the website/app
Uncover other websites/apps customers are using to order takeaway
Learn about any pain points users are encountering during their process, and what improvements they might make
(Read a more comprehensive guide to writing and framing your objectives here)
Now that we’ve defined our problem statements and objectives, it’s time to define the type of participants we’ll rely on to get the insights we need.
One of the most important elements of any project is talking to the right people. A few ways to approach this:
Bring in internal stakeholders that may have a good idea of what the target user will look like (such as marketing, sales, and customer support) and create hypotheses about who your users are.
Look at competitors similar to you, and recruit based on their audiences.
Make sure to write a great screener, which will get you the participants you need. Is there a particular behavior you are looking for (such as ordered takeout _#_ amount of times in the past three months)? Is it necessary they have used your product (or a competitor’s product).
Compared to the others, this step is fairly easy. In this section, talk briefly about the chosen methodology and the reasons behind why that particular method was chosen.
For this study, we’re using one-on-one generative research interviews. This method will enable us to dig deeper into understanding our customers, fostering a strong sense of empathy and enabling us to answer our objectives.
(We have a more complete breakdown of how to craft the perfect interview guide here).
If you’ll be talking to your users in real-time, an interview guide is a valuable cheat sheet. It reminds you of which questions will help you meet your objectives, and can keep your discussions on track.
For moderated research, my interview guides consist of the following sections:
The introduction details what you will say to the participant before the session begins, and serves as a nice preview of all the different points you’ll be discussing. It’s especially helpful if you are nervous about going into a session.
Hi there, I’m Nikki, a user researcher at a takeaway delivery company. Thank you so much for talking with me today; I am really excited to have a conversation with you! During this session, we are looking to better understand what makes you order food from our service. Imagine we are filming a small documentary on you, and are really trying to understand all your thoughts. There are no right or wrong answers, so please just talk freely, and I promise we will find it fascinating. This session should take about 60 minutes. If you feel uncomfortable at any time or need to stop/take a break, just let me know. Everything you say here today will be completely confidential. Would it be okay if we recorded today’s session for internal notetaking purposes? Do you have any questions for me? Let’s get started!
This portion of the interview guide is the trickiest to write. In this section, we’re writing down some of the open-ended questions we want to ask users during the session. For most types of qual research, you won’t always have a long list of detailed questions, since it’s more of a conversation than an interview. But readying a few open-ended questions you can then follow up on can serve as useful prep.
I always outline my interview guide questions with the TEDW approach. TEDW stands for the following structures:
“Walk me through….”
Another cool trick for question generation is to use your research objectives. Your questions should be able to give you insights that answer your objectives. So when you ask a participant a question, it is ultimately answering one of the objectives. Turn each objective into 3–5 questions.
The wrap-up is a reminder of all the items to mention during the end of an interview. Generally, you cover information such as compensation, asking if they would be interested in future research, and assuring them that you’re thankful for their time.
Those are all the questions I have for you today. I really appreciate you taking the time. Your feedback was extremely helpful, and I am excited to share it with the team to see how we can improve. Since your feedback was so useful, would you be willing to participate in another research session in the future? You have my direct email, so if you have any problems with the compensation or any questions or feedback in the future, please feel free to email me at any time. Do you have any other questions for me? Again, thank you so much for your time, and I hope you enjoy the rest of your day!
I place an approximate timeline in my research plans, so people know what to expect for the start and end dates. Some researchers stay away from this timeline, as it can solidify a deadline that may prove more difficult to meet than expected. I always stress that it is a basic approximation.
Research start date: Monday, August 5th
Research plan creation and review: Wednesday, August 7th
In this section, I make sure it’s easy for everyone to find links to the research sessions, any synthesis documents, notes, the presentation, any development/design tickets, prototypes or concepts and any follow-up information which would give context to the study.
Immerse yourself in the problem space. Understand what you are going to research by building domain knowledge of the subject matter and functional knowledge of the user interface. Domain knowledge is understanding the product and the vision/goals of the product. Functional knowledge includes a deep understanding of the concepts, interactions, and vocabulary of a product. You don’t have to become an expert on either, but you should have a baseline understanding of both.
Get access to the “right people.” Make sure you know whom you want as participants and that these people are relevant in helping us get insights into your questions. You want to avoid situations where participants answer, “I’ll have to find that out for you later,” “I would need to run a report,” “I would need to ask someone else,” or “I’ve never done/encountered that before.”
Set the stage. The setting in which you conduct your research session is important and should make sense for the study, such as in an office space, a co-working space or someone’s office/home for an observational study. Make sure the area is quiet and sectioned away from other meetings or conversations.
Determine the sequence and flow. There should be a natural flow during your interview sessions, and they should feel much more like conversations than strict interviews. Ensure your questions flow naturally and you aren’t jumping too much between topics with no transition.
Practice the script. Once you have drafted the entire script, read it out loud several times and practice it on others. Check for any awkward language or jargon, gauge the general length of the interview, and make sure you aren’t tripping up over any difficult words.
During a session
When I talk about actually running a generative research session, I always reemphasize the point of generative research: we are here to deeply understand someone’s perspective, stories, and problems. We are there to empathize with them, not to get through a checklist of questions.
During an interview
Be in the moment. It’s easy for your mind to wander during a research interview. Whether you are concerned about the interview going well, thinking about lunch, or stressed about a disagreement you had earlier in the day, quiet your mind before a session.
Build rapport. Your behavior during the first few moments of an interview, and throughout the entire interview, are crucial to how the session will progress. Be confident and respectful to the participant—smiling throughout the entire session, maintaining eye contact, reading the participant's body language, mirroring the participant's communication style, and being as genuine as possible.
Be silent. A large part of a job as a researcher is reacting with silence. The best thing you can do to get a person talking is to create a space for them to continuously talk.
Control your body language. Over 55% of communication is completely non-verbal, so it is essential for us to be aware of our body language.
Actively listen. When we actively listen, we are completely focused on what someone is saying, at that moment. Show empathy towards the person by engaging with what they are talking about, and trying to better understand them.
As mentioned before, the TEDW technique is a great way to frame questions, but how do we dig deeper and make sure we are getting the most valuable, and deep, information? For this, I use the 5-whys technique and ACV laddering.
The 5-whys: This technique is relatively self-explanatory: ask “why” about 5 times in order to get to the real nugget of information. Here, “five” is more of a guideline than a hard role. The point is to continue asking “why” until you really believe there’s nothing more a participant can explain.
ACV laddering details three different methods of reaching a person’s core values and beliefs:
Attributes (A) — The characteristics a person assigns to a product or a system
Consequences (C)— Each attribute has a consequence, or gives the user a certain benefit and feeling associated with the product
Core values (V) — Each consequence is linked to a value or belief system of that person, which is the unconscious (and hard to measure) driver of their behaviors
When we start to understand the different areas of the ACV ladder, we can identify where a participant is when they are responding, and try to urge them forward towards core values. For example:
Q: Why do you like wine coolers? (Assuming the participant has indicated they do like them)
A: They are less alcoholic than other options (attribute)
Q: Interesting. Why do you like them because they are less alcoholic?
A: I can drink more of them than other types of alcohol, which is important (attribute)
Q: Why is that important to you?
A: I don’t get as drunk and tired (consequence)
Q: And how does not getting as drunk and tired impact you?
A: Well, I don’t want to look like a drunk…it is important for me to appear sophisticated (consequence)
A: It is important for me to get the respect of others, and it is hard to do that when you’re drunk (core value)
With ACV laddering in mind, it is easier to pick up on attributes and consequences to, ultimately, get to someone’s core value behind their actions or thoughts. This really helps you structure the flow of a session and dig deeper into a person’s motivations and core drivers behind their actions. By keeping this technique in mind, you can get some really concrete insights that help you understand not only how a participant is acting, but the true reasons behind why.
After a session
Even after the interview is over, you can continue to learn and improve. The best way to do this is to relisten to your interview. Even better: have others listen to it and give you detailed feedback on how they think you can improve.
One way I always judge my interviews is by using a method adapted by Steiner Kvale’s interview assessment. I rate myself on the following criteria:
To what extent are the participant’s answers spontaneous, rich, specific and relevant?
Are the interviewer’s questions shorter and the participant’s answers longer?
Does the interviewer follow up and clarify the meanings of the participant’s answers, particularly emotions?
Did the interviewer interpret the meaning of the participant’s answers throughout the interview without asking?
Did the interviewer attempt to verify his/her assumptions of the participant’s answers?
Was the interview self-communicating through natural, story-like answers?
Not that we have finally run the generative research sessions we wanted to, it is time to pull all of this information together and spot different trends and patterns in the data. We do this by synthesizing the data and what that really means is bringing together all of the data we collected and the notes we took.
After each research session, I always listen to the entire research interview all over again and transcribe the interview word-for-word. Although this takes hours (usually 2.5 hours for a 1-hour interview), it reminds me of what was covered in the interview and of what the participants brought up. I then label the important lines with tags, such as pain points, keywords for what users were talking about, motivations, or suggestions. Then, when I look across the notes, I can compare common threads and patterns.
Write research summaries
For each session, I write a brief research summary. This practice helps solidify what was discussed, and better enables me to connect the dots between participants. Research summaries also highlight the most important trends or themes from a session, which gives my different teams an accessible way to digest research. Then later, they can help me come up with great recommendations and ideas.
Look for patterns with affinity diagrams
This is one of the first things I do after I complete 6-7 research sessions. It’s the most classic way to synthesize research.
A brief outline of the process:
I gather the notes I’ve taken for each participant and write down the different pain points, motivations, goals, needs, and tasks on post-its.
Once I’ve done this for each participant, I take all my post-it notes and put them in relevant groups (all the pain points from all the participants go in one group, all the motivations from participants go in another, etc.).
Once I’ve laid all that out, I cluster the similar post-its under each group. Oftentimes, after six research sessions, I can easily find patterns in different pain points, which means multiple people are having the same problems.
A common misconception researchers face is that we’re supposed to go off and do all of this synthesizing alone. That is the exact opposite of how it should be; synthesis is a group effort. If you are feeling stuck, you can reach out to others for their ideas and perspectives, or even run some brainstorming sessions.
“How might we” statement sessions
I often gather a group of colleagues who are more familiar with the research we have done. Together, we review the research sessions and recordings and then compile a list of “how might we” statements. What I love about these is they turn larger information into actionable nuggets of insights that inspire creativity. With these statements, I get reenergized from the different perspectives on how people are thinking about the research. I then run brainstorming sessions or create prototypes.
Ideation sessions can happen during ‘how might we’ sessions, or completely separately. I take my team and propose larger problems users are having with our product. Then, we each spend ten minutes coming up with ideas on how we might solve a problem like that. The trick is, you can’t think about technical feasibility, and you are not meant to think about your product as it is. Instead, you are encouraged to start from scratch, as if there isn’t a current design or flow. This can lead to great ideas and offer fresh perspectives on the research from your team.
After synthesis, we have to present our research. One of the worst things you can do after a generative research project wrap-up is to share a report via email and then let it collect dust in a digital folder somewhere.
Instead, I recommend presenting your research to your colleagues and allowing them to ask any questions. Catering your research reports to your audience is the number one way to get people to actually pay attention to your research synthesis. Not everyone finds research as exciting as you do. Leave them with just enough to understand, and then guide them towards resources that enable them to learn more, on their own time. It doesn’t matter how good the findings are if you aren’t able to communicate them effectively with your team.
Now, whenever I create a research presentation, I use the following formula:
Informative + actionable + fun = solid user research presentation
(For a more comprehensive look on presentations that stick with stakeholders, head here)
Designing your presentation so it’s informative:
1. Know your audience and speak to their interests
When I first presented my research to high-level stakeholders, I wasn’t reading the room. In fact, I ignored the room and babbled through the only thing I knew: the content on those slides.
Now, whenever I am relaying research insights, I know exactly whom I am talking to, and what their high-priority interests are. For upper-management, I discuss how my research findings could impact revenue, conversion rate, NPS, and customer retention. For marketing, I talk about potential content, language, and branding. For the product, I give exact examples with reasonable action items.
2. Keep it short (but make more in-depth information easily accessible)
You don’t want to fight for attention during a presentation. I always try to present all the research findings within 20-30 minutes and save any extra time for questions from the audience. I stick to sharing the most high-level information and then enable anyone who is interested in looking deeper into the research.
3. Have a high-level overview slide
I was once told by an executive stakeholder that his favorite presentations included a high-level overview—almost equivalent to a TL;DR. If he was able to see and understand the content in a glance, he would find it valuable to sit through an entire presentation of it.
4. Let your visuals lead
I don’t have much text on any of my slides (except for the high-level overview and next steps slides), because my slides are primarily filled with videos and photos. There is nothing, I repeat nothing, more important than showing rather than telling.
Translating your findings so they’re actionable:
1. Give concrete recommendations
An absolute must in any user research presentation is including recommendations. These aren’t simply high-level recommendations stating changes that should be made. I display recommendations in a very straightforward way. For every “issue” or “problem,” I provide a pointed recommendation, even if it is common sense.
2. Include detailed next steps In every presentation, I add “next steps” in the last slide. They tend to be fairly detailed. I point out when I will talk to the teams about the research, how the research will be incorporated, and any upcoming research projects.
3. Demonstrate the “big picture” value
Executives and stakeholders want to see your impact. So provide them with information about how research is being incorporated into the backlog, how it’s impacted the roadmap, and ways it’s supporting company OKRs.
Making sharing your insights fun:
1. Make research enjoyable. It doesn’t always have to be a report There are many other ways to share research outside of a simple report. Many stakeholders love these more creative methods. Sometimes I will put together UX comics, storyboards, or host a usability testing “movie night.” It may be harder to get stakeholder schedules aligned for something like this—but you can also open it up to the rest of the company. Two birds, one research exhibit.
2. Include funny messages or gifs I’m all for being professional, but I also think it is of high importance to bring smiles and jokes into the workplace. I often scatter some funny memes or gifs related to the research findings. This gets a bit of a laugh, can help break up any tension, and can refocus attention.
Generative research is not an easy skill to develop, but it is one of the most important abilities to have as a user researcher. I clearly can’t stress this enough, but the best way to learn this skill is to practice it over and over again. There are times when I am beginning a new generative research project where I still get nervous before the first few sessions before I have found my groove. It takes time and patience to cultivate these skills, but they are beyond worth it.