How should I structure and write a User Research case study?

A sample UX Research case study.

Source

By far, the most frequent question I get asked is, “how should I write a user research case study?” The second most frequent question I get asked is, “what should I include in my case study?”

Case studies are difficult and stressful. I have spent hours sweating and crying while putting together a case study. To this day, despite my years of experience and confidence in the field, I still hate the process.

However, I want to provide an example of how I structure and write a case study in the hopes that it will make your journey better.

What is a user research case study?

A user research case study is your way to demonstrate the value you provide to an organization. It is a story about a project you have accomplished and gives your audience a step-by-step understanding of how you approached it.

Case studies are at the heart of an interview and an integral piece to making it through to the next step during the interview process. If you tell a compelling and clear story of projects, you are more likely to get more interviews and further the interview process. Additionally, you will feel more confident during the interview process and with any next steps.

I promise you it is worth the time and effort to invest in your case studies.

What should be in a user research case study?

When you write a user research case study, there are areas you should include. However, always use your judgment. If a particular project did not cover one of these topics, you don’t have to make something up or force information into it. Use these topics as guidelines.

As a hiring manager, I always look for the following in user research case studies:

1. Context
2. Your role
3. Timeline
4. Research statement and goals
5. Research methodology
6. Recruitment criteria and process
7. Sample questions asked or usability tasks
8. Analysis and synthesis process
9. Outputs/deliverables
10. Impact
11. Next steps and recommendations
12. Reflections

Optional:

1. Your/team biases and assumptions

Check out my user research case study template!

The Example

This example is based on a fictional problem and company. As much as I would like to use a real-life example, it is tough to do this. I did my best to simulate a real project and fill this out as if I was creating a real case study.

In this example, I was previously working at a food delivery company (think: Seamless, Liefrando, Deliveroo). The fictional name of this company is Tasty Delivery. I was a user researcher at Tasty Delivered.

I don’t include any photos since this is a fake company and project, but I highly recommend including this information whenever possible.

Context and background

Hi, I’m Nikki! I worked at Tasty Delivery, which is a food delivery app. The app's goal is to connect people with all the restaurants, grocery stores, convenience stores, bakeries, and coffee shops in their area. All they need to do is order, and tastiness will be delivered straight to their door. The company was founded in 2015, and we are available on the East Coast of the United States and in the UK, Denmark, and Germany. As a researcher, I work on the company's B2C side, but there is also a relevant B2B aspect.

And just some context outside of my work. In 2015, I started to learn how to cook, and now I can make complex vegan meals! In the years, I also picked up other hobbies, like table tennis, hiking, and listening to podcasts.

Today, I will talk to you about a project we did to better understand the personas on our platform and their top usability issues.

My role

I am a user researcher at Tasty Delivery, and during this project, I was the only qualitative user researcher. I lead all of the interviews, and the end-to-end process, such as recruitment, synthesis, and workshops.

I was fortunate enough to work with an amazing team that included two designers, a product manager, and a few developers. They were present in almost all of the research sessions (notetakers!) and the synthesis and related workshops. Although I did some synthesis on my own, they helped me with putting the main themes together. At the end of the project, we had some relevant findings to the marketing team, so I worked with them on workshops as well.

The project had come from a road mapping session the product team had done. I was part of that session, so I had a lot of background knowledge. However, I had them fill out a research request template. This helped me prioritize the project against other requests coming in, as it was a company priority.

Timeline

Overall, the project took a total of one and a half months. Of course, we are still iterating on the personas, but the deliverables were created and shared within that timeframe.

• Discussing the project: 1 week
• Recruitment: 2 weeks
• Conducting research: 2.5 weeks
• Survey: 1 week
• Analysis: 1.5 weeks
• Report: 1 week

Research statement and goals

We wanted to understand better how users think about ordering food online and how they interact with our product to improve our app's experience.

What were the goals of the research project?

1. Discover user’s mental models on how and why they order food online (agnostic of Tasty Delivery)
2. Uncover the different products people are using to order food online, and their experience with these products
3. Evaluate how people are using Tasty Delivery to surface the top pain points

Research methodology

For this project, we decided on two different methods to fit the timeline:

• One-on-one generative interviews
• A follow-up survey

We decided on “walk the store” style interviews for the one-on-one generative interviews, which meant we had a 90-minute conversation. The first thirty minutes focused on their day-to-day and how ordering food online fits into their days. We also discussed competitors and other products. The latter 60 minutes was spent doing a complete walkthrough of the product, based on how they generally use it. This portion of the interview was a mix of interviewing and contextual inquiry. I observed them using the app, as they thought aloud, and then asked clarifying questions whenever necessary. I chose this method because it allowed us to understand people’s mental models of online food delivery and see how people interacted with our app. With this interaction, I could pinpoint the top pain points for the teams to focus on. Overall, we held 17 of these interviews.

We then did a follow-up survey in which we quantified the findings. Since the team would use this information for a future roadmap, I wanted to make sure the findings were as reliable and valid as possible. In this case, we used the insights we found of the top pain points and surveyed over 1,000 users on each pain point's importance and current satisfaction. We then calculated the opportunity gap (the level of importance of the pain point minus the current satisfaction level).

The stakeholders (product managers, designers, and developers) joined most of the research sessions as observers and as notetakers.

Recruitment criteria and process

For this study, we were looking for a mixture of users and non-users. We did this because we wanted to make sure we got a fresh perspective of the app and see how first-time users respond to our flow and experience. This helped us ensure we weren’t just looking at power users that were “used to” our flows.

Some of our recruitment criteria were:

• Have ordered food online at least once in the past month
• Has used an online food delivery app
• Age: 25–45
• Geography: the US only
• Language: English

We used the following tools for recruitment:

• HotJar pop-up on the app and website
• Emailing newsletter subscribers

We used a 20% discount voucher on their next order as an incentive for this study to recruit as quickly as possible.

Sample questions or usability tasks

Here is a link to the moderation guide.

During the interview sessions, I used very open-ended questions. To ensure this was the case, I used the TEDW approach to frame most of my questions. This led to an extremely open conversation, which allowed us to understand mental models and pain points without leading them.

When it came to the walkthrough portion of the interview, we had users walk us through the last order they made (whether it was on our platform) and then prompted the participants to talk through each step in detail.

Analysis and synthesis process

After each session, I hold a 30-minute debrief session with the team to discuss key takeaways, pain points, and surprises. This helps the team reflect on the session and starts building us up to the larger synthesis.

I synthesize research sessions by listening to each session 24 hours afterward and transcribing the session directly into an excel spreadsheet. I then code the data with common tags (such as pain points, needs, goals, tools). I also use this opportunity to highlight relevant quotes.

After eight interviews (halfway through), I held a mini synthesis session. Every stakeholder took three interviews, listened to them, and tagged the data. In the session, we did affinity mapping of the most common trends. Since we were hyper-focused on pain points for this study, we looked into those and goals, needs, and other products participants were using. The reason I did this mini-synthesis is that I know 17 sessions can feel overwhelming. This split up the sessions and made it more digestible.

I then held another session at the end of the project, where we tackled the remaining interviews. We then layered the mapping from the previous session and found the overarching trends. We discussed the top themes using the RICE method (reach, impact, confidence, effort) and did some dot voting to find the top three action items.

I also held a few workshops with marketing once we found some content insights.

Outputs and deliverables

After synthesizing each session, I put together a report for the session. I called this a research snapshot as it gives a high-level overview of what happened in that particular session. It is beneficial for teams to have this information at-a-glance because they ingest it more easily and take action.

After the mini-synthesis, I put together a report. In this report, I summarized the key takeaways and pain points we were finding. In this report, I included videos and links to more information. I did this as well after the final synthesis.

Other deliverables included two new personas and the first iteration of a customer journey map (which needs to be validated later). We chose personas because, before this project, the teams had little understanding of who was using our product and why. These personas enabled them to anchor decision-making, and what should be prioritized next.

In addition to the deliverables, we presented the results to several teams, including marketing, sales, and the C-level. These presentations were taken very well, and the teams felt empowered to use the insights across the organization.

Impact

This research helped the entire organization understand how customers move across our product and the most painful experiences they encounter. Teams could better work together on the holistic experience, making it more seamless for our users. During the quarterly planning, the insights and the personas were used in the prioritization and planning process — the pain points were highlighted and are being tackled through ideation, prototyping, and more research.

At a larger level, the marketing team was able to iterate on their content strategy, including how they reached out to customers, which increased our overall conversion rate and the number of orders per newsletter subscriber.

We have been working on improving the pain points, which has led to an increase in revenue per user.

Finally, our culture shifted in that the organization moved to a more user-centric mindset and is now more excited to do research.

Next steps and recommendations

Many pain points came out of the research. We are now following-up on these pain points with ideation and usability testing:

• The checkout flow was long and difficult to get through
• It was hard for users to know where they were (grocery store, restaurant, coffee shop)
• There was little reason for users to return and stay loyal to us

We shipped an MVP of a loyalty program, which has an increased retention rate by 5%. We also iterated on the checkout flow, making it more concise and straightforward. This increased click-thru rate by 15%

We will continue to iterate on the personas as we learn more. We also will validate the customer journey map with more interviews.

Reflections

What went well:

• People actually used the research!
• The methodology allowed us to reach all of our goals
• Stakeholders participated in the research
• The mindset of the organization shifted towards more user-centricity

Challenges:

• Recruitment took a very long time -> I will target better next time on more focused recruitment criteria
• It took a while to get buy-in ->I will educate more on the value of research
• The scope of the project changed a lot -> I will send an intake document sooner to have everything documented
• There were some last-minute participant no shows, so we had to scramble for back-ups -> I will find a way to include back-ups in recruitment

(Optional) Your/teams assumptions and biases

Biases/assumptions:

• People order food because they are lazy
• People want to order food from many different places (ex: grocery stores, coffee shops, restaurants, bakeries)
• People don’t know what they want before they open the app (more browsing)

What we validated:

• People want the ability to order food from many places but tend to have a few favorites

What we disproved:

People don’t order food because they are lazy; they order because:

• Something went wrong with dinner (ex: forgot to pick up something, groceries went off)
• Stress (ex: too much to do)
• Fun (ex: a relaxing night in)
• People have an idea of what they want before even opening the app

I truly hope this walk-through of my approach has helped you and can guide you through your next case study! Don’t forget to check out my template!

—

Interested in all things user research? Sign up for my newsletter and join the slack community! And check out User Research Academy for freebies, courses, and more!

The UX Collective donates US$1 for each article published in our platform. This story contributed to Bay Area Black Designers: a professional development community for Black people who are digital designers and researchers in the San Francisco Bay Area. By joining together in community, members share inspiration, connection, peer mentorship, professional development, resources, feedback, support, and resilience. Silence against systemic racism is not an option. Build the design community you believe in.

An example of a generative research interview

Source

I always get asked about how I conduct research interviews, and each time I do my best to explain my techniques. I mention research plans, TEDW techniques, not asking about the future, and being careful not to ask leading questions.

However, I constantly struggle with how to describe my research interviews. Since I rarely follow a script for generative research interviews, it is hard for me to write down a list of questions because I generally base what I say on the participant’s response. I also tend to go slightly off-script during usability testing if I find an interesting thread to follow that might bring some solid insights.

After years of practicing, I feel most at home during research interviews. Yes, I definitely can still get nervous before a research interview, but generally, they are the highlight of my week. I think of research interviews as a window into someone’s life, and I am lucky enough to get a peek. For me, interviews are the coolest part of being a user researcher, which is why I get so frustrated not being able to answer one of my most received questions.

So, I decided to try something new that might help. Instead of writing out the basic structure of my user research sessions, I thought it might be more helpful to conduct an example research session and write out the exact script.

The idea

My fiance, a product manager, was kind enough to volunteer to be my research subject. We talk in-depth about quite a few topics, but we decided to talk about one of his passions: boardgames. In this example, I sit down with him to better understand how he decides to purchase a particular board game.

The interview

I only transcribed the first thirty minutes (out of about an hour), but it should still give a good idea. Want to listen as you read? Check out the sample interview here.

Introduction

N: My name is Nikki. I am working on a project right now to better understand how people think about purchasing board games and how they actually go about purchasing them. So I mean, user experience researcher at this company, and I wanted to understand your thoughts and your thought process on how you go about purchasing board games. So this session will only be about 30 minutes. And there are no right or wrong answers. So I want you to answer honestly. You’re not going to hurt anybody’s feelings with your feedback. Since we’re going to use this, your feedback and opinions improve our product and purpose. Do you have any questions before we begin, though?

C: That will make sense?

N: Okay, cool. Do you mind if I record this session before we start this?

C: Absolutely fine.

Diving in

N: Okay, cool. Awesome. So as I mentioned, I want to understand a little bit better how you think about purchasing board games. Um, so just to kick it off, could us think back to the last time you purchased a board game on your own, not a gift or anything, and kind of walk me through from when you first realized that you wanted or needed the board game all the way through actually purchasing it?

C: Yeah, sure. Um, so I really like board games. I’m not trying to say need as many as I have. But for me, it’s been like a hobbit in German. And I like to have kind of a diverse board game. Depending on who we play with, there are a few things that so I think maybe contextualize it a little bit. The last board game was called charter stone. I saw actually I was in a board game store said we had brunch with a friend, and we were walking past a board game store on the way back. And I dropped in. It was actually the box that first attracted me to it. I thought it was a really well-designed box. And aside to read it, and it was a legacy type board game. To me, it’s one of those that changes every time you play it. So what you do in one game will affect the next day. So normally, for I buy a board game, I actually also put alliances quite a popular website for games called BoardGameGeek, which is like the online home of board games. So on there, you’ll have forums discussing them, reviews for each game. And reviews will take things like complexity into account, learn the number of players, and the mechanics because there are many different mechanics in board games. So if you think of it a bit like a video game, you can, you know, you can build a base, or you can do a first-person shooter or car racing game. Like board games, you have different mechanics, and people prefer different mechanics on what they’re doing. So while I was in the store, I quickly looked it up. I saw it had a really good rating there. This one was made a little bit more of an impulse buy. And so I bought that one on the spot because there were the mechanics are involved. And it was a theme that I liked. The artwork was beautiful. And then at least initial reviews that I read on Board Game Geek really positive, so I bought it.

N: Wonderful. Awesome. So that was a lot of information. And so what I might do is I might actually go back and talk to you a little bit about what you what you just talked about. But when you say that you bought it, can you just describe that portion a little more. You were in a store?

C: I’d looked at a couple of ones. I picked it up and did the kind of browsing things on my phone. And just to see what Board Game Geek was saying what some of the big reviewers were saying about it. And it was generally positive. And so I picked up I wandered around the store for a little bit longer. It was more a case of what else might I buy? I said, there’s a board game store. There was nothing else typical that I really wanted that day or caught my eye. So I went and bought it was pretty straightforward.

N: Well, awesome. Going back way to the beginning of when you mentioned that you dropped into the board game store and saw it was there anything that kind of triggered you dropping into that board game store in particular.

C: It’s my local board game store. So so it’s the one that’s nearest to where I live. I bought a few games there before they’ve always really friendly, really nice, and there’s a huge selection, which is good. And we finished brunch, and it was literally two streets away from where we were eating, so it’s close by that as I might as well. And Saturday tends to be the day that I indulge in my hobbies. I have a couple of hobbies, so if I’m near the local store for that hobby, I maybe go in and just kind of browse and see what’s available. So that was it.

N: Okay, so it was location-based like you were close to it. So it was easy to stop by. And so you mentioned that the board game like the actual box caught your eye. And you said that it was like well designed, can you talk a little bit more about what you mean by well designed.

C: So this one’s actually quite a fun example. Because there’s almost nothing on the box, if you think about a box, you’d get with Apple, where you have an iPhone on the front, and then no information. It was kind of like that. The box is very clean, very white and actually stood out against a lot of the board games in the store, which is why I noticed it the first time. I then went to the back. There’s a brief summary of the mechanics, which I said were the kind of mechanics I liked. So kind of building strategy and building games, a nice preference of style, there are the little artworks, but there wasn’t that one was very clean and very crisp, and that I was pretty impressed by that. So I like legacy games. I like village building games. And obviously, at that point, it wasn’t enough for me to purchase it. I was really interested. And that’s when I went to Board Game Geek. And I got some information.

N: That’s really interesting. And so you said that that box was different because of maybe the clean and the lack of information on the box? Could you give an example maybe of what the board games normally have on the box?

C: Yeah, it depends on the box. You’d normally get a lot of information on the side of them. So you’ll normally have, it kind of depends. So on the front, you normally have obviously the title and some illustrations on the back or the side, you will tend to get kind of function information to how many players rough time how long it takes to play. And some of the mechanics that are involved with the dice base game is a card game is it, those kinds of things. So the mechanics I mentioned before. And then on the back, normally, you get a picture or an overlay of what’s included in the box, if I think about my favorite game, The Game of Thrones board game, or Imperial settlers. If you look on the back of that box, it gives you an overview of what it might look like when you’ve set. This box doesn’t do that because it’s more of a story mode. Because I said it’s a legacy game. You don’t know what cards are there. That’s actually one of the things when you open the box is a big thing says do not read the cards because you’re meant to play through the story mode. So your game evolves, depending on your decision. So you’re not allowed to say no, and it looks like and also by printing on the back of the box. It’s not representative because it’s going to look different for every player based on their decisions. So that one, I think, is very different from most of the games that I play. And I think after the election did a good way of giving a hint of mystery about what’s involved.

