Whose Job is User Research? An Interview with Amy Santee

Almost every time I give a talk, I get asked how people can convince their companies to adopt more user research or pay attention to the research that’s being done. I’ve always given various answers, ranging from “quit and go to a better company” to “try to make research more inclusive,” but I realized that I was giving advice based on too small of a sample set.

So, earlier this year, I became obsessed with finding out who owns user research in functional teams. I’ve asked dozens of people on all sorts of different teams what makes research work for them, and I’m sharing their responses here. If you’re someone who is very familiar with how user research works on your team and would like to participate, please contact me.

Recently, I asked Amy Santee, an independent UX research consultant, some questions about who should own research. She trained as an anthropologist, and she’s been doing user research for several years for companies ranging from healthcare to insurance to hardware and mobile tech companies, so she’s seen what works and doesn’t work in a lot of different models.

Who Owns It

“For internal teams,” Amy explains, “researchers and designers who do research should ‘own’ the research process in the sense of being the go-to people responsible for driving its fundamental activities: planning and budgets, coordination, research design, recruiting participants, conducting sessions, and disseminating the results. It’s not so much ‘owning’ it but being the point person for getting things done.”

One of the themes I’ve seen so far in these interviews is the strong difference between the responsibility for conducting research and the ownership of the results. Regardless of who is responsible for getting research done, research results and participation should be owned by the whole team. The researcher or designer might be driving the process, but everybody else on the team should be along for the ride.

It’s not just direct members of the team who need to participate, either. “Stakeholders in design, product, engineering, business, marketing and other areas should share in this ownership to the greatest degree possible,” Amy says. “That’s why they’re called stakeholders – they have (or should have) a stake in the game when it comes to incorporating research into their processes and decision-making.”

To be clear, in Amy’s model, the stakeholders aren’t just interested in the outcomes. They should be active participants in the research. They can offer important perspectives from their respective business areas, and they should contribute to the research process itself by observing sessions, brainstorming ideas and solutions, and helping to synthesize the results.

The benefits of this sort of participatory research, Amy says, are clear. “The more this is done, the more value people will see in being involved, and the less the researcher needs to ‘own’ research by him or herself. Stakeholders might even learn how to do research so they don’t always have to rely on a single person or team to do it.”

Researching without Researchers

Of course, not all teams are lucky enough to have dedicated researchers or designers who are trained in user research methods. Amy has some suggestions for those who decide to do research without any experience on the team.

“My preference is for internal researchers because they have an understanding of the company and product from the inside,” she explains. “They are able to really get a sense for how research fits into the design process and business strategy. They can build relationships with other business areas and roles in order to figure out how research can bring the most value, when to do it, who to get involved, how to communicate most effectively, and possibly make more effective recommendations.”

That said, there are reasons to bring in experts from outside. “Training from an expert who has the right background and experience can help a team get started with the fundamentals and avoid the inappropriate execution of a research project (e.g., wrong methodology, misinformed research questions, etc.),” she says.

Sometimes, combining an external expert with internal trainees can even yield certain unexpected benefits. For example, outside consultants might have a fresher look at the questions the team should be asking. They might be able to bring up things that team members wouldn’t feel comfortable saying because they don’t have a bias or agenda. And, of course, they’ll typically have experience working with many different teams, so they’ll be able to spot patterns that less experienced researchers might not see.

Whether you’re working with internal experts or external coaches, the important thing is that the people on your team are engaged in the process. Making research a collaborative effort means more people in your company will learn from users, and that’s good for your product.

Learn More

For more information about Amy, check out her website, find her on Twitter, or connect with her on LinkedIn.


Whose Job is User Research? An Interview with Steve Portigal

This post appears in full on the Rosenfeld Media blog. 

Those of us who conduct user research as part of our jobs have made pretty big gains in recent years. I watched my first usability test in 1995 then spent a good portion of the 2000s trying to convince people that talking to users was an important part of designing and building great products. These days, when I talk to companies, the questions are less aboutwhy they should do user research and more about how they can do it better. Believe me, this feels like enormous progress.

