ResearchOps: Scaling User Research Without Losing Quality

What is ResearchOps, and what is it not?

ResearchOps is not a role or a piece of software. It is a set of decisions about how research gets done in an organization: who recruits participants, where what was learned is stored, how consent is requested, which tools are used, and how new researchers are trained.

The ResearchOps Community describes eight pillars: environment, scope, people, organizational context, recruitment and admin, data and knowledge management, governance, and tools and infrastructure. Nielsen Norman Group proposes a framework of six areas: participants, governance, knowledge, tools, competency, and advocacy. The two models agree on the essentials, though they divide the areas differently. NN/g notes that its model is not exhaustive and that the areas are related to each other, not isolated.

Why does this matter for a junior designer?

Because most teams start researching by hand: one researcher, one document, and an email to recruit. That works until the team grows, and then problems appear that have nothing to do with design: repeated studies, participants contacted three times in one month, consent forms nobody can find, and findings lost when someone changes company.

Understanding ResearchOps lets you propose small improvements without waiting for a big restructuring. A junior who organizes a shared folder of findings is already doing ResearchOps.

Which areas does it cover?

According to Nielsen Norman Group:

• Participants: recruiting, screening, scheduling, and compensating participants.
• Governance: processes and guidelines for consent, privacy, and information storage.
• Knowledge: processes and platforms for collecting, synthesizing, and sharing research insights.
• Tools: consistent toolsets and platforms that make research more efficient.
• Competency: enabling, educating, and onboarding other people to perform research activities.
• Advocacy: defining, sharing, and socializing the value of research across the organization.

Kate Towsey, one of the community’s figures, lists eight similar functions in her own diagram (participant recruitment, knowledge management, onboarding and support, tools and vendors, ethics and privacy, money and metrics, program management, and people and skills). Her warning is that when you work on one function, you end up working on all of them. The areas are connected, and touching one means reviewing the others.

Where should you start?

1. Find the strongest pain. Nielsen Norman Group recommends starting from the current problems that justify ResearchOps, because not everything can be addressed at once. Ask the team what takes up the most time.
2. Start with one area. If studies repeat, start with knowledge: a shared folder with a summary format. If participants are hard to find, start with a simple register of people willing to take part. For recruiting itself, see recruiting participants.
3. Write the process before buying the tool. A tool without a process only moves the mess somewhere else.
4. Track cost as you grow. NN/g offers a hypothetical scenario: if a company does ten times more research, the cost should not be eleven times the old budget but about nine, thanks to economies of scale, and the ResearchOps goal should be eight times or lower. These are not measured results.
5. Review every quarter. Ask whether the system saves time or just adds steps.

Towsey also warns that the time ResearchOps takes is badly underestimated. Start with a small, well-scoped project rather than the whole system.

When should you NOT set up ResearchOps?

• When research goals are not defined. Investing in systems without clear questions produces an empty repository, or one full of things nobody looks at. Towsey warns that you cannot create a specific system without being clear about what you want to achieve, and she calls reacting to an urgent need without considering the organization’s goals knee-jerk operations.
• When the team is very small and runs few studies. With one researcher and two studies a year, good notes and a shared document are usually enough.
• As an excuse not to research. The goal is to research more and better, not to generate processes.

Also, NN/g’s model does not cover career development, hiring, or onboarding for researchers. Those topics have their own practices.

Example

Illustrative example: a software company has four product teams that research separately.

• Problem: two teams interviewed the same customers in the same month. A third did not know a billing study from a year earlier existed.
• First action: a shared document with a one-page summary template per study, including date, goal, participants, and findings.
• Second action: a single participant list with the date of the last contact, so the same people are not contacted again within three months.
• Review: three months later, the team checks for earlier studies before starting a new one.

None of these actions needed a new tool. What changed was the order. For the repository itself, the next step is the research repository.

If your team uses AI-assisted interviews, also review the article on AI interview synthesis, because the governance of participant data applies the same way.

Common mistakes

• Believing ResearchOps is only about recruiting participants.
• Buying a repository before defining how findings are stored.
• Trying to set up all six components in the same quarter.
• Forgetting consent and privacy until a specific case appears.
• Not making clear who is responsible for maintaining the system.
• Measuring success by the number of studies rather than by the decisions they changed.

Sources

• Nielsen Norman Group, ResearchOps 101
• Nielsen Norman Group, ResearchOps: An Interview with Kate Towsey
• ResearchOps Community, About ResearchOps