N: That’s super interesting. So you mentioned that, since there wasn’t a lot of information, you went on to Board Game Geek to go and kind of look up the reviews and the different mechanics and more information. But before we get into that, and how you went through that process with charter stone, do you also go on to Board Game Geek when you get all that information on the box?

C: Yes. Oh, Board Game Geek is a pretty good community. It’s quite a diverse community. It’s like the authoritative source of like board games online. Like that’s the place you go to check it. For example, if you’re playing a game and you’re not sure about a rule, or you feel that it’s two rules that are conflicting, almost everyone I know will go to the board game geek website before they go to the official, the official website because normally it’s easy to find other people obviously because they the official companies can test the game like 100,000 times. So people do it. And also, if someone’s got an official answer from a company, they will consolidate there. So Board Game Geek is pretty authoritative. It’s also very detailed in what you’re looking for. And the website’s not the prettiest, I’ll be honest, but it’s very functional. You find what you need to find, which is great. To go back to your question, yeah, I will use Board Game Geek pretty much every time. I will also use it sometimes if I’m at home and browsing online for a board game. I will use maybe five or six big reviewers that I will also see what they’ve said about again.

N: Cool. Awesome. Thank you. That’s really helpful. Could you talk about a time when you have seen a game online or in a store and purchased it without going to board game geek?

C: Yes, but only when I’ve played the game before. For example, if I played with a friend so Game of Thrones, the board game is actually my current favorite board game and has been for several years that I bought off Amazon. Immediately I finished I went to I got introduced to it by one of my other friends who went down we spent the day playing. I laughed. I was like, I’m buying this game because I played it. And I had the experience. And I use I guess I use this on Board Game Geek as a proxy, I proxy other people’s experiences to be like, would this apply to me? And if I played it with them, and I like it, I will buy it without checking Board Game Geek.

N: Okay. Interesting. So it seems that if you’ve had the experience of playing the game, you feel more comfortable purchasing it without visiting board game geek.

C: Yeah, because at that point in my experience, I know I like it. As I said, I think with Board Game Geek, I use it when it’s new for me. You can read the packaging, maybe less overcharged soon, because the packaging, but generally, you can get an overview of how the game works, doesn’t say how the game plays, which is very, which is a very different thing. And there’s a lot of board games out there. They’re not all fantastic. And there are multiple reasons that that will be the case. So I tend to trust the community of gamers about what they like what they do, like, there may be a chance I’m missing out on an awesome game that I would think was fantastic because the community doesn’t like it. But generally, I found that the games that I buy, the process of buying games generally seems to work for me.

N: Okay. And that’s the process of looking and looking it up on Board Game Geek.

C: Yeah, it’s about more validating. So I’ll come across it in bed. So a friend will mention a game, or I’ll see online I see in a bookstore for game geeks, which is my way of getting more information. What is the experience of playing this? Occasionally, I get games recommended to friends. And if a friend has recommended the game to me, I’ll check it out. But I probably still will check Board Game Geek if I haven’t played it myself. Okay. Okay. Even if it is a recommendation from a friend, you are more likely to. Yeah, I think it depends. I’ve got many friends who play board games, and they’ve all got different preferences. I mean, there’s a couple of friends who like or enjoy almost the same games. So if they recommended them, I probably would take it off the bat as a smart purchase.

N: So looking at board game geek since it’s interesting to see what other people say. Cool. Yeah. And you’ve mentioned a few times that you’re looking for, like the experience. Either like the experience that you had yourself personally or on board game geek, you’re kind of looking for what the experience might be. Can you talk a little more about how you figure out what that experience is, especially on board game geek?

C: Yeah, so Board Game Geek actually has a good way of quantifying this. So they have two main numbers. One is complexity. And one is geek rating. Complexity is given a rating between zero and five by how complex the game is. And then geek rating, which is how good it is how high it sits in the ranking. For example, I know my two of my favorite games, Game of Thrones and imperial settlers, I know where they sit on that rank. So I benchmark all the games against those. Of course, it depends on what I’m buying them for. If it’s like a party game, so the kind of game you played with people, then that’s different. So there’s a common one that people would know on things like Cards Against Humanity would be considered a party game, or resistance, which is ones where you have to pretend to be a secret agent, those kinds of things. For those of us who want an easier and a lower complex rating, because you the idea is that you find a group of people probably haven’t played this before, and you sit down and get started playing. But something like the Game of Thrones has a much higher complexity rating. And that’s a bit more for kind of people who like hardcore games. You will sit for five or six hours, probably more. As long as the corresponding geek rating score is high on it as well. You also get an overview of the mechanics. I don’t really like dice-based games. I don’t like the chance. I prefer strategy games where I can plan. Yeah, roll the dice. That’s when I’m not really into that. For example, those put me off because I’m not in control. I wouldn’t think I played a really good game instead of I got really lucky, which seems which is not as much my interest.

N: I don’t know if you have the answer to this question, but those dice games, do they vary in complexity as well, or could they potentially vary in complexity as well?

C: Good question. I don’t play as many dice games. So I don’t think it was well informed. It depends on the game. If the dice mechanic is one part of the mechanic in your game, you can still have a very high complexity rating. It’s a game where you just roll the dice, and then yet your outcome is probably lower. Monopoly is considered a reasonably straightforward game; everyone’s played Monopoly. But it’s pretty straightforward, right? You roll the dice; you move that far around. That’s a sensitive premise. And there’s a lot of luck involved in that, where you land. I don’t enjoy that as much. There’s a Battlestar Galactica board game made by the same company that makes Game of Thrones board game that has a dice mechanic in it. But many other things are going on at the same time. It just introduces the random element of space battle actually, or events happening. It’s a reasonably small mechanic, but it can be a bit annoying when it goes the wrong way. But it exists. And it’s a really good game. The dice mechanic is one that I’m not a huge fan of in it. But I understand in that situation, you have to have a degree of randomness. Otherwise the game, the game wouldn’t work. You don’t have that degree of randomness, for example, in the Game of Thrones board game. Right? You can be strategic and play it through and control as much as you can always control the other players around you.

N: Cool. All right. Awesome. Thank you. So kind of, kind of going back to, to that to the, to the two ratings, that they use the complexity and the geek rating. Yeah, the Geek score. Does that kind of roll up into like an overall rating? For the board game? Like, Is there like a zero to five stars? Zero to 10? stars?

C: Yeah, so the geek rating goes from zero to ten. I can’t remember where the ranking score comes from. It doesn’t come from a combination of complexity because you can have a game that is like 10, out of 10, and very complex, but people still love it. And it’s worth the complexity. So the complexity core doesn’t, as far as I know, factor into it. I think the geek score is the main driver where it sits in the ranking. For example, I know that Game of Thrones sits at like 7.6 on the geek score, and 3.65 and the complexity score. So I said that’s my benchmark. But for example, I know some games appear higher than Game of Thrones in the geek score, I just don’t enjoy playing. It’s a bit like there are games that rank high, but they just, they’re just not my style. Arkham Horror, for example, is one of them. It should be a similar game, but I don’t like it.

N: Okay, interesting. So that brings me actually into the next question that I have. Do you weigh both the complexity rating and the geek score? Pretty equally when you’re deciding? Or when you’re looking at something?

C: No, no the geek score for me is normally more important. The complexity rating is a lot of great material online, like, you know, how to play and guides for playing. So the complexity doesn’t really bother me. And the places only concerned for example, if you if I found a party game that was highly complex, I probably wouldn’t buy that because I don’t want to teach everyone. I would want to sit down and play and have fun. I don’t spend an hour explaining the rules to ten people. That’s not fun for anybody involved. It’s one of the reasons that Game of Thrones, for example, has such a large onboarding time. If you can spend maybe half an hour explaining the rules after they’ve watched a 20-minute tutorial video. And then after the first game, they’ll probably have how to play and the second game is gonna be loads of fun for them. Like Game of Thrones has a long onboarding time, but for me, it is well worth it. It’s a really great game. If you’re into the theme of hard to game like resistance or Exploding Kittens, you want to be able to explain it in 10 minutes, and the complexity rating is way lower than the complex games like Game of Thrones, Imperial settlers. Their complexity score is higher. There are lots of things going on with it. But it’s a great game for more hardcore gamers. I wouldn’t play that with my dad because my dad’s not as much into it. My friends who were in my board game group, they’re super into that kind of level. And then you’ve got some people that may be a bit high for, but there are other games that will sit in the middle.

N: Awesome. Cool. That’s, that’s perfect. If I’m understanding correctly, the Geek score is a little bit more important than the complexity rating.

C: Correct. And it depends on the situation.

N: Yeah. Okay. Cool. And so you mentioned that you benchmark generally against Imperial settlers and Game of Thrones. Can you talk about what you mean by like, benchmarking?

C: Yeah, it’s more just to anchor myself, so I know, hey, these are two games I really love. This is roughly what the community thinks of them in terms of complexity and in terms of rating. When I go and look at another game, either community saying these are better or worse. It’s just an anchor point really. I just take the games I know and try to compare them but it’s not always right. I said, there are games that rate higher, that I don’t enjoy as much. And some games really lower. So it’s more just a starting point.

N: Okay. Can you give me an example of a time where you’ve seen like a lower rating and have actually enjoyed or bought the game? Hmm, good question. It doesn’t have to be like an exact name.

C: Either way, I can tell you about a time that there was a game that I was ready to buy, but I didn’t enjoy it as much. Let’s see. Yeah, there’s one called Seven Wonders. That did not addict me or hook me as much as Game of Thrones or Imperial settlers. It’s a great game. I enjoy playing it, but never got into the rhythm as much as the other two. And I’m not totally sure why. Maybe I don’t know. Maybe I like the themes of Imperial settlers and Game of Thrones slightly more. But yeah, so that was a game that was rated higher by the board game community. But I know that I enjoy it less. It doesn’t entice me to play as much. I’m thinking hey, why don’t I play today? It’s never the game that jumps to mind like Imperial settlers or Game of Thrones. There is my default like, yeah, I really love these games.

N: Hmm. That’s really interesting that you say that. Because you’re saying it’s not that you necessarily enjoyed it less, but it doesn’t jump to your mind. And it doesn’t like entice you. And I know you said you just said like, I’m not exactly sure why. But I’m wondering like, is it because you’ve cited like mechanics and themes before as ways that you choose board games? And is it would it be something like that?

C: You get really bought into what you’re doing. So Game of Thrones is the one you play for five or six hours. You play a particular house, and I’ve read the books and TV shows. So if I’m and I lose a footman, I’m like, I know, I’ve lost the footman. Yeah. Similarly, with Imperial settlers, it’s a much shorter game than Game of Thrones. But you pay for your faction and you grow your empire. With Seven Wonders, great game really strategic, different ways of playing it. But the games are much shorter, I think like an hour tops, and there are the different factions and you get less bought into them? I think at least from last time I played, it’s not, you know, you don’t get as invested. Perhaps that’s what it is.

N: So when you say that you’re not as invested or as bought in? Can you explain a little bit more what you mean about being like invested in that game? Yeah, invest in the success of that faction that you’re playing, or that team that you’re playing? Or that civilization that you’re playing?

C: I guess there’s more. There’s more persistence on the End Game of Thrones in Imperial settlers, like your decisions feel like they take longer. I think when I think back, like, I deserve almost a story that goes with Imperial cycles in Game of Thrones, like you play through. And you can remember that time that someone did an amazing move. And like backstabbed in Game of Thrones, or Imperial status uses or there’s always certain like combinations of cards that your opponent played and the damage was really good. Like you learned a lot from it. Where Seven Wonders is very replayable it’s always a different game. But I very, I really remember any time I was like, Damn, that was awesome. Or I was like, Oh, right, that we were trying to get those from the other games. So maybe it’s that kind of book that I was thinking about.

N: Okay. Um, I don’t know if you can answer this. But if you could change something about seven wonders to make it more like the Game of Thrones games with the Imperial settlers games that you’re talking about? Like, what would you change?

C: I have not played in about a year. So it’s hard to remember. And sometimes I don’t want every game that I play to be as intense, for example. Seven Wonders, I think is, is a very strategic game. It removes a lot of the emotional elements that you may get in Game of Thrones. It’s so nice, I’m not sure I’ll change it. I do enjoy it. When I said I do enjoy it when I play it. It’s just a different type of enjoyment.

N: That’s interesting. Okay, so going back to the actual like decision that you made to buy it. So that seven wonders were rated higher?

C: Higher, yes.

N: And Game of Thrones?

C: Okay, I think complexity is definitely lower. Definitely low.

N: Um, okay, so it was higher on the geek rating. So that that kind of pushed, did that push you towards that?

C: Yeah. We bought this game because I was back in London with a few of my friends where we played a Game of Thrones in Paris, it was a lot together. And we considered buying another game. There was no point buying Imperial Settlers since we already had a copy of it. We went to the board game cafe that we used to go to in London, and we spoke to the guy there. And he actually said Seven Wonders is very popular. Consider it. We checked out on Board Game Geek and it is rated highly. So we took it home. And we spent most of the weekend playing. So I think it was a combination of things like we wanted something different than what we had before. Like I didn’t want to buy another copy of the game I already had. We wanted to do something different. And situationally, that’s when I had the opportunity to buy it. And I’ve seen someone mention it loads of times on Board Game Geek. So it’s a game that I was aware the board gaming community enjoyed. So it seemed like a good opportunity to buy it.

N: Okay, and so you bought that one. Yeah, took it home, and then you guys played it?

C: Yeah.

N: Okay, cool. Um, so do you think that there was anything that you could have found on Board Game Geek? Or like any sort of information that would have like helped you maybe not buy this game? Or you know, reconsider the purchase because it sounds like that geek rating weighed pretty heavily as well as like that recommendation.

C: It’s like it’s a very good game and I see why it’s rated highly in the community, but it’s not something I like. The whole idea of board games is that you find something that you like or enjoy anything that I would have made me change my mind not to buy that or buy something else. That’s a great question. i guess both

N: Let’s tackle not to buy that first. Or if it since it seems like this game doesn’t seem like a bad game to you if you want to think about something that was like more highly rated that actually, you didn’t end up liking, if you have an example of that maybe that would be easier to come up with.

C: Yeah, I honestly like all the games I have. I just like them for different reasons and in different situations. I can’t think of one honestly.

N: How about something similar to Seven Wonders had a higher rating, but you regret purchasing it if you have one of those.

C: There isn’t any game that I necessarily regret purchasing. I don’t play a number of games as often as I shouldn’t have maybe not got the full euro value out of the game that I’ve purchased. So Game of Thrones it’s not a cheap game to buy and with all the expansions probably over 100 euros, but I played over 100 games of it now. There are other games that I’ve played like five or six times that would have cost 50 euros. But the times I played them, I’ve enjoyed them. They’ve been, they’ve been a bit more situational.

N: Okay. So it doesn’t seem like there’s any sort of regret or like, I wish that I could return this.

C: No, there’s no.

N: How about Have you ever felt like you wish you could exchange it for a different game?

C: No, so I quite like having a collection. I liked having the diversity collection. I’m the same with books. Like I’ve got a large book collection.

Tear it apart!

I am no stranger to making mistakes, and I am sure I made plenty during this particular interview. I encourage you to use this example to highlight what you might do better and things you would like to avoid in your interviews!

Since I interviewed my fiance, I was a little more informal, but this is my general tone and flow. Here are a few things I missed and would change:

• Getting written NDA and consent from the participant
• Including warm-up questions. My favorites are: “what are your favorite hobbies?” “what do you do in your free time?” “have you tried anything new recently?”
• Saying “awesome” and “cool” quite a lot (internal facepalm)
• Avoiding the future-based questions

The UX Collective donates US$1 for each article published in our platform. This story contributed to Bay Area Black Designers: a professional development community for Black people who are digital designers and researchers in the San Francisco Bay Area. By joining together in community, members share inspiration, connection, peer mentorship, professional development, resources, feedback, support, and resilience. Silence against systemic racism is not an option. Build the design community you believe in.

How I got into User Research

From the first time I heard about user research to my first internship.

Source

Since I was young, I had my sights set on becoming a vet or a psychologist. My parents laughed at the thought of me being a vet. If I saw an animal even stub their paw, I’d be in tears. I spent a brief time shadowing a vet when I was younger. I lasted about 2 hours before I ran out crying, swearing off my future as a veterinarian. I then dove into my second option, psychology.

During my Master’s program in Psychology, I worked in a mental hospital a few days a week. The patients I longed to work with had mental illnesses such as schizophrenia, bipolar disorder, and dissociative identity disorder (it exists). I worked with these patients in the hospital and criminals in a neighboring hospital to get this experience. Over the two years, I completely burnt out and withdrew my Ph.D. applications.

I was terrified. I had some debt from school and no viable career ahead. All of my plans flew out the window. I grasped at straws to find the right job for me. Could I be an interior decorator? Or a motivational coach? Or maybe I could start my own business. I spoke to a few career coaches and still felt lost.

