How to run a research session if you’re not a design researcher
How one UX writer took research into her own hands
by Andrea Drugay and Mira Rao
A few months ago, our Internal Communications team at Dropbox was getting ready to launch a new intranet for employees. As a UX writer, I worked closely with them to make sure the user experience (UX) copy was clear and that the navigation felt effortless.
But we knew we had to do some user research before launching it. Design research is the heart of UX, and it’s a philosophy upon which Dropbox Design is built. We wanted to be sure we were applying our design principles and best practices to internal tools as well as to the external Dropbox product.
The information in the new intranet was highly confidential, which meant we were somewhat limited in our research scope. We needed real insights from real Dropbox employees; remote testing with people who didn’t work for Dropbox wasn’t a viable option.
A new approach
I suggested we run a research session based on a style our Design Research team uses. With the help of Senior Design Researcher Paige Bennett, we pulled together a 2-hour session that I facilitated. We were able to gain insights quickly and put suggestions to use right away. And it was extra-exciting to me, because as a writer, I don’t usually run research sessions. I learned a lot about facilitating research, and I’m excited to do more in the future.
Whether you’re looking to learn from internal or external people, the process is the same. Here, I’ll walk you through it, so you can do something similar — no matter who you are or what your day-to-day role is.
The problem: You need research, but you’re not a researcher
If you’re at a company or on a team where you get to work directly with design researchers, consider yourself lucky. You already know the benefits of having research insights at your fingertips. You can work closely with your research partner to create a better experience in your product.
But not every team is lucky enough to have a dedicated researcher, and not every company has the resources to staff a Design Research team. Sometimes user testing is up to the designers, writers, marketers, or anyone who can squeeze it in.
Fortunately, there are plenty of options for basic, online user testing, like UserTesting.com and UsabilityHub.com. But the insights gained from unmoderated or remote testing can sometimes be limited.
For one thing, designers and writers sometimes get concerned that their prototype isn’t polished enough to test. It’s easier to explain a rough concept in person. Also, you can ask follow-up questions more easily in a moderated session than you can during a remote or unmoderated test. Sometimes, only live user testing will do.
The solution: We call it Real World Wednesdays
Real World Wednesdays (RWW) is a rapid, speed-dating style research session. You can do it with internal employees, external people, or both. It’s a great way to test mocks, works-in-progress, and half-baked concepts with users. Plus, it saves time, and it’s a fun way to get real, live, valuable, high-quality feedback.
John Saito mentioned it briefly in his blog post, How to stay scrappy. I’ll walk you through how to do it in more detail, so you can create your own live, in-person user testing with real humans.
From Paper to the real world
Real World Wednesday developed from a speed-dating concept proposed by Aruna Balakrishnan, Design Research Manager at Dropbox. The idea was fleshed-out and introduced to the team by Mira Rao, Senior Design Researcher, and Leona Dondi, Design Researcher, on the Dropbox Paper team. The designers and researchers on Paper wanted a way to quickly and iteratively test mocks, so they started doing fast, lightweight research sessions every other Wednesday. Our Design team practices No Meeting Wednesdays, and a lot of us have found we can use the unstructured time in creative ways.
“Real World” meant they’d be getting feedback from real people. They’d also be getting feedback earlier and often, since sessions ran bi-weekly. It was frequent, scrappy, and sometimes kind of messy. It turned out to be a great way to check in with users and let real people be part of the design process.
Once RWW proved its success with the Paper team, they started hearing from other teams who wanted to do something similar. So the sessions expanded, other teams joined, and more people started participating. Some of our teams in other cities even created their own versions, with unique twists that suit their needs.
How does it work?
We usually compare it to speed dating or speed networking. For an hour and a half, five participants give feedback to five different research groups. You can adjust the numbers to suit your own research style, but we’ve found five gives us diverse feedback with a manageable number of participants.
We gather in one of our collaborative spaces (a giant, open meeting room) and sit at five tables. There’s one participant (the “user”) and two “researchers” at each table. Each user talks with a pair of researchers for 15 minutes, then they move on to the next table. We repeat this four more times to fill out the hour and a half.
After we’ve thanked the users and they go home, we debrief with the other researchers. Afterward, we synthesize their input with our product teams and iterate on our projects.
So that’s a total of five “users,” 10 “researchers,” and one or more facilitators. The setup looks something like this:
What kind of things can you test?
Because these are scrappy, short research sessions, they’re best suited for things that don’t require a high degree of confidence. For instance, it’s a great way to get iterative feedback, but not the right place to make important product decisions. Here are a few examples of great candidates for RWW-style testing:
- Usability testing
- Feature and flow comprehension: Do users understand what this does?
- Discoverability and flagging user questions or concerns
- Language and copy feedback
- Onboarding flows
When we tested the intranet, we focused on the information architecture and language. The researchers were all testing the same project, but since we were looking for different insights, we used different research approaches. For example, one table did a card sorting exercise for the structure, while another did a highlighter test for the language.
You don’t need to have anything polished or finished to put something in front of users. In fact, the earlier in the process you can get feedback, the better. You can test anything from hand-drawn sketches to printed-out mocks, or fully built experiments that users can play around with.
Do I have to do it exactly this way?
Not at all. The setup I just outlined is a basic framework for Real World Wednesday. There are a lot of variables in a research project, which means you can adjust things to suit your needs. For example, you could:
- Have fewer or greater numbers of participants, or researchers, or both. For instance, you could have pairs of participants or even trios. Some people refer to these as “micro-focus groups.”
- Use a longer format, like 30 minutes instead of 15.
- Try a remote session. Set up five conference rooms, each dialed in to a scheduled video call with a different participant. The researchers swap rooms every 15 minutes. The participant stays dialed in but who they’re talking with changes.
Why do a Real World Wednesday research session?
- It’s an easy way to get great feedback from real people. You can get outside your bubble and get high-quality feedback right away.
- It saves time. Through rapid testing, you don’t have to sit in research sessions all day.
- Anyone can participate in or run a session. Anyone! Designers, PMs, engineers, researchers, UX writers, and more.
- It de-mystifies research. The conversations are only 15 minutes, so even if it’s a bad conversation, it’s over quickly. The short, lightweight style makes research a lot less scary, and it gives you a lot of practice in a short amount of time.
- It builds confidence. It’s a great way to get practice talking with people and becoming more comfortable with it.
- It’s fun. Really! As you build confidence talking with people this way, and as research itself becomes less intimidating, it can be fun to learn about other people, their daily lives, and how they interact with the world.
The important thing to remember is this is a framework, not a must-do. As Senior User Researcher Christopher Nash says, “Real World Wednesdays is one solution, not the only solution.” It can be a great jumping-off point to more in-depth testing, and a great way to get experience if you’ve never done research before.
How to do it, step by step
Before anything else
Determine who your participants should be
Recruiting participants is often the thing that takes the most time. If you want to find out your customers’ needs, you’ll need to put some time into figuring out who those people are. When testing the intranet, we had a built-in audience, which made finding participants easy.
“But if you’re doing this in the real world,” says Nash, “you’ll want research participants who can identify with the problem your product is solving. … For example, you wouldn’t want to test your concepts for a design tool with people who aren’t designers.”
You’ll want an audience that’s going to have enough context that they can identify with what each of the research duos will be showing them.
Send out a call for participants
Once you’ve determined who the right people are, then think about ways to connect with them. You might need to get creative. Try your friends and family networks, social media, Craigslist, professional forums, Slack communities, conventions, meetups — or anywhere else your potential audience might hang out, either in person or online.
Consider offering participants an incentive for their time, like a gift card or pizza. We brought fresh doughnuts to employees when we tested the intranet — a treat we don’t usually have in the office — because we were testing first thing in the morning. Coffee and doughnuts helped get everyone off to an energetic start.
The week before
You’ll want to do some prep work before running a Real World Wednesday. The week before your session, here are things you’ll want to do.
Find a space
Secure a good space where you can conduct the sessions. If you don’t have an open-space collaborative area, try a large conference room, or even a cafeteria. You’ll meet in groups of 3, so make sure you have separate areas where different people can gather.
Plan for 2 hours of research time
Each session is 15 minutes, and you’ll have a few minutes in between sessions to rotate. With introductions at the beginning and thank-yous at the end, the whole thing takes about 2 hours.
Send out a call for researchers and buddies
Let your team know you’re going to be running a research session, and find out if people have projects they’d like to test. There are two people per “research team.” One person is the “researcher” who asks the questions and guides the participant; the other is a “buddy” who helps take notes.
Ask your research duos to decide what types of tests to give
The fun part is that you can run several different tests at the same time: each research duo can run a different type. For the intranet research, we did two tests: a highlighter test and card sorting. But there are many other types of tests you can run, depending on where you are in the development process and the insights you’re hoping to gain.
Create a sign-up sheet
Have each researcher duo sign up for a slot and note the type of test they’re going to be conducting. Here’s an example of a sign-up sheet created in Dropbox Paper:
Have your research duos list out the questions they want to ask
Some people call this a “discussion guide,” but it doesn’t have to be overly detailed. It’s a list of questions and topics to cover with each user, that you can refer to during the testing. You can write out the questions, or create an outline of topics. Decide the kind of feedback you want to get, and the questions you want to ask. Writing a discussion guide is also an excellent way to prepare a brief explanation of the project.
Day-of prep
Set up the room
Get to the space early so you can set things up. You’ll want to have the following on hand:
- Name tags
- A timer (or a charged phone or tablet with a timer app)
- Table numbers
- Highlighters and pens
- Sticky notes
- Incentives (gift cards, pizza, whatever you like)
- Business cards to hand out after for follow-up questions
Before participants arrive
- Give your researchers and buddies an overview of the game plan.
- Make sure your researchers and buddies have multiple printed copies of their prototype, mocks, wireframes, copy doc, or whatever it is they’re testing.
- Hand out name tags.
Testing time
Before the testing starts
Introduce yourself and your researchers and buddies to the participants and thank them for coming. Give them a quick overview of the sessions.
- Each session is 15 minutes.
- The facilitator will give a 3-minute warning at 12 minutes.
- At 15 minutes, it’s time to rotate. The participants move to the next table, while researches and buddies stay where they are. Allow a couple of minutes for everyone to rotate.
- The facilitator announces when the next 15-minute round starts.
Remind the participants they don’t need to have specialized knowledge for anything they see. If they need context, the researchers will provide it. It’s also helpful to make sure participants know that honest feedback is the most useful, and that there are no right or wrong answers.
After the testing
- Thank your participants. Hand out your incentives and business cards, and walk them out.
- Debrief with your research duos on how the session went.
- Did they get helpful feedback?
- Were there any surprises?
- Do they know what to do now?
Tips for testing
For people who aren’t used to conducting research sessions — or facilitating them — there are a few things to keep in mind. Interviewing people can be intimidating, but with 15-minute sessions, you’ll get a lot of rapid practice. Remember to always ask permission before recording anything, and try to listen way more than you talk. Here are a few other tips:
Make sure each researcher has a note-taking buddy
Don’t try to conduct the interview and take notes at the same time. The team can switch up roles in between participants, so each one gets a chance moderating and taking notes. Set up a note-taking doc ahead of time. You can copy your discussion guide, and adapt it to make note-taking easier.
Capture what the users say, not what you think they mean
Try to record what people say in their own words. If you’re testing a prototype, try to capture what they do: “Clicked Submit” or “Dismissed dialog without reading.” You’ll have time to analyze and make sense of it all later. Quoting a user word-for-word can be a persuasive element of research.
Treat your users like experts
You’ve invited people to give you their thoughts, so take the time to listen to them well. Starting on a warm and welcoming note helps a lot. Be polite and friendly. Don’t interrupt them or put words in their mouth. Their insight is invaluable, so treat them like experts and don’t correct them.
Use regular language
Sometimes we get stuck in a bubble when talking with people at work, where we know the internal projects and processes well and don’t have to describe them. There can be things we don’t think of as exclusive but that are jargon, like design sprint or copy doc. Use clear, plain language, especially when referring to projects, processes, or products that people might not be familiar with.
Use silence as a tool
As Design Researcher Marian Oman says, “This can feel awkward at first, but be patient. Wait for participants to answer, and don’t rush to the next question.” If they end up on a long tangent while talking, you can guide them back to something you’re hoping to get feedback on: “What do you think about this section over here?”
Use “Why?” and don’t assume anything
Try to understand the reasoning behind their thoughts. Ask them to explain their reasons. Don’t assume you know what they’re going to say, and don’t assume you know what they “really” mean. Ask “stupid” questions, and ask for examples if you need to. Marian suggests saying, “I think I understand, but can you tell me more about why that’s important to you?”
Avoid leading questions
Leading questions are those that influence the user to give a single answer. Try to keep things as open-ended as possible. Instead of, “Was it easy to find the support you needed in the help center?” say, “Tell me about how you reached the help center.”
Rotate the order of your different versions
If you’re having users compare different versions of the same thing, mix up the order in which you show them. So User 1 sees Copy Table A, then Copy Table B. User 2 sees Copy Table B, then Copy Table A.
Do an immediate debrief
After you’ve run through all of the sessions, regroup with your research duos. Ask if they got the information they needed, if there were any surprises, and if they know what to do next. “It can be short, if needed,” says Paige, “but it’s necessary for capturing things while they’re still fresh.”
Now, you try it!
Research doesn’t need to be scary, intimidating, or something you can’t do just because you’re not a design researcher. With some forethought and logistical planning, anyone can run a research session.
I hope this post inspires you to create new ways to learn from your potential users and customers. If you have suggestions or tips of your own, please comment and let us know.
Huge thanks to Mira Rao for her words and insights and the Dropbox Design Research team for their advice and guidance, especially Christopher Nash, Paige Bennett, Marian Oman, and Aruna Balakrishnan. Big thank-you to Fanny Luor for the wonderful illustration!
Want more from the Dropbox Design team? Follow our publication, Twitter, and Dribbble. Want to make magic together? We’re hiring!