Unfortunately, you still don’t see much agreement about who owns user research within companies. Whose job is it to make sure it happens? Who incorporates the findings into designs? Who makes sure that research isn’t just ignored? And what happens when you don’t have a qualified researcher available? These are tough questions, and many companies are still grappling with them.

So, I decided to talk to some people who have been dealing with these questions for a living. For this installment of the Whose Job is User Research blog series, I spoke with Steve Portigal, Principal at Portigal Consulting. He’s the author of Interviewing Users, which is a book you should read if you ever do any research on your own.

Steve has spent many years working with clients at large and small companies to conduct user research of all types. He also spends a lot of his time helping product teams get better at conducting their own research. Because he’s a consultant, he sees how a large number of companies structure their research processes, so I asked him to give me some advice.

Read the rest at Rosenfeld Media>

Whose Job is User Research? An Interview with Dorian Freeman

As part of my ongoing series about how user research is being done in organizations, I asked Dorian Freeman, the User Experience Lead at Harvard Web Publishing to answer a few questions. She shared her experiences working in UX design since the late ‘90s. See the rest of the series here

Owning Process vs. Owning Results

When I asked Dorian who on a product team should own user research, she explained that there is a difference between owning the process and owning the results. “The people who are accountable or responsible for research are the ones who oversee the researching, the synthesizing of the data, and the reporting on the findings,” she explained. “However, the data from the research is ‘owned’ really by everyone in the company. It should be accessible to everyone.”


This is an important distinction. Regardless of who is collecting the data, the output is important to the whole company  and should be accessible and used by everybody. Research, in itself, is not particularly valuable. It’s only the application of the research to product decisions that makes it valuable. Making the results of the research available to everybody means that, hopefully, more decisions will be made based on real user needs. 

External vs. Internal

A few folks in this series have talked about the benefits of having UX research done by members of the team, but Dorian called out one very important point about external researchers. “An external expert can often provide insights that are more credible to the leadership than an internal expert, which is a perception issue, but helpful in some cases.”

And she’s absolutely right. We may not always love that it’s true, but highly paid external consultants will sometimes be listened to where an employee won’t, even when they’re saying the same things.

On the other hand, for day to day research that is informing product team decisions, an in-house expert is often preferable. Dorian says, “Typically, the in-house expert researcher has more institutional knowledge which can speed up the process and provide more insight. In the ideal scenario, the product team should always have an internal expert researcher working closely with them.”

For teams that aren’t lucky enough to have an expert, Dorian recommends getting someone on the team to learn how to do it. “Understanding the people who use your product is essential,” she says. “If you’re not interviewing users, you’re not doing UX.”

Whose Job is User Research? An Interview with Susan Wilhite

As part of my ongoing series where I try to find out who is doing user research in organizations and who should be, I spoke with Susan Wilhite. Susan is a lead UX researcher. She was incredibly helpful in explaining how teams work best under different conditions. This is the third post in the series. 

Strategic vs Tactical

When we talk about ownership of the research function, we have to start with the type of research we’re doing and our goals for that research. “When research is mostly tactical,” Susan explains, “it should be owned by either product management or the design team, with the other being a key stakeholder.” 

Research that is intended to answer very specific, well understood questions, should be driven by people on the team who are asking those questions. For example, usability testing and other forms of tactical, evaluative research are going to be owned and driven by the people responsible for making decisions based on the results of the studies. 

Strategic research, on the other hand, like that done when a company is still developing its primary product or service or is branching into other lines of business, should be led with broad direction and budget from the VP of product or other high level stakeholder. This puts that leader in the best position to interpret UX research findings for their peers and champion those ideas into wider strategic decisions.

Most importantly though, generative and formative research is best done in-house rather than by people outside the company. “This research, unlike evaluative, has a very long shelf life. A tiny amount of information from strategic studies are communicated in a final report,” Susan explains. "Findings developed outside the company can be a lost opportunity to grow institutional knowledge within the org over time. Down the road this is important because findings from generative and formative research inform the most tactical research.” 