By some crazy stroke of luck, I user experience fell into my life. I was at a party (wallowing, I’m sure) when someone mentioned user experience. They told me it was about making website and app experiences better for whoever uses them. This idea was intriguing. I went home early and looked up this potential new career.

I fell in love

The instant I Googled user experience, I couldn’t stop reading. Everything about the topic spoke to me. There was something about user experience. It felt like a beautiful mix of psychology and technology. I believed I could use what I learned during my Master’s program and apply it to user experience. I thought it would be an excellent fit for me. Plus, it gave me a sense of control. I finally knew what I could do for the rest of my life.

The only problem was I cannot draw. Not for the life of me. To this day, I can’t complete a circle (it always overlaps) or draw easy shapes. Visualization is one of my weakest points. I can see what I want in my mind, but it is almost impossible for me to put it on paper (physical or digital).

I ignored this small hiccup and figured I could learn how to become a designer. Spoiler alert: that didn’t work. However, I am so grateful for moving forward since it brought me to user research.

How did I start?

I immediately filled my shopping cart on Amazon with as many books as I could find, including:

• Interviewing Users: How to Uncover Compelling Insights by Steve Portigal
• Mental Models: Aligning Design Strategy with Human Behavior by Indi Young
• Measuring the User Experience (2nd Edition): Collecting, Analyzing and Presenting Usability Metrics by William Albert and Thomas Tullis
• Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests by Jeffrey Rubin

And many more!

I then scoured the internet for any guides or blogs on the subject of user experience. I sat on Dribbble for ages, scrolling through people’s designs; I found designs on Pinterest (I still have a UX Pinterest Board — although now renamed to User Research); I read guides on how to be a user experience designer. Anything user experience, I ingested.

I then found General Assembly. General Assembly is an education platform geared towards tech- and business-related careers, such as coding, designing, digital marketing, and data analytics. They had two options for a user experience course: a full-time immersive course and a part-time course. Since I was working, I chose the part-time course. I started counting down the days until it started.

What was it like?

The General Assembly course primarily focused on user experience design. We learned about design thinking, prototypes, and different tools such as Sketch. Finally, we came to the section on user research. User research fascinated me. I wanted to know everything about the topic. While my design skills were lacking, my background in Psychology bolstered my interviewing skills. I felt so comfortable conducting user research (although I had no idea how much I needed to grow).

That course rocketed my interest and love for user research. I didn’t get quite enough training in research, but it motivated me to continue my learning and quest to become a user researcher.

I want to make a quick note here: you don’t have to take a boot camp or expensive course with a certificate to get into user research. You don’t need a MA or Ph.D. (although for some companies such as Facebook, it makes it easier to get an interview). All you need curiosity, compassion, and a drive to learn and practice user research.

That course did not (I repeat, did not) get me my first user research job. Hard work and practice made this career a reality, and I will outline each step I took to get into the field.

What happened next?

If only the world were magical and I landed a job right after finishing the General Assembly course. That was not the case. General Assembly was great for understanding that user research was a viable career and the basics. I had a lot of work to do after that course. My immediate next step was to start applying to jobs.

But, before that, I noticed a small caveat present on almost each job description: portfolio required. My heart sunk once I figured out what a portfolio was. I had my General Assembly project, but that wasn’t going to help me with user research jobs. I knew it wouldn’t be easy, but here is what I did:

1. I volunteered for a pet adoption agency and did some user research for them. I had already been volunteering for them, so I knew who to reach out to. I also did this for a few other pet adoption agencies where I didn’t have any contacts — I do so without them knowing, but it served as a portfolio piece. To get participants, I used guerilla research by sitting in a Starbucks with a sign that said, “If you have adopted in a pet in the last six months, talk to me for twenty minutes, and I will buy you a coffee and treat.” It was surprisingly successful

2. I picked two different areas I felt strongly about and researched them. The first was a video game app, and the second was a writing app. I had friends/acquaintances I could use to conduct real user research on both topics. These two topics were passion projects, and my ability to research with friends of friends helped my interview skills.

3. I joined a few different hackathons to see what it was like working with other people (and the networking was great). For one hackathon, I was able to work with a product manager, product marketing manager, UX designer, and developer. Although we didn’t win the hackathon, I felt to a degree what it was like to work in a tech company for that entire weekend.

4. I offered to do small freelance projects for friends and family. I also asked my network if anyone needed help on projects. With this, I was able to work on three small projects for others. I only added one of them to my portfolio because of the size, but it was nice to have the potential to talk about multiple projects.

With all of this work, I created a portfolio of a few different studies. I felt good about my portfolio. Was the portfolio perfect? No. Did it include everything a portfolio should consist of? No. Everyone starts somewhere. But I had case studies. I had something to present and talk about during my interviews.

Are you trying to break into user research?

These are the steps I encourage you to go through:

1. Find a non-profit, charity, or something similar that you can create a project around. You don’t need to know any contacts at the given organization, nor do you have to tell them you are researching their website/app/platform. You can always send them any recommendations after you are done and see what happens!
2. Volunteer for a local small business or organization to see if you can help them. I went to a few different local shops in New York City to see if they needed user research help. I had a few leads on this but, ultimately, spent my time on the non-profit organizations. Due to COVID, here is an alternative: You can also find Facebook groups on specific topics and reach out to people via Facebook or LinkedIn.
3. Pick a true passion project and create a case study around this topic.
4. Join hackathons (even virtual) to experience working with others you would work with as a user researcher.
5. Reach out to friends/family, and friends of friends/family to see if you can volunteer your time to research their websites/apps/platforms.

These are actionable steps you can take to get more experience in user research before your first role, or even between roles!

If you’re looking for some guidance on creating a case study, check out my user research case study outline freebie.

—

Interested in all things user research? Sign up to my newsletter and join the slack community! And check out User Research Academy for freebies, courses, and more!

The UX Collective donates US$1 for each article published in our platform. This story contributed to Bay Area Black Designers: a professional development community for Black people who are digital designers and researchers in the San Francisco Bay Area. By joining together in community, members share inspiration, connection, peer mentorship, professional development, resources, feedback, support, and resilience. Silence against systemic racism is not an option. Build the design community you believe in.

I sat down with a bunch of product managers for a conversation

And the questions I received were fascinating.

Source

The other day I was invited to an informal product meetup as an informal speaker. My fiancé (yes, we got engaged!) is a product manager in Berlin, and he meets about once a month with a group of about ten other product managers. They swap stories and experiences, discuss tools, and seek advice from one another on all things product management. I, personally, imagined meetings filled with JIRA talk and phrases like, “it depends…”

A few weeks ago he asked me if I would like to come in and talk with the group about user research. He asked me if I’d be willing to answer as many questions as possible and be an open book about user research during those two hours. I said yes, but I was a bit apprehensive. A group of ten product managers and one user researcher.

I was mostly nervous that I would be unable to answer their questions well and that I would give them the impression that user research was not valuable. Imposter syndrome crept in on the day of, but I swatted it away. As researchers, we can struggle so much with defending and explaining our craft. I didn’t want to leave a bad impression or mistakenly convince people that user research is unnecessary.

We arrived at the apartment. Cheese and wine were served as everyone settled into their seats. Soon, heads turned to me. Someone asked me if I prepared anything (spoiler: I hadn’t). I explained that I wanted this to be an open forum for them to ask any questions they wanted to and I would do my best to answer.

It was over two and a half hours later that we noticed the time.

What questions did I get?

I had quite a lot of questions from the product managers:

• When do I reach out for help on user research?
• When should I hire a user researcher?
• What should I look for when hiring a user researcher?
• How do I pitch hiring a user researcher to the company?
• What should I expect from a user researcher?
• How should I work with a user researcher?
• Should a user researcher know how to do both qualitative and quantitative data?
• How should I get started with some user research (if I don’t have a researcher our the team)?
• How should I pitch the value of user research to a company/organization?
• What questions should I ask a user researcher?

What surprised me?

There is bad user research conducted out there. Just like in any profession, it can go wrong, and this can leave a bad taste in people’s mouths. A few product managers brought up some difficult times they experienced with researchers. I am sure you can think of some tough situations with product managers as well.

Things can go wrong in all professions and you can have less than ideal interactions with anyone. However, user research is still relatively new as a profession and a role. We have had to push for user research to be done, constantly pitch the value of user research, and defend the validity/reliability.

Based on these experiences, product managers were curious about what user researchers could do that they couldn’t. When they’ve seen user research done badly, they think, what is the point of a user researcher?

Other topics that surprised me:

• Product managers want to work with us.
• Product managers don’t necessarily know how to approach us. They deal a lot more with business problems versus customer problems. As researchers, we need to help our stakeholders translate the business into customer-centric thoughts
• We don’t have enough open communication with product managers. We can’t take these questions too personally. If product managers don’t see the value in user research, it is much more helpful they are honest and ask us, rather than just thinking this to themselves. If we are willing to hear the hard questions and give meaningful answers, we can educate in a positive way
• We have a lot more in common than we think. Product managers and user researchers want the business to succeed — we both want to solve problems and create a positive impact. If we work together better, we can do this much more effectively and efficiently.

What is next?

I left the meeting buzzing, despite drinking water all night and abstaining from the wine (I wanted my mind to be sharp). I wondered to myself, why don’t we have these open and honest communications more often?

We constantly work with product managers, among many other stakeholders, all the time, but we don’t seem to have much open communication. My biggest takeaway is this:

Speak with product managers as if they were your users, stakeholders, and peers. Be open to their questions (even if they hurt), and be honest and kind with your responses. Educate and learn. Together, we can truly work so well.

Here are some additional action items I will take away from this:

• Meet more often with product managers — I am going to try to get back into the group as a follow-up but, aside from that, I will start attending product management conferences, webinars, and meetups to better understand them
• Take these questions and write down answers for my stakeholders, so they can easily reference them. For example, the “when should I reach out” question can be answered in a Google Slides presentation that stakeholders can later reference!
• Writing an article about user research geared toward product managers that answers these questions, and has additional tips

Take some time to sit down and chat with your product managers. Let them as you the hard questions and give you feedback. We can continue to educate each other and work as a team.

The UX Collective donates US$1 for each article published in our platform. This story contributed to Bay Area Black Designers: a professional development community for Black people who are digital designers and researchers in the San Francisco Bay Area. By joining together in community, members share inspiration, connection, peer mentorship, professional development, resources, feedback, support, and resilience. Silence against systemic racism is not an option. Build the design community you believe in.

How I bombed my first generative research interview

And how I recovered.

Source

I had just joined my second full-time job in user research at a company called Olapic. I was bushy-eyed and excited. A few weeks in, I was doing a good job learning and absorbing all the information I could. I was proud to have recently learned how to write research plans in a new way. I was also delving into the subject of discovery research, of which I had almost no experience.

I observed a few research sessions run by my manager. I tried to pay attention to the questions he was asking. I noticed he was entirely improvising his questions, following a loose guide of topics. He based his questions on what the participant had just said.

We had our weekly catch-up after one of these sessions. A few more interview sessions were coming up. I distinctly remember my manager facing me and saying, “Nikki, you’ll run the next generative research session. What do you think?”

I. Was. Terrified. But, of course, I agreed. The week between that meeting and the next interview was the fastest week of my life.

The day came. I remember standing by the printer, waiting for my discussion guide to print, and listening to the audible thumping of my heart. I grabbed my paper with trembling hands, and my heart climbed further up my throat as I sat in front of my computer. My heart galloped along as more people joined in observing.

I dialed in and started the call. My voice was so high-pitched and shaky as I spoke about the weather; I’m surprised the glass in the room didn’t shatter. Right from the start, the participant mentioned a specific feature I was not familiar with. It took me over five minutes of asking the same question before I could comprehend what she was explaining. The participant was frustrated, and I wanted to go home to cry.

I bumbled on but kept drawing blanks or misunderstanding what the participant was saying. About 15 minutes into our scheduled 90-minute call, I gave up. I was too flustered and embarrassed to form a coherent question. My manager stepped in and finished the rest of the interview as I sat and stared vacantly at the wall.

As soon as the 90 minutes finished, I mumbled sorry and ran to the bathroom. I cried for ten minutes straight. Later on, at home, I continued to cry. I woke up the next morning not wanting to go into work. I questioned my right to be a user researcher. I wondered whether this was the right job for me, or if I could be a good user researcher. I considered quitting and going into a role where I didn’t have to talk to anyone — I envied developers. I was defeated and demotivated.

How I recovered:

My manager sat me down after about two weeks. He asked me what was wrong and why I was avoiding research like it was the plague. I covered my face and admitted to him the feelings of imposter syndrome and the doubts I was facing. He told me we all make mistakes and that it wasn’t a big deal. He pointed me to a few resources on generative research, such as Indi Young’s website.

For the next two weeks, I scoured the internet for discovery research guides, talks, webinars, videos, and books. I read countless articles and watched as many videos as I could find. I wrote down many different questions I wanted to ask participants and used open-ended phrasing. I also took the time to have several people walk me through the product, and experienced it from a user’s perspective.

I got my curiosity back. That was the key. I was eager to learn by doing, instead of trying to be perfect at something I had barely practiced. A few weeks later, I went into the next generative research session. It wasn’t perfect, but I spent the whole 90 minutes asking questions. Some might have been leading, and some might have confused the participant, but it was a significant improvement.

I realized that it happens. We all have to start somewhere, and we can’t be perfect with everything. I had to relinquish my control if I was to be successful as a user researcher. I let go of the need to know and plan everything and allowed the participant to lead the conversation where they needed. I was living the phrase, “go with the flow.”

How to prepare:

• Know the in’s and out’s of the product you are testing. That way, if a participant brings up how they are using a product, you will understand what they are talking about. You also won’t have to ask them to explain irrelevant details. Still have them show you how they are using the product, of course!
• Understand any product-related or industry jargon the participant may use, so you aren’t asking clarifying questions on terms. Knowing the jargon also helps you keep up and relate to the participant on a deeper level
• Write a discussion guide with prompting questions if it helps you. I ended up having to do this.
• Use TEDW to foster open-ended conversations, and to write any questions beforehand
• Practice on a colleague (we always have dry runs for people who are learning)!
• Observe others conducting similar interviews and ask them how they prepare
• Assess your previous interviews to derive action items on how you might improve next time (check out my freebie here)
• Continue your curiosity and passion for learning. Seek out courses, podcasts, webinars, books, or blog posts on the topic and use them!
• Try an improv class! These classes help you to think on your feet and go with the flow
• Share your fears, doubts, or concerns with your manager, mentor, or colleague. Just voicing these thoughts helps you through them, and the person may have valuable resources to share

I hope this story does either, or both, of the following:

• Helps someone prepare for their first generative research interviews
• Shows someone that they are not alone in feeling like an imposter, or feeling inadequate in their role

After so many years of being in this field, I still fail and make mistakes. The other day, I overcommitted to a project the team could not support. I failed my stakeholders. I still wanted to crawl into bed, but I called them the next morning, explained my mistake, and mentioned other ways to support them. I am less likely to make that mistake again.

We have all failed, and we have all made mistakes. Failure and making mistakes are the best places from which you can grow. The beauty is, you will never stop making mistakes. And you will never stop growing and learning.

—

Interested in all things user research? Sign up to my newsletter and join the slack community! And check out User Research Academy for freebies, courses, and more!

The UX Collective donates US$1 for each article published in our platform. This story contributed to UX Para Minas Pretas (UX For Black Women), a Brazilian organization focused on promoting equity of Black women in the tech industry through initiatives of action, empowerment, and knowledge sharing. Silence against systemic racism is not an option. Build the design community you believe in.

The life and timelines of research projects

Source

When I was first starting as a user researcher, I had no basis of understanding how projects worked in tech companies. The only mental model I had of research was academia. I was unable to find examples of research projects online and had no idea how they worked. Eventually, I learned that once I saw research in action. However, it would have been highly beneficial for me to understand the overall process beforehand.

For those who have not yet worked in a tech or product company, it can be hard to envision what projects would look like. Previously, I wrote an article about a week in the life of a user researcher. With this article, however, I will shine some light on a seemingly mysterious process only available behind closed doors.

Let’s begin

Imagine you are working at Best Friends Animal Society, an animal welfare organization in America dedicated to ending companion animal deaths in shelters.

Sidenote: if you have a chance to volunteer there, I highly recommend it!

Second sidenote: tears came while writing this article due to my absolute love for animals. If you are looking to do a portfolio piece, consider volunteering for a charity or non-profit organization!

You are a user researcher at this organization. You work with different departments, but primarily tech, product, and marketing. You are continually working with product managers, UX designers, and developers to empower teams to make the best decisions for the organization.

Usually, your research projects come to you in two different ways:

1. From precious research insights
2. From an internal stakeholder

For this project, we will focus on the second. A research project lands on your desk from one of the product managers. Recently, we have seen a drop in the usage of the “adopt” area of the website. The product manager looked at Google Analytics and saw a considerable decrease in time on page and click-thru rate. The team in charge of that functionality wants to understand what is going wrong.

What would you do?

The life of a research project

Before we dive into the timelines with this project, it is essential to look at the holistic life of a typical user research project.

The steps a user researcher generally takes for a research project

