Skip to main content
Join the Agentforce Hackathon on Nov. 18-19 to compete for a $20,000 Grand Prize. Sign up now. Terms apply.

Define Your Research Plan

Learning Objectives

After completing this module, you’ll be able to:

  • Determine the problem you want to study.
  • Choose an appropriate research method.
  • Use an approach document as a guide and a historical document for the future.

Why User Experience (UX) Research Matters

image of researcher with magnifying glass and images around them

Chances are you’ve heard people hem and haw about their experiences with technology. Do any of these sound familiar?

  • I can’t stand that it is so hard to use!
  • I just don’t understand who they built this for?
  • Wow! I had no idea it did that.
  • I never would have figured that out on my own.

And this is just folks talking about setting the timer on their microwave. But there’s a way to build technology to avoid most of these issues: Get to know your user.

The thing is, when we build cool things—like invisible planes, websites, or even a brand-new page layout in Salesforce (the most cool of all!)—we have a habit of building them for our own needs. We assume that our needs are the same as our users’ needs, that they like what we like, that they get excited about creating workflow rules just like us!

It would make things so easy if your users’ needs were the same as yours (albeit a little weird). Building new products or features would be a breeze—just build something you like and magically all your users would love it too.

The truth is, your user is not you. Their needs are different from yours.

So how do you figure out what’s important to your users? How do they use your product or service, and how might they like the next big thing you’re building?

Enter your new best friend: user experience (UX) research.

What Is UX Research?

UX research is a set of tools and methods that help you understand your users and their needs when using your products or services. It combines the structure of project planning with the rigor of research, all the while building a case to improve your product, service, or feature. It helps you uncover who your users are, what’s important to them, and how they work. Answering these questions will help you build a better product or service.

UX research work can be tough. But if you imagine your users as the hero and you as their benevolent benefactor, you can help them create an experience that reduces work for them and eases their journey. And the best part about it all, they will thank you for it!

So now that you know why UX research is helpful and how it can work for you, let’s dig into how you can do it yourself.

Note: We aren’t trying to turn you into a professional user researcher. But by the end of this module, you will be able to build and execute a basic research study.

Let’s take the first step—build your research plan.

One Step for You … One Giant Leap for Your Users

Most projects need some kind of planning document to guide the project, and user research is no exception. This is where a research plan comes in. In this doc you’ll define the problem you’re researching, figure out which users to study, set a timeline, and determine the approximate length for your research activity. Whew!

As the lead on this research project, this document will help you keep your project details in one place. It also acts as a contract with your UX research team members where all your stakeholders can agree on and keep track of the key pieces of your study.

Your research plan will include:

  • Project scope (includes the problem you’re studying and any results of prior related research)
  • Project timeline
  • Participant recruitment list
  • Project research methods

Let’s check them out…

Understand the Research Problem

To help you understand the UX research process, we’ll be following Carla, a member of the Sales Ops team, as she embarks on the first step in her UX discovery journey. She’s seen a dramatic decrease in usage of her company’s core sales application, and she wants to know why. With this clear problem statement she’ll help her team members build a better experience for her users.

Carla does her due diligence, and instead of just jumping into a project head first, she checks to see if anyone has researched this problem before. The results of this, and general product research, are extremely helpful for deciding who to interview and which questions to ask. Carla loops in the folks who might be most immediately impacted by this project—we’ll call them our audience (more about identifying your audience in unit 5). From them, Carla learns the information that’s already been collected about the issue.

Carla is a super sleuth investigating the problem history. She looks for any place she can find concerns: bugs, support tickets, user or customer surveys, lists of feature requests, website logs with drop-off rates. You name it, Carla has dug into it and found some great morsels of data to use in framing her study.

Define a Timeline

Defining a Timeline

One of the most common challenges when creating a research plan and approach is time. Time to build your approach, time to engage your audience, time to recruit your users, the duration of time for your interviews, time to build your report, time to deliver your report… that’s a lot of time!

 Audience’s time: Research is no good if your findings aren’t available early enough to be useful to your developers and decision makers—be sure to factor in your development team’s timelines. This is a great opportunity to engage with your team members and other stakeholders to consider any time constraints for the study.

 Interview time: Think about 30–90 minute durations for interviews. Are you good at listening intently, while asking questions and taking detailed notes? Most of us aren’t. Either record your interviews or have a teammate take notes during your interview. Account for your interview time, and buffer time between interviews for all important tasks like staying fed and hydrated.

 Recruiting time: Allow enough time to recruit study participants, and keep these tips in mind:

  • Look to analytics to find a list of active users
  • Have a short study explanation ready for your potential participants that explains:
    • Do they use it <current product> fairly frequently?
    • Do they, or will they, use it to do their job more effectively?