In other words, don’t pay vendors to acquire deep knowledge about your users unless you intend a long-term relationship those outside researchers. Understanding the product/service and users is a critical advantage, and the understanding that comes from conducting generative and formative research should be kept close to the vest.

Cross Functional Teams vs Silos

Recently, with the growth in Agile and Lean methodologies, we’ve seen a lot of companies break down functional silos in favor of cross functional teams. This can improve communication within the product team and help diminish the waste that happens when silos only communicate through deliverables. Susan points out some of advantages and disadvantages of doing away with the research team. 

“I have become a fan of the embedded research function,” Susan says. “Researchers are themselves tools, and as such are vastly more effective when given the chance to compound learnings and develop stakeholder trust in a circumscribed domain.” When a user researcher works within a product team, they become much more effective, since they’ll have a better understanding of the team’s real research needs. They can also build trust with the team, which will hopefully lead to less resistance to suggestions made by the researcher. 

On the other hand, embedded UX research has its own problems. “The hazard here is that product groups have varying budgets and sexiness – a researcher caught in a group not advancing fast from attention given by executives or the market can hobble a career.” Having a separate research team can prevent that by allowing researchers to circulate among teams and find areas of interest and groups where they work best. But still, it takes a very well managed corporate culture for a silo to work. As Susan warns about research teams in silos, “Success is uncommon.” 

Regardless of the company org chart, Susan encourages summing up and offering evolved thinking on strategic frameworks and tactical principles throughout the company. “I’d like to see twice-yearly off-sites where the org reviews what has been learned and workshops ideas from the product team at large,” she says. “Partly to remind the team of what has been learned and how we think we know it, but also to ponder aspirational research - what’s next.”

Whose Job is User Research? An Interview with Tomer Sharon

I'm interviewing researchers, designers, product managers, and other people in tech about their opinions on how user research should be done within companies. This is the second post in the series, and it appeared in full on the Rosenfeld Media blog. 

If you'd like to be featured as part of the series, contact me

As part of my ongoing series of posts where I try to get to the bottom of who owns user research, I reached out to Tomer Sharon, former Sr. User Experience Researcher for Google Search and now Head of UX at WeWork. He also wrote a book called It’s Our Research which addresses this exact topic, and his new book Validating Product Ideas is now available. He’ll be speaking at the upcoming Product Management + User Experience from Rosenfeld Media about ways teams can work together to learn more about their users.

I asked Tomer a few questions about his recent statement that UX at WeWork won’t have a research department and what suggestions he has for creating a team that conducts research well and uses it wisely.


Read the rest at Rosenfeld Media >


Whose Job is User Research? An Interview with Jeff Gothelf

I'm interviewing researchers, designers, product managers, and other people in tech about their opinions on how user research should be done within companies. This is the first post in the series, and it appeared in full on the Rosenfeld Media blog. 

If you'd like to be featured as part of the series, contact me

While doing research for the upcoming PM+UX Conference, several respondents requested guidance around how user research should managed. In fact, it was the most common write-in answer on our survey, and a question that comes up repeatedly whenever I give talks. Apparently, there seems to be very little consensus about who on a product team should own research. This makes it a lot harder to get user insights and make good product decisions.  

In a way, this is good news. Five or ten years ago, there would have been more questions like, “How do I get my boss to consider doing user research?” and “What is user research good for?” Those still come up, but far more frequently, I’m hearing things like, “How do we make sure that everybody on the team understands the research?” and “Who is in charge of making sure research happens and deciding what to do about it?” Research, these days, is assumed. It’s just not very well managed.

To answer these questions, I interviewed several very smart people who know a thing or two about research and building products. I’ll share some of their suggestions in a series of blog posts.

First, I spoke with Jeff Gothelf, the author of Lean UX (O’Reilly, 2013) and Sense and Respond (Harvard, 2016).

Read the rest at Rosenfeld Media >