I want to stress that this is a typical journey and research won’t always happen in such a linear (and clean) fashion. Often, you have to skip straight to recruitment because of timelines or conduct research while recruiting. This overview is simplified but gets the overarching message across of the steps a researcher generally takes during a project.

As you can see, before you jump right into research, you go through the steps of really understanding and defining the problem and goals of the study. You are meeting with stakeholders to ensure alignment and answer clarifying questions.

Arguably, steps 1–6 are the most important as they drive the project in a particular direction. For example, the research statement and goals help define the methodology, recruitment, and the discussion guide. This building block effect is why it is vital to take these steps before diving into research.

For the ease of this article, let’s come to some conclusions:

Research statement:

• We want to better understand the user’s mental models when it comes to animal adoption to improve our current website

Research goals:

• Understand how users are thinking about adoption, in general
• Uncover how users are currently interacting with the adoption feature on our website
• Identify pain points in the adoption process, in general, and on our website
• Discover other apps/websites users are interacting with to adopt animals and their experience with them

Now comes the picking of methodologies. I have previously written on this subject, and it is a difficult one to explain. However, you use your goals to help guide you to the write methodology, which lands in one of three buckets:

1. Purely generative research
2. Purely evaluative research
3. A hybrid between generative & evaluative research

Here is a high-level and simplified process I go through when deciding:

1. Are we looking to understand mental models, frustrations with current methods, or how users think about concepts in general? Are we looking agnostic of our product? -> Generative research
2. Are we trying to evaluate how users are interacting with a prototype or live product? Are we looking to see pain points associated with our particular product? -> Evaluative research
3. Is there a mix of both? -> Hybrid research

Once I place the goals into one of these three buckets, I can decide on the methodologies that would help answer these goals. The most common associations are:

Generative research

• 1x1 in-depth discussions (aka interviews)
• Contextual inquiry
• Mental models
• Customer journey interviewing
• JTBD

Evaluative research

• Usability testing
• A/B testing
• Competitive testing or analysis
• Benchmarking
• Surveys

Hybrid

• 1x1 in-depth discussion + usability testing
• Card sorting
• 1x1 in-depth discussion + follow-up survey

The different types of user research sessions

Timeline of a typical project

The timeline of a typical project can be over three to six weeks. As mentioned above, it can include just generative research (which is about four weeks total) or just usability testing (which is about three weeks). Another standard timeline is conducting generative research to understand the problem, and then creating insight-based prototypes to usability test.

The timeline of a typical user research study

As you can see, in the above image, you decided to run two separate studies. First, you run a 1x1 in-depth discussion to understand the following goals:

1. Understand how users are thinking about adoption, in general
2. Identify pain points in the adoption process, in general

After, you run a usability test to cover the following goals:

1. Uncover how users are currently interacting with the adoption feature on our website
2. Identify pain points in the adoption process on our website
3. Discover other apps/websites users are interacting with to adopt animals and their experience with them

In this evaluative study, you may also offer prototypes for users to test in addition to looking at the current live product. Or, you may have to run a separate evaluative study to test those prototypes.

Timeline of a hybrid project

Slightly different from a typical project is the hybrid project. I love hybrid projects; they are my absolute favorite types of studies to run. I feel like I get much more accomplished in each session than with the typical project timeline. I also use hybrid projects to highlight the importance of generative research.

The timeline of a hybrid user research study

In this instance, you run a more extensive study, including generative and evaluative research. In one session, you are conducting a 1x1 in-depth discussion followed by a usability test. In this study, you can answer the following goals:

1. Understand how users are thinking about adoption, in general
2. Uncover how users are currently interacting with the adoption feature on our website
3. Identify pain points in the adoption process, in general, and on our website
4. Discover other apps/websites users are interacting with to adopt animals and their experience with them

While I prefer hybrid projects, they are more advanced than the typical approach where you tackle one method. Hybrid projects take more careful planning and time management. While you are practicing and honing your craft, I recommend starting with a regular timeline and making your way to hybrid.

These timelines are not rules!

As I mentioned, these steps and timelines are ideal. You may have to do lean research in two weeks, or you might not have the budget to run two or three separate studies. In this case, you will have to choose between generative and evaluative research. Additionally, you may already have previous research the team could look into to answer the questions.

I offer these graphs and steps as guidance towards your next research project. They are not hard and fast rules to live by, and I encourage you to find the best process for yourself and your organization.

---

If you’re interested in joining an awesome community of user researchers, join the User Research Academy Slack. If this article piqued your interest, and you would like to learn more, check out the courses and webinars I offer.

The UX Collective donates US$1 for each article published in our platform. This story contributed to UX Para Minas Pretas (UX For Black Women), a Brazilian organization focused on promoting equity of Black women in the tech industry through initiatives of action, empowerment, and knowledge sharing. Silence against systemic racism is not an option. Build the design community you believe in.

Freelance or in-house… where to go next in user research?

Which user research track should you choose?

Source

There is no right way to get into user research or one perfect next step on the journey. Whether you are just starting or have been in the field for years, there is no “correct” place for a given level of experience. There is no template for the perfect career path. We are user researchers, and we come from a large variety of backgrounds. Our paths will be just as varied.

I have questioned this next step frequently, to be honest. I am a classic “grass-is-always-greener” case. When I am an in-house researcher, I long for the days of freelance, and when I’m a freelancer, I wish for a stable 9–5. I transitioned between these two roles in the past seven years and, I must say, I love both for their reasons. The choice depends so much on:

• What your goals are
• What you want out of your role
• Your level of experience
• How comfortable you are in different environments

I will talk about the pros/cons of both sides. This article talks about my experience I have had in both roles. I want to provide as much guidance as possible for those who are asking themselves this question. However, my experience may be very different from yours, or you might disagree. In that case, go for it! Try new things and report back!

In-house researcher

I, personally, have come to love being an in-house user researcher. Creating your schedule and working for yourself is fun. However, I love the distinct impact of working in-house. Here are my favorite parts of working in a company as a full-time user researcher:

• Working consistently with the same product. Although some may see this concept as a con (which I explain below), I love it. I love watching the product I’m working on evolving. When I am in-house, I can see my direct impact on this product, which is why I became a user researcher. I watch the pain points of users melt away as we improve. It is very gratifying to see how you have helped shape a product through research.
• Develop in-depth knowledge of an industry. Learning about an industry is fantastic as it allows you to understand your users deeply. You can generate profound insights about who uses your product and what the motivations might be. I loved becoming an expert on hospitality, social media management (SaaS), and e-commerce. It helped me contextualize my learnings from research into an enormous scope.
• Learning how to work on and impact a team. You can learn how to work on a team and how to help that team along with user research. Working with others helps you learn how to pitch the value of user research to different roles. Your process becomes your own as you work through how to integrate user research into an organization. You can also try new and creative methods of introducing and reporting on research.
• Mentorship. Mentorship and proper management aren’t a given, but you are likely to find a manager to guide you. When you have someone to help you, you can learn and develop much more than on your own. They will teach you how to navigate the world of user research properly. A built-in mentor (through a manager)is hands down the biggest pro of being an in-house researcher
• Receiving a stable paycheck. I love getting paid. I also love getting paid the same amount at the same time every single month. I know how much I will get and when it will drop into my bank account. I can count on my paycheck. Even if it isn’t “enough,” I still know it will be there and how to budget around it.

And, of course, there is the other side of the coin. Here are the cons of having an in-house research role:

• Getting stuck in company politics. There is nothing more that I hate than getting sucked into company politics. This can happen if you are working in the same company long-term. It creates tunnel vision. You can no longer see things for what they are but, instead, through a lens of who said what, who was upset, and who pissed someone else off.
• No set working schedule. There are days when I wake up early, ready to work by 7 am. And there are days when I couldn’t be bothered to open my email until after lunch. Some days I don’t want to talk to or see another human. Having to be at work during certain hours can be a drag.
• Same sh*t, different day. The same job with the same people can sometimes be monotonous. You can feel like you are getting nowhere despite the work you are putting in and can get boring.

As a junior, I would recommend an agency or in-house with a user research team and a strong user research manager. These positions will help you develop your skills much faster and further than on your working through freelance.

Freelance researcher

Freelancing can be a lot of fun, and something is alluring about being a freelancer. Although I did freelance for some time in New York City, and I did love it, I default to in-house. Here are some of the things I loved about freelancing:

• Variety of projects. With freelancing, you hop between different projects. You get three months in one place, maybe six months at another, and others might only need you for a few weeks. You are continually working on new ideas and products. This feeling can be refreshing and exciting.
• Seeing how different organizations operate. It is incredible to see how various organizations structure themselves and how they integrate user research. You get to see a variety of teams and their ways of working. Having these experiences can help you apply user research to a diverse set of situations.
• Understanding different industries. Jumping around projects also means jumping around sectors. You can spend a few weeks in e-commerce, a few months in academia, and then some in payments. You will see B2C, B2B, B2B2C companies and understand how user research fits into the puzzle of these.
• Flexible working. You don’t have to be in an office at a specific time every day of the working week. I loved being able to get groceries on a Monday when everyone was at work. Working for yourself means setting your schedule and “unlimited” vacation.

And cons to consider:

• Dealing with health insurance and taxes. I hate paperwork. And I loathe paperwork that I don’t understand. When you are freelancing, there is a lot of paperwork that isn’t easy to understand. You have to deal with your health insurance and taxes, which can get complicated. It is time-consuming and arduous.
• Not a stable source of income. Not having a guaranteed paycheck is one of the hardest parts of being a freelancer. Contracts and jobs can fall through at the last minute, and people can ghost you. Nothing is ever as secure as you would find in an in-house role. Also, you may have to chase people to pay you for work you did.
• Unsure of your impact. Since you are jumping around different projects and companies, you never know if your work will be used. You might put a lot of effort into research to never see the changes come through on the company’s side. You leave a lot up to them, which can feel frustrating.
• Marketing yourself constantly. To get work, you have to market yourself through networking events, reaching out to recruiters, and talking to others in the field. During these times, it can be hard to have a normal conversation since you are selling yourself all the time. This constant search for another contract or temporary role can get exhausting.
• Blurry work/life balance. When I was freelancing, I would do a lot of work from home. This meant that I sometimes turned on the TV at 2 pm, making me wildly unproductive. Or, other days, I would be working late into the night. Like we are all facing with remote work now, it can be hard to find a balance when you are working from home.
• It can be lonely. This experience might be me, but I could feel quite isolated. There were days when I didn’t speak to another human. There was no chit chat by the coffee machine or shared lunches. I couldn’t make “work friends.” This feeling wore down on me.

Looking for freelance user research work? Guess what! It’s the same as looking for a full-time job. You have to apply different search criteria. Here are a few ways I recommend:

• Job boards (ex: LinkedIn) and use the filters for contact or temporary work
• Slack channels
• Networking and word-of-mouth

A note on agency life
Agency lifestyle means you will be working on different projects, brands, and teams, which is attractive in gathering a lot of experience. However, agencies are less likely to do in-depth discovery research, and you aren’t as likely to follow through with the product/brand to make sure the analysis is actioned on or continued. Sometimes an agency is a happy medium between in-house and freelance!

My biggest advice for those just starting is to go in-house or agency. A lot of freelance roles will be for mid-level or senior user researchers because they have to come into a company and do things pretty quickly. Often, you won’t get a lot of guidance, and the company will be in a difficult spot with user research. This is super hard for someone junior to tackle!

Don’t force or rush into any of these if they don’t feel right. I promise you will have the opportunity to try all of them throughout your career if you’d like. Overall, the path is up to you!

---

The UX Collective donates US$1 for each article published in our platform. This story contributed to UX Para Minas Pretas (UX For Black Women), a Brazilian organization focused on promoting equity of Black women in the tech industry through initiatives of action, empowerment, and knowledge sharing. Silence against systemic racism is not an option. Build the design community you believe in.

Basics on how to conduct card sorting

And why it is one of my favorite methods.

Source

There are a few reasons I love card sorting so much. The method is simple, effective, and fun to participate in (for both the moderator and the participant). I was surprised when I realized I hadn’t written an article solely on card sorting. It deserves it’s time to shine.

I first learned about card sorting about six years ago. I was talking to a colleague, and we wanted to redesign our platform for a different set of users. We were currently supporting hotels and hotel staff, but we wanted to see if we would also help staff working in residential buildings (think high-rise apartment buildings in New York City).

Now, of course, there was a lot more that goes into a conversation like that then merely bringing up card sorting. We had done qualitative research with the residential building staff already. We were trying to think of how to pivot the platform. How might we use the existing skeleton to support the differences in workflow?

I was still relatively new to the field of user research, and it was back when I believed there were only two methodologies: discovery research and usability testing. I hadn’t done too much experimenting with other methods for a few reasons. I hadn’t learned about theses methodologies, I didn’t feel confident with them, and I had no real guidance on how to implement this.

We set up our goals for the research session. We wanted to accomplish a few things:

• Understand what current features made sense to these users, and which were missing
• How the users categorized the different features and information on the platform
• How users would imagine the platform to look in terms of navigation and nesting
• The flow users went through in their day-to-day

Many great goals. After a week, we started usability testing. Spoiler alert: it didn’t work. I tried to ask them how they would navigate the current platform and stumbled around with future-based questions that were most likely leading. At one interview, I remember getting out a piece of paper and just having the person write down a list of what they wanted.

Major fail.

We wanted a mix of understanding users’ mental models and information architecture. That is where card sorting shines. After that last interview, I went back to the drawing board, Google.

At the time, I didn’t know what information architecture was, but I eventually put together enough of the right search terms to find card sorting. After reading a few articles, we went to work.

What is card sorting?

Card sorting is an activity in which you give cards to a participant and have them order the information in a way that makes sense to them. These cards can have information written on them, can be blank or a combination of the two.

These three scenarios line up with the three different card sorting techniques there are. Each of them has a time and place. My favorite is mixed card sorting.

Closed card sorting

Closed card sorting is when each participant gets a set of cards with information already written on them. They are limited to using these cards. This approach is very evaluative and is best when the terminology or concepts are well-defined and established. It can give you apparent patterns on the cards. The significant cons for this, however, is that you might not fully understand the user’s mental model, as they have to conform to what you wrote on the cards.

Open card sorting

Open card sorting is pretty much the opposite of closed card sorting. Participants create categories and concepts of their own and then order them. Open card sort is great for exploratory work, and understanding how users relate to, organize, and define different concepts. It can lead to a better understanding of terms and definitions. However, the con for this approach is that the patterns are usually not as clear as with closed sorting.

Mixed card sorting

Mixed card sorting includes cards with predetermined information, but allows the participant to create new categories or concepts that may be missing. When I do mixed card sorting, participants can “edit” the pre-written information. Mixed card sorting is my favorite because it allows for both evaluative and generative work, although you may still run into the same cons of fewer distinct patterns.

How do you choose?

First off, determine if you are in a generative or evaluative phase of the project.

Would you feel comfortable/confident in defining terms, concepts, and categories for your users? Have you conducted previous research that would help you correctly identify them? If yes, you can then use closed card sorting to evaluate the patterns better.

If you are starting from scratch, or don’t feel confident in creating cards, I would recommend going with either open or mixed card sorting. This way, you can better understand how users are defining these areas, and then go ahead with a closed card sorting after that.

To decide between open and mixed is up to you. If you know that some concepts have been validated, but others not, then go for the mixed, if you want to go all out discovery, open will suit you best.

Regardless, make sure you always capture the running commentary as the participants are placing, writing, or organizing cards.

How to run a card sorting test

Many different components go into a card sort, so I split them up into three main steps. I also referenced articles that go more into detail when it makes sense, such as with defining the content of the cards.

Before the card sort

Now that we’ve talked about this magical methodology. Let’s run one.

Define your research goals. As wonderful as card sorting is, it has its time and place (as does every other methodology). To be effective, you need to make sure your research goals match up to your methods.

The common goals that align with card sorting are:

• Evaluating a users’ mental model on the information architecture of a product/service
• Understanding how concepts relate to each other in the mind of the user and the hierarchy of them
• Uncovering definitions, terms, or ideas that might be missing or misunderstood

Decide what card sorting method you will be using. Depending on the phase of your project, choose between open, closed, and mixed. If you aren’t sure, I always recommend mixed. If you are super tight on time, you can do a closed card sort and then, in the end, ask users what they would change.

Writing the cards. If you are doing a closed or mixed card sort, you have to write the cards. Knowing what to include in a card sort is the tricky part. What you write on the card depends on the project. The most important part is not to include more than 40 cards in your card sort. Since deciding what to write for a card sort is an extensive process, I wrote another article on that here. That article is all about how to write cards for card sorting.

Setting up the card sort

1. Usually, card sorts last 60 minutes, so plan for that amount of time
2. Recruit 15–20 participants for this kind of research
3. Get the cards ready

• Make sure there is enough space to spread out all of the cards on a table or ensure there is enough wall space if they are hanging them
• If you are conducting your card sort online, make sure you have sent the link to the participants and tell them they will need internet access

1. Get someone to help you during the session to take notes and observe what you might miss. They can also help with recording the meeting
2. Go through the session to practice before with a colleague to make sure everything makes sense before inviting the participants

Moderating the card sort