Be ready to schedule time and know that folks will likely change their availability—a lot.

As you can see, just the logistics of UX research is complex—but all your advanced planning will help things go smoothly.

Now that she knows how long the process will take she can start recruiting participants!

Recruit the Right Users

You are so ready to kick off your recruiting and get your interviews started. Chances are you have access to a few lists of people your team members recommend as participants. Or potentials may come up during your problem history investigation. You could just interview all of them. But that’s a lot of interviews to conduct and analyze, which makes your results too late to help design and development, which is the whole point of your study. So how do you whittle down the list of users to just the right ones?

image of researcher turning handle on bingo basket

How Many Participants Does It Take to Change a Product?

How many participants is enough? Some amazing researchers identified (using science!) that the number of participants needed for a study will vary depending on the type of research you’re conducting. We’ll cover methods soon, but you’ll need at least 5 participants for a usability study, while interviews can have up to 30 users. With interviews, the golden rule is to talk to enough people to collect enough data to start seeing patterns—hearing the same things over and over again. Try to start with 15 users, then check for patterns. If you don’t see them, you may need to recruit more participants or narrow your research scope.

Inviting Participants to Join Your Study

You’ve nailed down your number of participants, now it’s time to decide which users are best for your study. Ask yourself:

  • Do they use it <current product> fairly frequently?
  • Do they, or will they, use it to do their job more effectively?

If the answer is yes to both of these questions then you have your users!

Folks who use products regularly are better equipped to give you examples of how it works (or doesn’t) in their daily role, which gives you great material for brainstorming improvements.

Next you’ll segment your participants. Maybe you have your users already grouped by persona. If not, learn more about using personas for recruitment in the UX Personas for Salesforce module.

Personas helps you refine your list of participants. For example, if the thing you’re testing only impacts a specific segment of your users, then look to those groups for participants. Or perhaps you’re in the very early stages of product/service exploration, you’ll want to open your participant selection to a broader group of users. We’ll cover personas more in unit 2.

But deciding who you want to interview is just a piece of the puzzle. Now comes the really fun part—choosing the right research method to solve your research problem.

Choose a Good Research Method

This can be tricky, but there are four basic categories to choose from when picking a good research method:

  •  Behavioral methods focus on what people do.
  •  Attitudinal methods focus on what people say.
  •  Qualitative methods try to answer “Why?” or “How?”
  •  Quantitative methods try to answer “How much?” or “How many?”

image of researcher with idea bubbles around them to represent different research methods

Use qualitative methods to understand opinions, use cases, or motivations. For example, you might ask someone to show you how they’ve organized their folder structure (behavioral) or ask them reasons why they like or dislike using your product or service (attitudinal).

You can think about quantitative methods as being all about the numbers. They give you meaningful statistics that reveal patterns. For example, how long does it take each participant to complete the same task or how many people did or said the same thing (8 out of 10 people didn’t know how to export a report in our product).

But let’s back up… what is a research method?

It’s a strategy or procedure that you can use to gain insights about your research problem. Common methods include:

  •  Surveys are good for casting a wide net to collect many responses.
  •  Card sorting activities are good for grouping things into categories, for example, items in a navigation menu.
  •  Contextual inquiry is good for observing a participant in their own environment to better understand how they work.
  •  Individual interviews are good for getting detailed information from a user and spending one-on-one time getting to know them or how they use your product or service.
  •  Focus groups are good for observing how participants respond to your questions in a group setting, noting similarities and differences to how they work or use your product or service.
  •  Usability testing is good for learning how your users experience your service or product by measuring tasks and performance.

You can pick one method or combine several, but we recommend you stick to one for now. As you get more comfortable with UX research you can add more.

How to Use Your Approach Document

So you’ve assembled all the pieces to your approach document, right? Not so fast detective, there’s one more very important part to include at the end—a resources section. This is part of the problem history that others may investigate in future studies.

This is the part you won’t actually fill in until after your research study is finished and you have recommendations based on the feedback you’ve collected. Include in this section:

  •  Participants list, including each user’s name, company, and role.
  •  Questions you asked your participants (more on that in the next unit).
  •  Summary of results, including any spreadsheets or slide decks you’ve produced. Don’t worry, we’ll talk about analyzing your findings in a later unit.

Now that you’ve created your approach document, in the next unit we’ll talk about how to craft your questions.

Resources

Share your Trailhead feedback over on Salesforce Help.

We'd love to hear about your experience with Trailhead - you can now access the new feedback form anytime from the Salesforce Help site.

Learn More Continue to Share Feedback