1. Give the participant the set of cards (or have them out on a remote tool). Walk them through what the session will be like and explain what you are looking for them to do. In each scenario, mention that any cards that are confusing or they are unsure about can be put to the side.
2. Closed/mixed card sort: Tell the participants you are Explain that you are looking to understand how all of the items on the cards relate to each other. Explain that they can group the information in a way that makes the most sense to them.

• Open card sort: Tell the participant that you are trying to understand what should be in your product/service. Then explain, once they’ve finished naming the cards, that you want them to group the cards in a way that makes sense to them. Once the cards are grouped, you will ask the participant to name the grouping. Then explain that you will ask for a name for each group of cards once the participant has arranged them.
• Request that the participant thinks aloud during the session, so you can fully understand their thought process behind their categorizations. If the participant struggles with thinking aloud, be sure to prompt them regularly

1. Thank the participant, give them a chance to ask any questions, and provide your contact information. Be sure to mention the timeline for any incentive.
2. Finally, email the participant within 24 hours to thank them for their participation in the study and with any incentive you had offered

Analysis

Once you finish the card, it is time to analyze it! To keep the length of this article reasonable, I will write a separate article on how to analyze your card sorting results, including some templates.

Recommended tools and resources

• Notecards and pens
• Trello
• Optimal workshop
• UXSort

---

For more engaging discussion, please sign up for the User Research Academy slack group! And check out User Research Academy for free resources.

---

The UX Collective donates US$1 for each article published in our platform. This story contributed to UX Para Minas Pretas (UX For Black Women), a Brazilian organization focused on promoting equity of Black women in the tech industry through initiatives of action, empowerment, and knowledge sharing. Silence against systemic racism is not an option. Build the design community you believe in.

How to interview as a user researcher if you aren’t (yet) a user researcher

When 1–3 years of experience is necessary for an internship

Source

A company’s expectations of user researchers are high. It is a competitive world out there, especially for people looking to break into the user research field. My heart sinks when I view intern or junior positions that require experience (stop doing this!) or act as though applicants should already be experts. While I believe we need to revamp our hiring process, this is the current situation.

I get so many questions from people trying to understand how to navigate what should be a simple interview process. Let me tell you. It is not easy. How are you supposed to have real-life experience and know everything as an intern or junior level? I have been in this field for over seven years and am still learning.

What I can offer are a few steps and pieces of advice to feel more prepared for your first user research interview. They won’t answer all the questions, but they might make you feel better walking into the session.

Have a story in mind

My first and most significant piece of advice is to have a story in mind before starting the session. This story should be an example of a project you completed. You want to have this story to help you answer the questions they will ask you. Ideally, in this story, you will have faced challenges and can reflect on what you would improve next time.

A great way to understand how to create a story is to look at other researcher’s portfolios. These portfolios will help you know how researchers work in a company.

Before I started working as a user researcher, I knew I had to create a portfolio piece. With this in mind, I volunteered to understand animal adoption and how people interact with animal rescue websites. I chose a company I volunteered with in the past. I conducted generative research to understand pet adoption in general and usability testing of the website. I also did a card sorting exercise to see the impact on navigation. I brainstormed some metrics I imagined the company would be tracking, such as click-through rate, in-person visit rate, contact rate, etc. Although I didn’t have access to their data, I wanted to show my understanding of business metrics.

I then used this story throughout my interviews as an intern and junior researcher. This story helped form my process and, although it was outside of a typical company, I had answers to why I chose the methods, how I recruited, and how I conducted the research. I also prepared reflections and challenges:

• Working alone is very difficult, and I was lucky to get some input from my friends who are designers
• I developed a report with findings to pitch to the company, but ultimately, did not have the opportunity to work with them
• I wasn’t working on a strict timeline, but I tried to simulate the timeframe in a company setting (I allocated five weeks for the entire project)

Understand how the company works (and company jargon)

It is challenging to demonstrate how you would fit into a team without a general understanding of the basics of how tech teams work. And without the jargon or terminologies that are common in the tech and user research industries. I recommend researching how tech teams work, how businesses work, and how user research can fit into organizations. This will make you stand out to recruiters and companies, as someone with a real passion and motivation to go above and beyond.

When I was newly interviewing, I found it very important to understand the timelines at a company. I delved into understanding how scrum, sprints, and agile worked since the majority of companies I applied to used those methods.

I read everything I could about how user research might work in these confines. I also learned about how long specific user research methods generally take. Although timelines can differ (through recruitment availability and tools the company has), here are the basic guidelines:

• Generative research methods can take 4–6 weeks
• Evaluative research methods (usability testing) can take 2–4 weeks
• Surveys can take 1–2 weeks
• Recruitment can take 1–2 weeks
• Alignment meetings can take up to 1 week

Some of these methods can overlap, but keep these in mind when determining a timeline. As a note, you can start researching before you finish recruiting to cut down timelines!

With this in mind, I tried my best to simulate how I would research projects at a company. When people asked me how I would deal with tight deadlines, I had mentioned my ideas on methods I could overlap and ways to speed up recruitment.

I wrote an article on the essential concepts, processes, and jargon to understand. Check it out here.

Know who you will work with and how you can collaborate

Understand the different roles you will work with. Some of the most common for a user researcher are:

• Product managers
• Designers
• Developers
• Marketing
• Account management
• Customer support

It is helpful if you have never worked in a typical company setting to research each of these roles. Understanding their day-to-day and their goals will help you know how you would work with them.

Let’s go back to the example I used above. I had never worked in a tech company. I had no idea what a product manager was.

Knowing the roles I was going to be working with, I could answer questions about when I would engage with them. I also felt more confident about how I would pitch user research value to these roles since I could speak to the goals they were trying to accomplish.

For example, even though I had never researched content copy, I knew that was something marketing worked on. That way, I could talk about how I might interact and help the marketing department. Additionally, I knew customer support had incoming calls about customer problems. I could then talk about how important it was for me to meet with them regularly to understand top issues, which would reduce their workload if fixed.

If you aren’t able to talk to the different people in these roles, look up job descriptions. These descriptions should help you understand what the responsibilities are and what they are trying to achieve.

Be prepared for a whiteboarding challenge

The whiteboard challenge for a user researcher can be a daunting task.

Your interviewers will give you a vague prompt and want you to provide them with an idea of your process. This exercise allows them to evaluate how you go about approaching a problem in a “real-life” setting, beyond your curated portfolio. Companies are increasingly valuing employees’ thought processes over their qualifications.

Understandably, this can be a challenging experience, which is why you should practice beforehand! Whiteboarding your approach is a great skill to have in general.

Check out my whiteboarding approach in this article. And practice!

Get ready to answer tough questions

There will be some questions that you might not be able to answer. Keep in mind, it is okay to say, “I don’t know.”

A lot of your answers will be hypotheticals. For instance, since I didn’t work with product managers in the past, I could only say how I might engage with them. By knowing the different roles, you can better hypothesize what you would do in various situations.

When I had to talk about how I would work with product managers, I answered based on my research. I knew I would have to involve them early, that I might have to explain the value of user research, that I would have to meet with them frequently to ensure user research was correctly involved. With this knowledge, I brainstormed ideas on how to answer those questions. I read articles on how people have tackled these issues in the past and used that as my hypothetical answer.

Here are some questions you should be prepared to answer:

1. What is your user research process?
2. How do you manage difficult stakeholders?
3. How do you convince stakeholders about the value/importance of user research?
4. If you had X goal, which methodology would you choose?
5. How do you select the right method for a project?
6. How do you turn insights into actions a team can take?
7. How do you ensure your deliverables are acted upon?
8. Talk about a challenge you have faced. What was it, and how did you overcome it?
9. What is the most challenging part of your research process? (For you and others)

The best approach for interviewing for a user research position is preparation. Take your time in understanding how user research works at companies, and think about how you would positively impact that organization through user research. If you are feeling stuck, read through another researcher’s portfolio or ask a fellow researcher to talk you through their process.

Torch the user research reports

Creative ways to share user research insights

Source

The first time I was asked to create a research report, I was lost. After spending my life writing academic reports, I was used to the long-winded, endless vocabulary in these presentations. Producing a report like that, as a user researcher, would prompt a lot of blank stares. And when I tried it, it did. After (many) failed attempts, I have finally found three ways to effectively share user research that is tangible, creative, and realistic for a user research team of one or fifty.

After creating and presenting my first user research report, I received many blank stares. I stood in front of the CEO, CTO, and head of product — shuffling through a pretty dull, and visually unappealing, deck. (To my humiliation, I’d used a preset gradient background). Each slide was filled with information I gathered from research sessions. And while it was helpful information, it was a lot. It wasn’t distilled down into anything digestible by upper-management.

That was when I learned my first lesson in presenting research: It doesn’t matter how useful the findings are if you aren’t able to communicate them effectively with your team. I also realized how easy it was to feel like an imposter in this field.

The worst thing you can do when you present research or create a research report is to have it sit in a folder somewhere, collecting dust. Insights need to be infused with excitement and urgency to promote action, and it is our job, as researchers, to do just that.

Now, whenever I share user research, I use the following formula:

Informative + actionable + fun = solid user research shareout

After many attempts at successfully sharing user research in an energetic and knowledgable, I have finally found five ways to effectively share user research that are tangible, creative, and realistic for a user research team of one or fifty.

Different ways to share insights

Demo desk: A “Demo Desk” is an area that allows employees to stop by and play with the current prototypes/ideas you are working on and give feedback. This will give other employees the chance to understand what the product team is working on and also give their input to impact your ideas. It is a great way to understand what user research is, how it is conducted, and how it affects your product/service.

Usability movie night: Usability movie night is an event you can host showing back-to-back video clips of usability tests, which brings everyone closer to the customers’ experience. Nothing makes us empathize with our customers more than watching them use our product. Whether they’re struggling to understand the UI, or they’re thrilled to interact with a new feature, observing the customer experience first hand is incredibly eye-opening. It helps teams plan where they should next focus their efforts.

Choose Your Own Adventure: The entire point of a CYOA is to bring someone through a story in a way that they feel very connected to the material. I have used CYOA to connect the product and tech teams to our users in a creative and digestible way. I craft stories and scenarios for our personas and allow the teams to make their way through these stories that reflect actual choices users must make. Shopify wrote about how they have had much success with this type of deliverable.

Research session snapshots: This type of summary I use is full of factual information and consists of direct recommendations or the next steps. I create a research session snapshot after a usability test, or when I am synthesizing a few generative research sessions for a team. Generally, in this scenario, we might not have time for a group synthesis session, or this could be a summary of the group synthesis session.

Canva infographics: Qualitative research summaries and reports can get very word-heavy. By breaking the words into infographics, we give a visual representation of what we learned, which is more engaging for those receiving our reports.

How to use these methods

Now that I have explained some of the different techniques I use to share user research insights and ideas, I will take you through how I set each of them up.

Demo desk

Necessary equipment includes iOS and Android test devices, Windows test device, Mac test device, desk area, feedback sheets, candy (for a reward!)

1. Find a central space in your office space where you have space to set up the various test devices relevant to your product/service
2. Speak with the designer(s) to understand any upcoming prototypes or concepts they want to test. The feedback you can generally expect from a demo desk is visual appeal, usability, typos, missing information, confusing information, and what is going well
3. Set up the prototypes of the test devices
4. Write up brief descriptions of each prototype, so people are aware of the context and a feedback sheet.
5. These are the steps I use to explain:

• Choose your preferred device
• Open up the prototype (all the current ones will be on the homepage/desktop)
• Read the brief context about the prototype you choose to test
• Be aware, it is a prototype, so things might not work as they do on our platform
• Play around with the prototype for 10–15 minutes (more is even better!)
• Fill out a feedback form
• Leave your feedback form in the demo desk feedback jar
• Take a piece of candy and have a wonderful day
• If you are having any trouble, come to Nikki’s desk and annoy her until she fixes it 😊

6. Write up a feedback sheet. Here is what I include:

• Date and prototype being tested
• What was confusing about this prototype/idea?
• What didn’t work?
• What was missing?
• What would you change to improve it (and a short answer on why)
• What was working well?
• What did you like about this prototype/idea?
• Any other feedback, comments, questions, or suggestions

7. Aggregate the input every week (or few days) and present to the designer(s)

Usability movie night:

1. Choose a theme for the night, such as a pattern you have seen in generative research, or a series of usability tests on a particular prototype
2. Create an introduction to the movie night, which gives the audience a context of the goal and objectives behind the research you were conducting
3. Find short and compelling video clips (you can do this while you synthesize) that clearly show user issues, confusion, unmet needs, or goals they are not able to achieve. I usually pull about 7–10 video clips, two minutes each. Put these together in succession to show the pain points or problems users were having. I also include two or three short clips at the end of positive remarks users had about the product/service.
4. Engage the audience in a game after they view the videos. This could be a role-playing game where people write down ideas on how to alleviate these pain points, and the top three ideas win a prize. Or, you could set up a scavenger hunt around the office, in which the clues correlate to problems or pain points the users had.
5. Order snacks, pizza, and beer for the team for the usability night and have fun!

Choose your own adventure.

This is an excerpt from an article I wrote for dscout, which gives more information on the CYOA model. As mentioned, Shopify also went into detail about how they create CYOA.

1. Choose a problem you want to bring to light. For instance, I wanted to highlight the non-linear path that comes with planning travel and all the nuances involved. This will give you a good understanding of the type of story you want to create, and which part of the journey to focus on. I always ask myself: What is the goal of the user at this point? Where does that goal start and end? I now have a story starting point and endpoint and need to include the details in between. I then choose the most common pain points, needs, and tasks to include in the story.
2. Create a user flow. Once I had an idea of the overarching story, I broke it down into a flow or journey the user experiences. Mostly, these are steps the user has to go through to achieve that goal identified above. At this point, most of these are linear, task-based steps, without any emotion. It’s okay if they are a little disjointed, and some parts don’t connect correctly with others. This stage is really for outlining the basic story.
3. Infuse emotion. Once I have a basic outline of the story, I begin to add emotions to the context. Instead of simple text, I form scenarios. For instance, “select a date to travel” becomes “Jonas isn’t sure which exact dates he will travel. On the website, he sees the option to select a set date range, which annoys him, seeing as he wants to explore several different options.” Adding these intricacies allows readers to understand pain points in a way that is not solution-oriented and is product-agnostic.
4. Add choice. Now comes the most complicated, but interesting, part: adding options. This is where it is very beneficial to get into the mindset of the user and relive the research sessions. Where do your users have to make decisions? What are the triggers that cause them to think: “Forget this website/app, I’m going somewhere else”?
5. Read your story. Go through the CYOA, ensuring it makes sense, and you have included the different possibilities in an easy-to-understand narrative. The value of a CYOA is that it can continuously evolve and grow as you learn more about your users.
6. Send it out. I first send these stories to the UX team, so they can glance over to see if everything makes sense. I then roll it out to the broader company. Often these stories are based on personas, so I also make sure to socialize those with the story to give more context.

Research session snapshots

These snapshots are a quick way for the team to easily visualize what important information has come from the research sessions. My snapshots include:

1. Which participants faced this issue (ex: P1, P4, P5, P7)
2. The insight/problem
3. The actions/recommendations
4. A quote
5. 1–2 video relevant video clips that highlight the issue
6. If it is a usability test, an annotation of the screen and what happened

I hope these help diversify the way you share your research insights and give you some creative ideas. Remember: food and drinks really help to motivate people to join events — so keep that in mind. Please let me know if and how you use these, and any adaptations you do!

---

If you are interested, check out more free content and my offerings on www.userresearchacademy.com and join our slack channel

How to ask for feedback

And why it is so important.

Source

No matter where you are in your life and your career, there will come a time where you will either ask for feedback from someone, or you will be asked to give feedback. Feedback is an amazing tool and is one of the best ways you can learn from others. Without continuous feedback, it is almost impossible to improve.

Learning how to properly ask for feedback, and how to give feedback, are two huge milestones in your career. By asking for feedback, you admit you don’t always have the correct or best answer, and you open yourself up to a world of opportunities. You show people that you aren’t afraid to be wrong, and you also show yourself that it is okay to ask questions. And, by giving feedback, you help others grow personally and professionally.

Without asking for and giving feedback, how would you be able to move forward? How would you know ways you can improve for next time? Albert Einstein was attributed (although many would argue otherwise) with saying:

The definition of insanity is doing the same thing over and over again and expecting a different result.

Without feedback, we would continue doing the same thing over and over again, hoping for a better result. Continuous feedback breaks these toxic cycles.

However, this can go horribly wrong. On both sides.

---

Let’s start with the concept of asking for feedback…

It is wonderful when people ask for feedback. I absolutely love it. However, sometimes, the questions can miss the mark. I believe the right intent is there, but it can leave the person receiving these requests either frustrated, confused, or tired.

For example, I spoke with a few friends who get asked feedback frequently for portfolios, resumes, jobs, etc. Both of the below scenarios are, of course, exaggerated to get the point across, but they are still representative. Here are three examples:

**I do understand we are in a time where people may really need jobs, and we are emotionally exhausted. So if you receive a message such as the below, be kind and try to explain that you simply need more information to give the best feedback/do the best networking possible

Example 1 (networking):

• Person: “Hey, can you help me find a job?”
• Feedback giver: “Hey, let’s see if I can help. Can you tell me more?”
• Person: “I’d like a job in user research.”
• Feedback giver: “Okay…where are you looking for a job.
• Person: “Anywhere, I can work remotely or move.”
• Feedback giver: “okay…where are you currently located?”
• Person: “Boston.”
• Feedback giver: “And what kind of role are you looking for? What level? What type of company…”
• Person: “Anything user research related.”

Example 2 (networking):

• Person: “Hey, can you give me some feedback on my portfolio piece/resume?”
• Feedback giver: “I’d be happy to, what kind of feedback are you looking for?”
• Person: “If it is good and if it will get me a job.”
• Feedback giver: “Sure, but what is your experience level”
• Person: “Mid-level.”
• Feedback giver: “Okay, and what types of jobs are you applying to? This will help me with giving you the best feedback.”
• Person: “Mid-level user research jobs.”
• Feedback giver: “Can you give me an example of a company?”
• Person: “UK Gov.”
• Feedback giver: “Okay, and what is your biggest strength and your biggest weakness in your portfolio?”
• Person: “I don’t know.”

The thing is, we are all learning how to network and how to get through these situations. Some people have been networking for years, and some people are naturally good at it. But others are still trying to navigate the digital world of networking and asking for feedback, where we lose important indicators such as body language and tone.

Example 3 (workplace, over slack):

• Researcher: “What do you think of this research report I just put together?”
• Colleague: “It’s nice…but I am not really sure how to use it…”
• Researcher: “What do you mean, you don’t know how to use it?”
• Colleague: “Maybe it is just me, but how should I use this for roadmap or planning?”
• Researcher: “Well, it isn’t as if I can give you all the answers, but it shows the number of participants who were confused on slide 7.”
• Colleague: “Sure, I guess I’m just not sure what the next steps should be. Really, maybe it is just because I’m not used to working with a researcher!”
• Researcher: “Okay, then what can I do?”
• Colleague: “Maybe you could put the next steps or recommendations you have…”
• Researcher: “Okay, sure.”

It can be difficult to hear negative things about work we’ve put time and effort into. Sometimes the feedback will come out in kinder ways (such as above), and sometimes not. We have to learn how to take this feedback and make it as constructive as possible, to learn how to do better next time.

Some guidelines on asking for feedback:

1. Think about both sides. The best advice I can give when asking for feedback is to think critically about your message. Would you like to receive it? If you received it from someone else, could you help them?
2. Mean it. Don’t ask for feedback if you aren’t going to use it or are just going to defend whatever you currently have or are doing. This isn’t helpful for anyone. It is totally fine to disagree and have discussions (that is another way we learn), but don’t just ask and ignore.
3. Give more context. As mentioned above, more context makes communication more clear for everyone. It also makes everyone’s job a lot easier. It is really difficult to authentically reach out to help someone find a job if you aren’t feeling motivated to do so based on the message you received.
4. Try not to get defensive. As I mentioned, it can be hard to not get upset when someone doesn’t understand something you have worked on. Remember, you are all working together towards the same goal within a company. The best thing you can do is understand someone’s perspective and then decide what to do with the feedback. Maybe there is a misunderstanding and you can make things more clear, or maybe something is confusing that you can change.
5. TALK to the person first. If you are connecting with someone you don’t know and asking them for feedback, create some conversation. Show them you did some research and why you want to get their feedback. Maybe they wrote an article or gave a talk you loved — let them know! Try not to just lead with asking for things.
6. Give people the benefit of the doubt

---

Better feedback conversation examples:

I just quickly wanted to give some good examples that are similar to the ones above. These are also based on real-life experience! It just takes time to learn these skills, but it is important in advancing your career.

Example 1:

• Person: “Hey! I was wondering if you could help me with finding any opportunities. I am a mid-level user researcher located in Boston, MA (but willing to relocate or work remotely). I have worked as a researcher for 3 years, mostly at B2C companies. I am looking to move to a smaller sized company (under 500 people) and in the B2C space. I would love a role in education tech or medical tech, however, I am also happy to work in the e-commerce space (where I have more experience). I’ve attached my resume if you want more details. Please let me know if there is anything else you need from my side. Thank you!”

Example 2:

• Person: “Hi! I am currently looking for a new job in user research. I created this portfolio based on my recent work at a B2C company. I am starting to apply to some junior and mid-level roles (I’ve only been in the field for about 1 year). I am really struggling with the layout and making sure my content is engaging. I have some nice deliverables, but I’m not sure if everything makes sense when I put it together. Would you mind looking through it to see if it tells a story? And also if there is any content I am missing that you think would be applicable to a hiring manger? Thank you and let me know if there is anything else you need!”

Example 3:

• Researcher: “What do you think of the research report I sent you a few days ago?”
• Colleague: “Oh, it’s nice, but I’m not really sure how to use it…”
• Researcher: “That is such great feedback, thank you for sharing. Can you tell me more about what is confusing or missing? I’d love to make it more actionable for you, and be able to improve the next reports! Maybe we could have a meeting to discuss it?”

All of these are just simply models based on some experience I and others have had. These aren’t rules, by any means, they are simply some guidelines you can use when thinking about asking for feedback. Again, I’m not saying the first examples are wrong, but they might come off as difficult to engage with to some. Remember, you are asking favors of people when you ask for feedback. You want to make sure you come off as clear and understanding.

We all can come together and think about how our words impact each other, on both sides, and become better at communication. As the world evolves, online communication will start becoming more and more inherent in our lives. It is best to think about having a conversation online as you might in person.

Stay safe and healthy

---

For more engaging discussion, please sign up for the User Research Academy slack group! And check out User Research Academy for free resources.

Seven steps to writing a screener survey

How to make sure you are always getting the best participants.

Source

Screener surveys are an excellent tool for the beginning of each research study. Before you jump into recruiting, you can send out this survey to assess potential participant’s backgrounds, behaviors, habits, and other essential characteristics.

There are a few reasons we write screener surveys:

1. Find and talk to the most relevant participants for your research study
2. They help you guarantee you are getting high-value participants
3. Ensure return on investment for your research will be as high as possible
4. Avoid wasting time/money on suboptimal participants
5. Avoid wasting the time of others (ex: users who might not be the best fit)
6. Dodge awkward research sessions where the participant cannot meaningfully answer the questions you are asking

I learned about the importance of screener surveys the hard way: through first-hand awkward experiences with the wrong participants for my study. I was researching the process that occurs when people move to a new home or apartment. I wrote my screener survey, which was full of demographic information, and asking a few questions about whether they had moved recently.

We received a good number of responses quickly, and I was happy. They were matching the demographic data we wanted from our target participants. Nothing ticked in my head, saying, “how are we getting so many participants so quickly?” Not to spoil the plot, but it had to do with the screener survey. It was too focused on demographic data and not focused enough on behavior.

So, what happened? I had participants come in, and I asked them my default starting question, “tell me about the last time you moved.” They gave me an overview, and I set to dig into the details:

• Me: “Okay, great, now walk me through the step-by-step process you went through.”
• Participant: “Oh, I wasn’t involved in the process. My partner/real estate agent took care of that. You should probably talk to them.”
• Me (internally): Sh*t.

Some of the people had lied on the screener survey. They responded saying they had moved in the past year. However, some had moved a few years ago. But they knew what I was looking for and the correct answer to participate for the incentive.

I had recruited the wrong participants because of my screener survey. Not all the participants were a bad fit, but an overwhelming majority ended up not being super helpful. I had to redo my screener survey and start recruiting again. That is when I learned, screener surveys:

• Are not all about demographics
• Should focus on behavior and habits
• Need to elicit specific information
• Can’t give away which answer is correct

After that experience, I took my screener surveys much more seriously and learned how to write them correctly.

However, they can be tricky to write

Like most things in user research, we have to consider how we construct screener surveys seriously. Certain questions can backfire on us. You have to achieve a balance within a screener survey:

1. Get the right information to qualify the best participants
2. Make sure you are not asking obvious questions that would lead people to exaggerate their responses to participate

Tips for writing effective screener surveys

After a few years, I have done my best to achieve this balance. I always use the following steps before writing and sending out a screener survey.

The seven steps to writing an excellent screener survey

1. List the criteria of your ideal participants. Before you even think about recruiting, it is beneficial to list out all of the different criteria an exemplary participant would have. And think about the information you need from them. For instance, if I had genuinely thought about needing information on the step-by-step moving process, I would have (hopefully) included questions about whether or not they took part in this. It is beneficial to consider:

• Who are your target personas or proto-personas
• What behaviors do you want to understand more?
• What habits are you trying to target?
• What are the goals the user is trying to accomplish?

2. Write one question for each criterion you identified

• For each ideal standard/behavior, write one screener question

For example, if it is essential someone has wanted to move for 60 days; write a question about this behavior

• Make sure to write precise questions that ask for particular behavior patterns or timeframes:

Imprecise criteria: People who have wanted to move for 60 days

Precise criteria: People who have visited 3+ apartments in the past 60 days

3. Focus on how potential participants feel and HAVE behaved

• Focus on their past behavior, as it is the best predictor of future behavior

Future question: Will you look at apartments in the next 60 days?

Past question: Have you looked at 3+ apartments in the past 60 days?

• Ask for only the most basic demographic information that you need, since it makes the survey longer

4. Order your questions carefully (use logic!)

• Ask questions that will quickly weed people out in the beginning
• Prioritize the essential criteria you need the participant to align with before you ask specific questions

For example: Make sure you ask IF someone has thought about moving before asking them how often they have viewed apartments

• Ask about location first if you need in-person interviews
• Use a funnel approach

For example: Start with more broad questions, move into specifics, and then broaden out again with questions like demographic data

5. Avoid leading questions

• Leading questions will influence people to answer in particular ways, and skew your data
• Leading: How great was our coffee?
• Fixed: How would you describe our coffee?

6. Include a mix of open-ended and closed questions to avoid obvious answers

• Using a combination of open and closed questions helps to make sure you are getting the best participants. A 60/40 mix is safe, where 60% of questions are closed, and 40% are open-ended questions.
• Open-ended questions help you see how a participant would answer in their own words, without priming them to respond in a specific way
• Using closed questions in a non-obvious way can help you understand behavior patterns (ex: asking how many times someone viewed apartments in 3 months, and giving a range of answers)
• Adding an open-ended question to your screener survey can give you clues as to how much insight a participant will provide in your actual study
• One word responses, illogical rambling or cagey answers can all indicate that a participant may provide a low return on investment

7. Always include an open text field

• Always make sure you include an open-text area in each multiple-choice question, as it is impossible for you to know you include all options someone might need
• Ex: “other,” “not applicable,” “I don’t know,” or “none of the above”

Let’s go through an example:

We own a plant shop in Brooklyn, New York, where we sell groups of exotic plants. We have been posting our plants on social media, and people from around the United States are contacting us and asking if we have an online shop. We want to consider this as an option but aren’t sure what people would want or expect. We want to conduct user research to understand the following:

1. How people would like to purchase plants online
2. What do people expect of an online plant store
3. What do they think of other online plant stores
4. Get their opinion on a prototype of the online plant store

Our screener survey might include questions like:

1. Have you purchased plants online? (Yes/No)

If yes:

1. How often have you bought a plant online in the past six months? (Multiple choice)
2. How many plants have you purchased online in the past six months? (Multiple choice)
3. Where did you purchase from? (Short open text)
4. How was your experience with buying plants online? (Long open text)

If no:

1. Have you considered buying a plant online? (Yes/No)
2. If yes, why have you not purchased one online yet? (Open text)
3. If no, why have you never thought about it? (Open text)

Feel free to add more thoughts on how you would screen!

---

For more engaging discussion, please sign up for the User Research Academy slack group! And check out User Research Academy for free resources

If you liked this article, you might also be interested in:

• Moving Beyond the NPS to measure experience
• Recruiting the right participants
• Writing a UX Research survey
• Elevating your survey questions

Concepts, processes, and terminology — oh my!

The important terms and ideas to understand as a user researcher.

Source

I recently ran a webinar on the topic of transitioning from academia to user research. A lot of my webinar focused on the importance of understanding the teams and business you will be working in as a user researcher. Although you can create a perfect portfolio piece in a silo, it is imperative to have the ability to relate to how an organization runs. I have spoken to many UX research recruiters and what they look for, in addition to user research skills, is how you would integrate into a team.

It is challenging to demonstrate how you would fit into a team without a general understanding of the basics of how tech teams work. And without the jargon or terminologies that are common in the tech and user research industries. I recommend doing research on how tech teams work, how businesses work, and how user research can fit into organizations. This will make you stand out to recruiters and companies, as someone with a real passion and motivation to go above and beyond.

A note about business and user research

The real truth of the matter is that companies exist to make money. I hate always coming back to this fact, but it is reality. And we have to face reality. The majority of what teams are looking to accomplish in an organization exists to make that company money. We need to be okay with this fact and understand where user researchers fit into it.

User research enables teams to make the best decisions. When organizations make better decisions, it tends to impact essential business metrics for a company, such as conversion rate, revenue, retention rate, acquisition rate. When teams make informed decisions that create a positive impact on users, they can better contribute to the mission of making the company more money. So teams rely on you for fast research to make these better decisions and positively impact the organization as a whole.

What UX is juggling

This is really important to understand because it gives you context into what your mission is on a team, and in a larger organization, outside of the day-to-day tasks.

Now on to teams…

Fitting into a team is essential for user researchers. It is crucial to understand every single role you will be working with. These internal stakeholders will become your internal users. They will be reaching out to you with questions and digesting the research you deliver. By understanding what they are trying to accomplish, you can better empathize with them and tailor research insights in a way that is optimized for their day-to-day. This also helps you figure out where and when user research is relevant in a project.

Ideally, as a user researcher, you work with all different roles and departments. However, the colleagues I have worked with the most are:

1. UX/UI Designers
2. Product Managers
3. Developers
4. VP- or C-Level Executives (from Product, Engineering, & others)
5. Account Managers
6. Customer Support
7. Content marketing

The list could go on, but these are the major roles I have seen could benefit from user research. Take the time to learn what each of these people does and what they are trying to achieve. With this knowledge, you can positively impact their lives with research, which will lessen the need to beg them for buy-in.

Understanding teams/processes = including research

Processes, Jargon, and Terminology

I will not go in-depth with each piece of jargon, terminology, and process, but will provide a list of which you can use to then deep dive into. This also does not include every process, piece of jargon, or terminology out there, but it is a starting point for learning about the different concepts user researchers commonly encounter.

Processes:
By understanding processes, you can understand where user research fits in.

• Agile
• Scrum
• Sprints
• Ceremonies
• Retrospectives
• Backlogs
• Standups
• Kick-offs
• Lean methodologies
• Waterfall
• Kanban
• Requirements
• Product management
• Product roadmaps

Concepts:
By knowing these concepts, you can make sure you are including them and doing robust research

• Business metrics (ex: click-thru rate, conversion rate, retention rate)
• OKRs / KPIs
• Product analytics, by using tools such as Google Analytics and Firebase
• Validating/disproving hypotheses
• Prototypes, wireframes
• ResearchOps
• Usability Metrics
• A/B testing
• Workshop moderation/facilitation
• Iteration
• Ideation
• Design thinking
• Recruitment
• QA (quality assurance)
• How Might We Statements/reframing solutions

Terminology & Jargon
With knowledge of terminology and jargon, you can talk more confidently with many different departments about all you can help them with

• Generative research (or discovery research, problem-space research)
• Usability testing
• Diary studies
• Card sorting
• Guerrilla research
• Jobs to be Done
• Heuristic evaluation
• Competitive analysis
• Affinity diagrams
• Participatory design
• Mind map
• Customer journey map
• Mental models
• Empathy map
• User scenarios
• Surveys
• Screener surveys (link coming)
• Personas (and here)
• User stories
• Implementation
• Deployment
• JIRA

I hope these are helpful in getting you started with learning how tech and product teams/organizations work in the real world, as well as important terms to understand as a user researcher. The more familiar you are with these, the more you can conjecture how you could impact an organization as user researcher.

Especially big thanks to Nielsen Norman Group and Atlassian for documenting so many of these terms, making my life easier when finding great links!

---

If you are interested, check out more free content and my offerings on www.userresearchacademy.com and join our slack channel

If you liked this article, you may also enjoy:

• How to Break Into User Research
• User Research Practice Problems
• Moving from Academia to User Research

User Research practice problems — updated

Because practicing whiteboarding, research plans, survey writing, and portfolio pieces makes perfect.

Source

Updated March 2020

After teaching many classes and mentoring many students, the mantra “practice makes perfect” has become one of my most common sayings. During my courses and mentoring sessions, I only have so much time to go through practice examples. With that limitation, I thought it might be helpful to brainstorm a list of problems that many people can use to practice.

Some of the problems on this list are from my brain, and others from various things I may have seen over the internet. I’m sure some people have imagined these problems before me, and I will do my best to link to anything I take directly from another website. I will include these resources at the bottom of the article.

I will do my best to update this with new problems as much as possible. If you have any suggestions, please email me: nikki@userresearchacademy.com

How to use the list

The reason I put this list together is so you can practice various skills:

1. Whiteboarding sessions (read how to tackle a whiteboard session)
2. Writing research plans (read more about research plans, with a template)
3. Survey writing (read about writing survey questions)
4. Research portfolio pieces (how I structure a user research portfolio)

And anything else you think about!

You won’t have all the answers since these are static problems, and I can’t answer all the questions you may have about each problem. I also didn’t go into crazy detail for each problem. In this case, write down the questions you have or the assumptions you make. And then how you would tackle these. This is good practice regardless, as this happens a lot in real life!

Now on to the problems…

List of practice problems:

Problem statement
How can we better understand the way people travel?

Project brief:
Your client is a leading travel brand who sees new opportunities emerging in the digital space around how people plan travel. They want you to focus your research on one group of the travel experience, either leisure travel or business travel. The client expects you to deliver insights on how people travel, in order to start designing something relevant for users.

---

Problem statement
How can we better understand the way people adopt a pet?

Project brief:
Your client is a non-profit animal shelter who wants to better understand the process people go through when trying to adopt a new pet, specifically in the digital space. They want you to focus your research on people who have adopted a pet in the past 1–2 years. The client expects you to deliver insights on how people adopt pets, in order to start designing a digital solution relevant to users.

---

Problem statement
How can we better understand the way people digitally communicate with each other?

Project brief:
Your client is a messaging platform that wants to better understand how people digitally communicatee with each other. They want you to focus your research on people who use platforms such as iMessage, WhatsApp and Facebook Messanger to communicate with others on a daily basis. The client expects you to deliver insights on how people communicate with each other, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand the way people find their way around a new city?

Project brief:
Your client is a tourist agency who wants to better understand how people find their way around a new city. They want you to focus your research on people who have traveled, at least once, to a new city in the past six months. The client expects you to deliver insights on how people navigate a new city, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand the way people organize their wardrobe?

Project brief:
Your client is a retail platform that want to better understand how people organize their wardrobe. They want you to focus your research on people who purchase new clothing on a regular basis (at least once a month) and care about organizing their wardrobe. The client expects you to deliver insights on how people organize their wardrobe, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand the way people set and stick to their goals?

Project brief:
Your client wants to better understand how people set and stick to their goals. They want you to focus your research on people who have set a goal in the past six months and have either followed it through or have not been able to complete the goal. The client expects you to deliver insights on how people set and stick to their goals, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand the way people keep up to date on the weather?

Project brief:
Your client wants to better understand how people stay up-to-date with the weather. They want you to focus your research on people who currently use weather apps, or listen to the weather channel. The client expects you to deliver insights on how people stay up-to-date with the weather, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand how to make women feel safe when traveling alone?

Project brief:
Your client wants to better understand how women currently travel alone, and the concerns they have. They want you to focus your research on women who have traveled alone at least once in the past six months. The client expects you to deliver insights on women traveling alone, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand how people order food takeaway online?

Project brief:
Your client wants to better understand how people order food takeaway online. They want you to focus your research on people who have ordered food online at least three times in the past month. The client expects you to deliver insights on online food ordering, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand how people decide and plan to move?

Project brief:
Your client wants to better understand how people decide to and plan to move. They want you to focus your research on people who have moved to a new house or apartment in the past six months. The client expects you to deliver insights about moving, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand how to reduce homelessness in major cities?

Project brief:
Your client wants to better understand how to reduce homelessness in major cities. They want you to focus your research on major cities that are dealing with a homelessness crisis (ex: NYC, LA, SF). The client expects you to deliver insights about how to reduce homelessness, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand how people find and keep roommates?

Project brief:
Your client wants to better understand how people find and keep roommates. They want you to focus your research on either someone who has just found a new roommate, or people who have been roommates for more than one year. The client expects you to deliver insights about how people find and keep roommates, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand how people recycle?

Project brief:
Your client wants to better understand how people choose and understand recycling. They want you to focus your research on either people who have recycled consistently over the past six months or people who have tried recycling and gave up. The client expects you to deliver insights about how people choose and understand recycling, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand how people buy clothes online?

Project brief:
Your client wants to better understand how people choose and buy clothes online. They want you to focus your research on people who have bought clothes online at least five times over the past six months and have returned at least three items. The client expects you to deliver insights about how people buy clothes online, in order to help them to start designing a relevant solution.

---

Problem statement
How can we better understand how people respond to and gather information about a pandemic? (COVID-19 bonus!)

Project brief:
Your client wants to better understand how people respond to a pandemic. They want you to focus your research on people who have lived through a pandemic and have experienced a lockdown/quarantine during that pandemic. The client expects you to deliver insights about how people respond to and gather information about a pandemic, in order to help them to start designing a relevant solution.

Resources

• 100 Example UX Problems by Jon Crabb
• 100 Days of Product Design by Susan Rits Design LLC
• Designercize by Mezzotent
• WeWork Interview Exercises

---

If you are interested, check out more free content and my offerings on www.userresearchacademy.com and join our slack channel

Recommended resources for User Researchers

February 2021

Source

I get asked quite often about any resources I can recommend for someone new to, or even seasoned, in the field of user research. Since I have found myself writing the same recommendations constantly, I decided to compile these into a list, which I will come back to and update!

Last updated, February 2021

Podcasts:

Since I have a dog, I spend a lot of time listening to podcasts while we go on long walks through Berlin. During this time, I love to listen to podcasts about user research. Not all of them allow me to come away with tangible action items, but they allow me to understand a different or new perspective. I love hearing about different ideas or challenges other researchers have faced. Here are my favorites:

• The Conversation Factory (my new favorite)
  A fantastic podcast, hosted by Daniel Stillman, where he explores the edges of Conversation Design: the application of Human-Centered Design principles and Experience design to human discourse.
• Dollars to Donuts
  A wonderful podcast, hosted by Steve Portigal, where he talks with people who lead user research in their organization about all things user research.
• Mixed Methods 
  A thought-provoking podcast, hosted by Aryel Cianflone, interested in the hows and whys of user experience research. Through interviews with industry experts and hands-on trial and error, they indulge and celebrate curiosity.
• Awkward Silences 
  A podcast, by User Interviews, where they interview the people who interview people. Listen as they geek out on all things UX research, qualitative data, and the craft of understanding people to build better products and businesses. Hosted by Erin May and JH Forster, VPs of growth/marketing and product at User Interviews.
• Aurelius 
  By Aurelius labs, and hosted by Zack Naylor, a podcast that talks to industry experts, discussing design and product strategy. Hear from leaders how they are solving the right problems and building products and features that matter most.

Slack channels:

There is nothing I love more than seeing a community of UX’ers helping each other. I truly believe a community is one of the best things for a field, and there are several amazing slack groups growing. I highly recommend joining these communities, as they are some of the best support out there.

• Mixed Methods 
  A great community for all things UX, both research and design. Join the growing community to post questions and help others in the field.
• ResearchOps
  A global community who’ve come together to discuss the operations and operationalization of user research and design research — also known as ResearchOps. ResearchOps includes the people, mechanisms, and strategies that set research in motion.
• User Research Academy
  A bit of a shameless plug here, since this is a slack channel I am growing. A community to be a support system, a go-to place for user researchers to find advice, and a community for an engaging discussion on important user research topics
• Ethnography Hangout
  A global community created for conversations about ​ethnographic methods. This is an interdisciplinary group wearing many hats from design to tech and research, so you don’t need to have any formal background in ethnography to participate.

Books:

There are some basic books I always recommend for people to read, which have a wealth of information about user research. Although these are more static than articles and podcasts, they serve as wonderful foundations and building blocks. When I get stuck on a problem, I still go over to my bookcase to pull out these books. These books include information on, both, qualitative and quantitative user research methodologies.

• Research Practice: Perspectives from UX Researchers in a Changing Field by Gregg Bernstein (I am a contributing author!)
• A Practical Guide to Measuring Usability by Jeff Sauro (one of my favorites)
• Just Enough Research by Erika Hall
• Think Like a UX Researcher: How to Observe Users, Influence Design, and Shape Business Strategy by David Travis
• Observing the User Experience (2nd Edition): A Practitioner’s Guide to User Research by Elizabeth Goodman, Mike Kuniavsky, and Andrea Moed
• Interviewing Users: How to Uncover Compelling Insights by Steve Portigal
• Mental Models: Aligning Design Strategy with Human Behavior by Indi Young
• UX Research: Practical Techniques for Designing Better Products by Brad Nunnally and David Farkas
• Measuring the User Experience (2nd Edition): Collecting, Analyzing and Presenting Usability Metrics by William Albert and Thomas Tullis
• Handbook of Usability Testing: How to Plan, Design and Conduct Effective Tests by Jeffrey Rubin
• Practical Empathy by Indi Young
• Quantifying the User Experience: Practical Statistics for User Research by Jeff Sauros

Blogs/Resources:

I am often scouring the internet for information on user research. After all, searching the internet is how we learn now. I love reading about different perspectives and thoughts on user research through people’s words. Instead of finding particular articles, I wanted to recommend the websites I reference the most.

• Neilsen Norman Group
  One of the top websites for all things UX and a great place to find relevant information. One of the articles I send around the most from NN group is their article on only needing to usability test with five users
• UX Collective
  My go-to when searching for UX articles on Medium. They have a great selection of UX articles written by people in the field. What I love most about these pieces is that they are written by people who are experiencing the problems in real-time, and can give tangible advice/examples on how to handle them
• dscout People Nerds
  dscout is constantly putting out relevant information into the world of UX, and they touch upon many important topics, such as accessibility and repositories. They take real-world problems researchers are facing, at a global level, and provide content to help them overcome these hurdles. PS: I write for dscout, but find them extremely relevant regardless :)
• Usability.gov
  A bit old school, but a really comprehensive website all about usability and improving user experience. They have guides, templates, and documents to help you with better understanding, and testing, usability.
• User Research Academy
  Another shameless plug. I founded User Research Academy back in 2019 to help people get into the field of user research. I offer courses and mentorship in user research.

Facebook:

I only have one recommendation for Facebook, but it is such a wonderful community, so I wanted to make sure it got proper recognition.

• User Research Collective

I hope you find these helpful! As I mentioned, I will be coming back to add and update these!

---

If you liked this article, you might also be interested in:

• Which UX Research methodology should you use? [chart included]
• 5 ways to reframe a solution to a problem statement
• How to Break into User Research
• Assessing your user research career level, seniority, and path

5 Steps for Setting Up In-depth Interviews

In-depth interviews are gold. This user research method allows us to genuinely understand who our customers are and what they experience in their everyday lives. It’s a style of interviewing that goes beyond the customer’s interaction with our product. Of course, we still want to know how a product or service impacts them. However, understanding our customers as real people, with lives outside of our product, should affect the way we build our product or service.

How do you set up these research interviews?

Here are 5 steps to get started:

1. Define your problem statement. This is the central statement the research seeks to understand. It is WHAT you will be studying.

Example: Choosing a software product is a very complex process; we seek to deeply understand how people make these decisions.

2. Define your research objectives. They should address HOW you are going to study the problem statement. Do this by breaking the research problem down into several objectives:

Ask yourself: “What am I trying to learn?” and “What must the research achieve?”

Example objectives:

• Understand the end-to-end process of how participants are currently making decisions on choosing a software product.
• Uncover the different tools participants use to make software product decisions.
• Identify any problems or barriers they encounter when trying to make decisions on software products.
• Learn about any improvements participants might make to their current decision-making process.

Identify what stage of the idea is being researched:

• A concept or idea: You need to understand the process people are currently going through (generative research)
• A prototype: You need to uncover what people think about the prototype and how they expect to use it (generative + usability testing)
• Live code: You need to evaluate the performance of the product and what people think about it (usability testing)

3. Target the correct participants for the study. Before you start recruiting, you have to understand who your users are so you can optimize recruiting efforts. Talking to the right people is a fundamental part of effective research. What are some ways to do this?

• If you haven’t already established personas or a target audience, take a day to define your target user. Do they work in marketing, sales, customer support? Probe internal stakeholders for key insights and come up with proto-personas.
• Scope your competitors, and recruit based on their audiences. Bonus: You can even recruit people who use the competitor’s product, and during the interview, ask them how they would make it better.

4. Write a research plan. Research plans contain all of the necessary information about the research project. Use it as a kick-off document to distill core goals and align the whole team.

5. Align the team. Once you have finished the research plan — or even before — sit down with the team to discuss the research problem and objectives. By doing this, the whole team can brainstorm questions they would like answered or concepts they would like to understand better through the research.

With these five steps, you should be able to start generating critical insights from discovery research!

Why you should always aim for open-ended conversations

It isn’t all about asking questions.

Source

The always in the title might be a little bit of a lie and slightly misleading. I must admit, not every conversation I have is open-ended. There are times when I am human (other times, I am a robot) and ask a yes or no question, or even a leading question. However, I do my best to have the most open-ended conversations as often as my brain can keep up with my mouth.

Open-ended conversations are the magic of user research interviews. They allow you to understand users’ mental models and dig into the lives of your customers.

Discovering how and why users think a particular way is key to delivering great insights to your teams. With just a list of basic interview questions, it is nearly impossible to uncover the mind of the person sitting next to you.

There is one particular framework I use to ensure I do this as much as possible. Unfortunately, I can’t remember exactly where I learned this from (it was years ago), but if anyone recognizes it, please tell me.

The TEDW Framework

I have used this framework since I can remember, and it has helped me become a better researcher. With this, I spend less time thinking about what to say next. Additionally, the TEDW framework means I am not always asking, “why, why, why” repeatedly, but I am still able to dig deeper into what the user is saying.

Another reason I love this framework is that it turns interviews into conversations and storytelling. What you want and need from users is to have them recall specific memories and tell you stories about those previous experiences. The TEDW framework enables you to get into this mindset. It takes the pressure off of the researcher and the interviewee.

Another cool thing is that the TEDW framework is not about asking questions, but about having open-ended conversations. Instead of asking people direct questions, you are using active listening and open-ended statements to extract the stories from them. Using this technique makes it a lot easier for participants to give you reliable past data, as it reduces biases that come through in research.

TEDW framework

Some examples

To demonstrate this further, here are some ways I would reframe questions into the TEDW format. Since Netflix is such a famous app/service people use, I will use this as an example:

• Original question: “When was a time you Netflix?”
• TEDW question: “Tell me about the last time you watched Netflix.”
• Why I rewrote this: If you start with a question like “when was the last time…” you are not prompting the user to tell us any stories. You are asking a specific question. Let’s start broad, and then you can use the “what, when, where, how, why” to dig deeper into setting the scene.
• Original question: “Were you doing other things while watching Netflix?” -> follow-up: “Why were you shopping online while you were watching Netflix?”
• TEDW question: “Describe what else you were doing while watching Netflix.”
• Why I rewrote this: The original question is direct and a technique I will sometimes fall into. The person might not know why they were shopping online while watching Netflix, but it is more important to know first what they were doing and to have the participant set the scene. Then, if you are a team that is trying to understand the way people go in and out of a show, you can dig deeper into that area. You might not get as reliable of data if you are asking these direct questions.
• Original question: “Why were you feeling frustrated with Netflix when you couldn’t log in?”
• TEDW question: “Explain what you mean by frustrated.”
• Why I rewrote this: There are two reasons to rewrite this question:

1. You have to understand what that person means by frustrated. People often have different perceptions of what emotions mean, and it is essential to understand that from a user’s perspective, not from your assumed mental model of the feeling. My frustration might be your anger or sadness.
2. Again, this is a direct question. The participant might not know why she was frustrated. If you leave it more open-ended, she will end up recalling the scene, which gives you ample opportunities to dig deeper into what is most important to the participant. And, you should care about what the participant cares about.

• Original question: “What made you turn on Netflix last time?”
• TEDW question: “Walk me through the last time you started watching Netflix.”
• Why I rewrote it: Again, you are getting at a story with the TEDW format. You are asking them to recall a memory of what was happening, instead of asking them to answer a specific question on what made them turn it on. With the context of the story, then you can drill down into subjects such as, “what were you feeling?” “When was this?” “Describe the scene for me.” You want to focus on the story the participant is telling you, not the answer to a question.

Using this framework doesn’t mean that you never drill down and use questions like, “why did this happen,” or “when were you doing this?” Instead, TEDW is a way to start conversations, and a way to begin the storytelling process. Once the participant starts giving you nuggets of the story, you can dig deeper into the critical parts based on our research goals.

Give it a try and tell me how it goes!

Want to share with others? Feel free to use this condensed slide deck.

---

Interested in more user research? I teach an Introduction to User Research Course and am available for one-on-one mentoring. Check out the User Research Academy. Please join the User Research Academy Slack Community for more updates, postings, and Q&A sessions.

5 ways to reframe a solution to a problem statement

And why this is essential for user research.

Source

Very rarely do I get handed a problem statement. Whenever colleagues want to engage with me in a research project, they have already landed at a solution. I am not saying this is bad because solutions are a comfortable place to start. They are easy. However, they limit our potential and possibilities. I’ll give an example of something I hear frequently:

“We want to build a share feature for our users so they can share their trip ideas or details to friends and family. Can you research this for me?”

I’m sure this statement resonates with many user researchers. It is a tough situation to be in, and one that happens far too often. If this is the type of statement you are consistently getting from colleagues, you have an excellent opportunity to teach a new mindset. You can teach the mentality of approaching ideas from the problem-space before solution-space.

Why is reframing the solution important?

I’m going to pick on Google, for once, because I believe Google has enough self-confidence to take a small hit. Let’s talk about Google Glass.

To be upfront, Google Glass was a failure. The product did not succeed in the slightest. There are several different reasons for the flop, but we will focus on one in particular: Google Glass did not solve a problem for users.

There were many assumptions made about Google Glass, which were not validated with users. The conjectures led to many questions and, ultimately, to a product that did not correlate with the user’s needs or goals. There was a lack of clarity on:

• Who would use Google Glass
• When/where people would use Google Glass
• Why people would use Google Glass
• What value Google Glass brought to people

These are a lot of essential questions that were left unanswered. With this approach, there is a substantial likelihood that products will fail. If there is no value to users, they won’t use it.

And the best way to determine value? Start with a problem, not with a solution.

By understanding the problem-space before coming up with a solution, we allow for:

• Understanding a user’s actual problem and need
• Brainstorming ideas that are relevant for users
• More possibilities to help with a particular problem
• A higher likelihood of a successful product/feature

The best way to understand the problem space is by conducting generative research sessions with users. Although I won’t cover generative research here, please take a look at my comprehensive guide to generative research.

Picking apart the solution

We’ve established how important it is to start with a problem rather than a solution. However, many times, we are faced with a solution, as in the first example. Let’s take a look at that again:

“We want to build a share feature for our users so they can share their trip ideas or details to friends and family.”

Let’s assume there has not been any user research done on this topic of “sharing.” There are a few things that are not ideal with this statement:

1. There is no clarity on what the problem is we are trying to solve
2. We jump directly into a solution
3. Users wanting to share their trip ideas or details is an assumption
4. Sharing might not be the only or best solution
5. Our thoughts should come from generative research

But, lets base this scenario in reality. We’ve received this solution and need to test it. We can go in one of two directions:

1. Usability or concept test the solution
2. Take a step back and consider the problem

I know the latter isn’t always possible, which is why I included the first option. Sometimes the idea/feature/product is too far down the production line, and we have to do damage control. The best we can do is usability test the solution to understand what we can improve in further iterations.

However, sometimes it isn’t too late, and we can take a step back and consider the problem. We can ask the question: “what problem is this solution trying to solve?”

Tools to reframe the solution -> problem statement

This kind of question may be much easier for researchers to think about since we are used to doing this daily. For our colleagues, it might not come as naturally. Luckily, there are a few different methods we can employ to help us reframe the solution.

‘How Might We’ (HMW) Statements
This method is very trendy in the UX world, and for a good reason. ‘How Might We’ statements allow us to reframe our insights and thoughts into a broader context. We use these types of statements because they can get us thinking about the problem from many different angles, and they open the door to creativity. They also ensure we are thinking about an actual user need versus just coming up with cool ideas. Let’s take the sharing example and recontextualize it with HMW statements:

HMW Examples

Investigative Stories
Investigative stories enable us to become detectives when thinking about a problem. With this method, you employ a journalist-type view of the situation. By looking into all of the different aspects of the problem, you can get a holistic picture of what you are trying to tackle. After you answer all of the questions, you can create a story of your user, which helps to understand the actual user need/problem.

Investigative Stories

Unpacking Assumptions
This is a technique I have been practicing and teaching for many years now. It is one of my favorites as it plays very well into my Buddhism practice. Before I begin thinking about solutions, I list all of the different assumptions I/we have about the user. It consists of everything you think you know. If we take the example above, the list might look like this:

• Users want to share trip details with friends and family
• Users are booking travel for a group of people
• Users need other’s opinions on their trip options/details
• Users find their current method of sharing details painful
• Users want a new way to share trip details with others

The Six Thinking Hats Model
Dr. Edward de Bono originally introduced the ‘Six Thinking Hats’ model. This method examines problems/concepts from many different viewpoints to get a holistic understanding. Getting colleagues to engage in this kind of exercise can be complicated, but also extremely rewarding. The thinking hats/roleplaying game gets people into the minds of users. Each person wears a hat:

1. White hat: Facts
   - What information do we have?
   - What hasn’t worked in the past?
   - What information is missing that we need?
   - What are the weaknesses?
2. Green hat: Creativity
   - What are the other angles we are missing?
   - What are the alternatives?
   - What are the next steps?
3. Yellow hat: Benefits
   - What are all the benefits of the different options?
   - What solutions would work?
   - What is the best-case scenario (for users and the business)?
4. Black hat: Risk
   - What are the different risks of each option?
   - What solutions would not work?
   - What is the worst-case scenario (for users and the business)?
5. Red hat: Feelings
   - How do the options make you feel (from the user’s perspective)?
   - What do you like about the options?
   - What don’t you like about the options?
6. Blue hat: Process
   - Where are we now?
   - What other work needs to be done?
   - What is the next step?

Research Plan Template
One of the most significant pieces of advice I can give is to create a template that prompts colleagues to think of the problem statement before they even come to you. An additional way I do this is by sending a research plan template for colleagues to fill out before we meet to discuss features. This template starts with the problem we are trying to tackle, rather than the solution. With this, you can start discussions from the problem-space. Check out my research plan template.

Writing the problem statement

Once you have done these exercises, you can write some problem statements. I mentioned the ‘How Might We’ formula above, but I also use some other problem statement formulas:

• I am (persona/role) trying to (do X) but (barrier/problem) because (x), which makes me feel (emotion)
• I am a mom trying to book a flight ticket home for my daughter, but I don’t know her college schedule, so I am unsure which dates to book for her, which makes me feel frustrated.
• I am (a persona/in a situation) who needs a way to (user need) because (current problem)
• I am traveling with a group of friends and need a way to coordinate everyone’s schedules so that I can pick the best date/time for everyone

Problem statement

You don’t have to use the exact formula (I deviated above), but it is an excellent framework to keep in mind. Try to avoid proposing solutions during this phase, as it is an easy trap to fall into. Keep your focus on the problem and facts.

Overall, getting people to shift from the solution-space to the problem-space is a considerable challenge, but one worth confronting. If you are continually urging others to think about the problem before the solution, they will start to adapt to that mindset. By instilling these practices, and with some time, you can transform the mindset of an organization to approach ideas from the problem-space. Not only does this make your life as a user researcher easier, but it also turns the company into a much more user-centric culture.

---

If you liked this article, you may also find these interesting:

• User Research isn’t black & white
• How to write a generative research interview guide
• Benefits of internal user research
• User research plans — with template

Interested in more user research? I teach an Introduction to User Research Course and am available for one-on-one mentoring. Check out the User Research Academy.

Please join the User Research Academy Slack Community for more updates, postings, and Q&A sessions

Should user researchers give feedback to teams?

Where does user research feedback start?

Source

The other day, I saw a bad prototype. It came up during a design critique. We were going to start user testing that very prototype the next day. I wrote down my notes and mentioned it to the designer.

The problems I saw were:

• Typos
• Simple design flaws (different colors for the same hierarchical information)
• Information that made no sense in the context

For me, these were easy things to fix. I wanted to give the designer this feedback for two reasons:

1. To make the design cleaner, and to encourage attention to detail
2. To ensure we were getting the right feedback from the users

The second reasoning behind this, for me, is more important. When I present a prototype to users, I would rather not spend the precious time we have with them confused about easily changed information. Or information that doesn’t matter in the test. It can be a big waste of time, and participants can get stuck on these small inconsistencies.

What happened in this case? Unfortunately, the designs didn’t get changed in time. We tested the older designs with the issues I mentioned. While we did get some great feedback on the user experience, there was some time wasted on those smaller inconsistencies. I had to explain them and wave them off as small mistakes that don’t matter. However, it made the interviewing experience seem less productive and prepared. Almost every user recognized the changes I had asked to be made.

Regardless, again, we still received great information from users, but it felt clunky to explain away the prototype. Now, I know prototypes are supposed to be far from perfect, but this felt beyond the usual prototype spiel I give.

So, my biggest question in this case: is it okay for the researcher to request the changes I did? Or is it on the researcher to perform the interview in a manner where these inconsistencies don’t matter to the user?

When should user researchers give feedback?

This particular case made me question when, and at what level, user researchers should give feedback to our teams. I generally give feedback during the following opportunities:

• During the idea/concept phase
• During the prototype phase
• After a design is completed
• Synthesis from research sessions

I’m not entirely sure if this list encompasses every opportunity, but it was my starting off point. I don’t want designers or other team members to think I am an expert in UI/UX (or any other field, for that matter) or that I am overstepping boundaries.

Here is how I give feedback at each of these steps:

• During the idea/concept phase. I do my best to ensure teams come to me with ideas very early on in the development process so we are able to test the viability of the idea with users. When they come to me with ideas, they are generally solutions, rather than problems. I ask them to come up with the problem they are trying to better understand and the questions they would ask during to find out more information. Some teams have come to me with a fully developed idea, which I knew would not stick with users, or solve any pain points. In this case, I was new to the company, so I was forced to test it with users. It proved the point that it is important to do some upfront user testing before we come with fully built solutions based on assumptions. Now, when people come to me with solutions, I request they go back to the drawing board and start with a user problem, and questions they would like to ask.
• During the prototype phase. This is similar to the example I gave above with the prototype. I try to get a look at all prototypes before we put them in front of users. I will have the designer walk me through each screen, and I will point out any small inconsistencies. This gives the designer a second pair of eyes on the designs and helps ensure the design and flow make sense. Prototypes can still be “messy,” as in low-fidelity, but they need to make sense. We don’t want to waste time having users comment on small things that are insignificant to the usability test.
• After a design is completed. This is where the whole feedback concept starts to get tricky for me. Once a design has completed user testing and is off into the wild world of being “live,” what do we do? Since it was already user-tested, do we have the right to give additional feedback? For this stage, I will wait a bit and then follow-up with any feedback we are receiving on the particular design (or feature). If the design did not go through user testing, I will test at this stage and do a heuristic evaluation to give some additional feedback to the designer.
• Synthesis from research sessions. And finally, synthesis. Maybe for some, this is the most straightforward but, for me, it can get complex. We all talk about how synthesis is one of the most important parts of the user research role, but rarely is it discussed in full. At this point, how I understand synthesis is as follows: we digest and analyze the research sessions, and then give “actionable recommendations” on what should come next. What does this mean? Are we telling people what to do? What are we recommending? This brings me to my next point…

At what level should we give feedback?

Since the first three opportunities for feedback are much more straightforward, I will focus on synthesis for this particular case. I have the following questions when it comes to giving feedback (specifically targeting synthesis):

• What should we be producing? Action items/recommendations?
• What are the action items/recommendations?
• How far should we go with action items/recommendations?

I truly believe user research isn’t about giving people answers, it is about giving people tools to better contextualize something. We aren’t meant to “tell people what to do.” So, with this in mind, what are we supposed to be writing in terms of recommendations?

When I tested the aforementioned solution (which was a huge feature), it was glaringly obvious our users would not find it helpful or useful. And they would not pay for it. There were a few aspects of it they liked, but, by in large, it wasn’t sticking with them. They simply were not interested, and would rather have the company work on other features or improvements.

When I received those results, I wasn’t entirely sure what to do. The solution was already half-way built, and the team had spent a good amount of time working on it. I decided to give my honest recommendation: stop working on this immediately and pivot to working on other, more impactful, areas. I gave some ideas on how we could change the idea to suit our users better, but it should not be a high priority. I was lucky to have enough people on my side to be met with little resistance.

However, when it comes to these tests, I always wonder what level we should give this feedback and these recommendations? I often state the recommendations as problems instead of solutions:

“User is unable to locate the “pay” button or move to the next step” versus “move the “pay” button to higher on the page or make it a bolder color.”

This still gives enough flexibility for someone to make a better decision, without me telling them exactly what to do. However, as I mentioned, I also made an honest recommendation of not continuing on with a product. I’m not entirely sure what the balance is, but I am sure there is one. But I would still love to know…

How do you give feedback as a user researcher?

---

If you liked this article, you may also find these interesting:

• Burnout as a User Researcher
• User Research Isn’t Black & White
• Benefits of Internal User Research
• How to Write a Generative Research Guide

If you are interested, please join the User Research Academy Slack Community for more updates, postings, and Q&A sessions :)

Assessing your user research career level, seniority, and path

Source

Career paths are extremely important topics to think about, especially in the context of a more niche field, such as user research. While there is some information online, it is primarily for the broader field of UX and much more focused on the UX design career path. Planning the next 1, 3, or 5 years of your career is never easy. But trying to do so without a lot of guidance or mentorship can be even more difficult.

The reason I know this is because I have recently been trying to figure out what my next step is, and have also failed to plan effectively in the past. This lack of planning has led to confusing and less than ideal roles and situations. Knowing what your current level is, and where you want to go with your user research career, really helps you make sure you are in the best role for growth.

User research career levels

There are a few different levels of user research, and (fortunately) they generally follow the same kind of trajectory as other careers. I have also put a general amount of years of experience but this, of course, can vary. I have seen people in certain roles with much less, or more, experience than is generally “recommended.” I believe an employee’s skillsets and level of maturity are far more important in determining a career level than the number of years someone has been in the field.

I have also measured these against the following areas of impact a researcher could have on a company level:

• Operational: Deals with the day-to-day function of user research
• Organizational: Handles how the company understands and ingests user research
• Strategic: Aids the company in making strategic decisions based on user research

User researcher levels

• Research coordinator: Supports the product team throughout the research life cycle, including scheduling, recruiting efforts, participant communication, streamlining research operations and team communications
• Junior user researcher: Embedded in a team to carry out user research activities. They have some practical experience but need regular guidance and training to produce their best work and develop their skills. They generally work in combination with a more senior user researcher
• Mid-level user researcher: Embedded in a team and responsible for planning and carrying out user research activities. They are able to work independently on a team, without too much guidance
• Senior user researcher: Able to plan and lead user research activities in larger teams and on more complex services. They build user-centered practices in new teams and align user research activities with wider plans to inform service proposition. They may supervise and develop other user researchers to assure and improve research practice
• Lead user researcher: Leading and aligning user research activities across several teams. They ensure that teams take a user-centered, evidence-based approach to service design and delivery. They develop and assure good user research practices
• Head of user research: Leads user researchers in an organization and attracts and builds talent. They are an expert practitioner who can define and assure best practice, influence organizational strategy, and priorities, and collaborate with colleagues across a company.

Download this sheet here

Different career paths

There are two main career paths for user researchers, and they are similar to those of other industries. In general, you can go one of two paths:

• The individual contributor
• The manager

The biggest question I would ask when determining one of these two paths is to understand: “do I want to help others develop the skills I have?” or “do I want to continue to hone my skills as a research practitioner?”

As a manager, of course, you may still be able to engage in the more tactical side of the job (ex: actually conducting research), but usually, you operate as a people manager, mentor, and strategic partner. As an individual contributor, you will most likely be able to contribute at an operational, organizational, and strategic level. The biggest difference here is whether or not you are mentoring and managing others.

If you feel okay stepping away from the day-to-day and are looking to mentor others in the field, management might be your best bet. If you want to become a super expert in your field, I would stick with being an individual contributor. Of course, the best way is to simply try. As of right now, I have been a senior-level individual contributor and have finally decided to make the leap to management. Let’s see :)

How to assess your level

Now, these descriptions and charts are all generic. They have to be. There is no one description that will be perfect for all. Many user researchers have unique paths and experiences, so it is hard to make generalizations. However, for the purpose of this article, I do my best to help you categorize and see where you can grow.

Here are the steps I take when assessing my level:

1. Audit my own skills. I always start by listing out all of my skills and my level of confidence in these skills (“low, medium, high” is totally fine). I also list the skills I would really like to learn next, that I find important for moving to the next level
2. Look at the skills in the different levels. I then look through the skills in the level I think I am, and then the levels directly below/above. I also stalk people on LinkedIn at the level I think I am, and the surrounding levels. I see what their experience and skill sets are, and then compare that to mine. I also do a lot of networking and talking to researchers at all levels to get a more concrete idea. Actually talking to other researchers is the best way to do this!
3. Consider my past experience. As I mentioned before, skills are one thing and experience is another. I always consider my past experiences, roles, and responsibilities. For example, when I was starting out, I was a UX Research intern but was expected to operate as a more junior/mid-level. With this, I was able to gather different skills and experiences that pushed me almost straight from Intern to mid-level. It is important to take this into consideration.
4. Think about my level of maturity. This is especially important when you start to get into the senior/lead positions in the field. It is extremely important that you strongly consider how mature you are as an individual. More and more people will be depending on you on a consistent basis, and you will have much more pressure and feedback coming your way. It is okay if you have not yet had the training to best handle these situations, but they are very critical to consider when you move into these roles. You will also have a level of responsibility for others if you choose the management track

I recommend doing this at least twice a year, as it will give you a better understanding of where you are currently and where you can go in the future. Not only is this great practice to do for yourself but, if you are looking to go towards the managerial track, it will be great practice for your future reports!

What is another aspect of your career that is great to assess regularly? Defining your user research philosophy!

---

If you liked this article, you may also find these interesting:

• How to Assess Your User Research Interviews
• How to Break Into User Research
• A Week in the Life of a User Researcher
• How to Write a Generative Research Guide

If you are interested, please join the User Research Academy Slack Community for more updates, postings, and Q&A sessions :)