What research ops covers and where to start

Say you're on the research team at a hospital group. You find out that two teams there ran the same study a few months apart, both asking why patients miss follow-up appointments. Neither team knew about the other, and the second study cost as much as the first.

Research ops, short for research operations, is the work that stops a study from being run twice. Research gets repeated because the first team's findings sit where nobody looks. You stop it by making the place where findings live the first stop before any new study starts.

Research ops has a few more parts too, and the place to start is a short look at where your team's hours go.

What research ops is

When one researcher runs a few studies a year, they can keep it all in their head. They know who took part, where the consent forms are and what last year's study found. But as more teams start running research, that stops working.

As studies and researchers multiply, the overhead multiplies with them. Each researcher solves the same recruitment problem in a slightly different way, consent wording drifts from study to study, the same patients are invited by three teams in a month, and recordings sit in personal folders.

Research ops is the work that keeps research running smoothly as it grows. It covers recruiting and paying participants, handling consent and data, choosing tools and keeping findings where people can find them. You'll see the name written three ways, research ops, ReOps and ResearchOps, and they all mean the same job.

Nielsen Norman Group defines ResearchOps as the orchestration and optimization of people, processes and craft in order to amplify the value and impact of research at scale. The ResearchOps Community, a global network of practitioners, describes it as the people, mechanisms and strategies that set user research in motion. The practice grew up around user research, and the same needs apply wherever an organization gathers evidence from customers. Market research, patient experience and service design teams also recruit participants, handle personal data and store findings.

What stays with researchers is the research: choosing the method, designing the study, running the sessions and interpreting what people said and did. Research ops changes the ground they work on.

A team has outgrown doing this by hand when studies wait for participants, or several teams invite the same patients in the same month. Another sign is when last year's findings exist somewhere, but nobody finds them before the next study starts. Each sign has a different cost: time, legal exposure, money or credibility. The first job of a new research ops function is to find out which one costs this organization the most.

The eight areas research ops covers

Research ops can sound like an endless list of chores. The ResearchOps Community's model sorts it into eight areas, which it calls pillars. The table shows the question each area answers and who usually owns it in a large organization.

That's a lot for one person. This guide folds them into four areas research ops works on every day: participants, governance, knowledge and tools. Research ops supports the other four, but the head of research owns them. Nielsen Norman Group's model reaches a similar list from another direction, with six components: participants, governance, knowledge, tools, competency and advocacy. The four working areas are where the two models meet.

Decide which area to fix first

With eight areas, it's tempting to fix whichever one people complain about most. But the loudest complaint isn't always what slows your team down.

A better start is a time audit. Look back at the last two quarters of studies. For each one, note the hours spent on each task and the days from the first request to the first interview.

An audit like this takes two or three weeks and needs no new tools. Ask each researcher to reconstruct the hours they spent on each task in their most recent studies. Then pull the dates from calendars and the request log: when the request arrived, when the first interview ran and when the findings were presented. Reconstructed hours are rough. They are good enough to rank problems, and ranking is all the audit has to do.

The request log shows a cost the hours can't. Some requests are dropped because participants could not be found before the decision date. Those decisions went ahead with no evidence from patients at all, and each one belongs in the audit.

Those numbers are your starting point, so later you can tell whether a change helped. Then rank the areas by hours lost, delays caused and risk carried. A gap that costs you nothing can wait. A small gap that delays every study can't.

Risk can move an area up the list even when it costs few hours. If the audit finds three different consent forms in use across the teams, and one of them is two years out of date, that costs almost no time each week, but it moves up the list on risk.

Share the ranking with the researchers who gave their hours. They will see their own complaints in it, or see why another problem came first.

At the hospital group, the research team runs the audit across a dozen studies. Two tasks stand out. Finding and booking patients takes the most hours, and searching shared folders for earlier research comes second. So the team fixes knowledge first, because it decides whether a study needs to run at all. Recruitment comes next.

The audit also sets the targets for both fixes: fewer hours spent searching, fewer days waiting for patients and fewer requests that a past study already answered. Those figures are what the research ops lead takes to the head of research when asking for the next investment.

Repeat the audit every six months with the same measures, so each result can be set against the last. Researcher hours per study by task, days from request to first interview and requests dropped for lack of participants are enough to show whether research ops is working, separately from the value of the research it supports.

Finding past research stops repeat studies

Think back to the two teams at the hospital group. The answer already existed, so the second study never needed to run.

That's why knowledge management saves the most wasted work. It means keeping findings where people can find and use them. A common reason collections of past research fail is that filing is a separate job after the study ends, and by then the team has moved on.

Nielsen Norman Group has studied why repositories fail. Maria Rosala surveyed more than 400 UX and ResearchOps professionals and followed up with interviews. The study found four main reasons: very low UX maturity in the organization, dissatisfaction with the chosen tool (23 percent of respondents), no clear owner (29 percent) and a contribution process that asks too much work of the people expected to add to it. The practitioners' recommendations follow from those reasons: choose a tool built for the purpose, set goals beyond collecting research in one place, involve the people who will use it, build the tags from the start, start small and adjust with use, make someone responsible for keeping it up, and keep promoting it.

A research repository is a shared, searchable store of past findings and the proof behind them. A good one fixes the filing problem in three ways.

• Findings land in it while the study runs, so there's no filing step afterwards.
• One search covers every team's studies.
• Each finding stays linked to the quotes and transcripts behind it.

Pulse works this way. Every study's themes, quotes and transcripts are kept together in the Insights library, beside earlier studies, and the library is queryable across projects. So before a new brief, the short written plan for a study, goes out, the team can check what patients have already said.

A repository also needs an owner, because the other fixes depend on one. At the hospital group, looking after it becomes part of the research ops lead's job, with a quarterly look at the most-viewed findings.

A small set of tags makes findings searchable across studies. The hospital group might start with four families of tags: the service (outpatients, maternity, emergency care), the patient group, the stage of care and the method. Keep each family to about a dozen values, write down what each one means and tag every study from each family before it closes. Too many tags, or tags used unevenly, make search unreliable.

Watch what people search for, too. Where the repository logs searches, the ones that return nothing are a list of questions the organization is asking and research has not answered yet. They belong in next quarter's research plan.

Bring findings to people as well as storing them. A short monthly digest of new findings, sent to the teams whose tags they carry, reminds everyone the repository exists.

Make it a rule for every new request. Before anyone starts a study, someone searches past studies and writes one line, "Here's what we already know, and here's the gap."

If there's no gap, there's no study.

Recruitment and scheduling take most of the admin

Ask a researcher where their week goes, and much of the answer is admin. They screen people, book times, send reminders, chase people who don't show up and pay people for their time. Each of those tasks grows with every new study, so this area breaks first when more teams start running research.

The work starts before recruitment, with one way to ask for research. A short request form gives the research team what it needs to scope the study and find the right people:

• The decision this research will inform, and the date it will be made.
• The question, in one or two sentences.
• Who the study needs to hear from, and how many groups must be compared.
• What the team already knows, with links to earlier findings.
• Who will act on the results, and in what meeting.

The decision date matters most. It lets the research team work backward to a start date and say at once whether a full study can finish in time. The same form also shows which questions keep coming back, which teams are underserved and which patient groups are asked for most often. Those groups are the first a research pool should cover.

When requests exceed capacity, publish the rule used to choose among them. Weigh the size of the decision, how uncertain the answer is today and whether existing evidence already answers it. A request that earlier findings can answer gets a pointer to that evidence instead of a new study. A request tied to a small decision that is easy to reverse may suit a lighter study run by the team asking, with support. The largest and most uncertain questions go to the research team.

A pool of patients who have agreed to be contacted for research cuts the search for the groups requested most. It needs consent records, profile details, a history of who took part in what, and regular removal of people who no longer respond. For the groups the pool can't reach, one or two recruitment partners with agreed quality standards save a scramble for a new supplier on every study.

Scheduling is the task a platform can remove completely. With Pulse, participants open a link and take the interview on a phone or laptop, so there are no calls to book and nobody waits for a free slot. They can come from a shared study link or an uploaded list of your own patients, or be recruited to a profile and a screener, the few short questions that decide who takes part, including business and expert audiences. Every participant goes through fraud checks, and incentives, the payment people get for taking part, are handled for the team. Each interview arrives as a full transcript with its recording while the study is still in the field; fieldwork can run overnight, and the findings come minutes after the final interview.

Governance gets harder as more teams run research

Now the hospital group's patient experience team starts running its own interviews too. That's another place where a consent form can go missing, or a recording can be kept longer than it should be.

Governance is the set of rules that stops this. It covers consent, privacy, how long you keep data and who can see people's personal details. Three rules are worth setting before more teams join in.

• One consent text, approved by your legal team, used in every study.
• A set time for keeping recordings and transcripts, written down and followed.
• Clear roles for who can see personal details and who sees only the findings.

Data protection laws in many countries share common principles. The UK Information Commissioner's Office lists seven: lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; integrity and confidentiality; and accountability. Applied to research, they mean collecting only what the study needs, using it only for the purpose participants agreed to, keeping it secure and deleting it when it is no longer needed. Many organizations also follow a professional code such as the ICC/ESOMAR International Code, which gives researchers, legal teams and participants a shared reference point.

Contact needs a rule as well. When several teams recruit from one group of patients, research ops keeps a shared record of who was invited, by which team and when. The rule can be simple, such as no patient invited to research more than once in 90 days. The pool applies it when invitations go out, so no team has to check by hand.

Recordings, transcripts and notes often hold personal data, so research ops decides where research data is stored, who can open it, how long it is kept and how it is deleted. A retention schedule makes those rules concrete. The periods below are examples only; each organization sets its own with its privacy and legal teams.

Studies about health are sensitive by nature. Agree with the privacy team which studies need extra review and who gives it. Keep one incident process too, so a recording shared with the wrong people, or a request to delete someone's data, is handled the same way every time.

On Pulse, personal data is redacted from transcripts, customer data is never used to train AI models, and access runs on Owner, Admin and Member roles. The platform is GDPR compliant, and SAML and OIDC single sign-on are available on request on the enterprise plan.

Quality is the other half of governance, because questions start to drift when more people write interviews. One interview guide per study, shared by everyone who runs it, keeps every participant on the same well-formed questions. Each theme in a readout should link back to the quotes and transcripts it came from, so anyone can check a finding against the interview behind it.

People outside the research team need support as well. Nielsen Norman Group's guidance on democratizing research draws the line by task: most people can learn to run a simple qualitative test, while complex work, such as choosing a method or framing research questions, needs a researcher's education and experience. A light review at two points, the plan before fieldwork and the findings before they are shared widely, catches leading questions and conclusions stretched past the evidence while there is still time to fix them. A regular session where people who run studies compare what worked, which questions produced useful answers and which templates need changing gives the research ops lead a direct view of where the support is working.

Buy tools for the problem you found

A tool bought before the process is settled tends to copy the old way of working, problems included.

So buy for the problem your time audit found. Check where findings end up, how participants reach the study and how results reach the teams who act on them. A standard research plan helps every team plan studies the same way first.

At the hospital group, the audit pointed at knowledge and then recruitment. So any tool on the shortlist is judged on two questions first. Do findings land in one searchable place while each study runs? Can patients take part without a booked call?

Build the team's standard setup into whatever you choose: interview projects with the right access settings, survey templates with the standard screener and consent questions, and repository tags applied by default. Prefer tools that connect to what the team already runs. Every file moved by hand costs time, and it is another chance for patient data to land in the wrong place.

Before a new tool is approved for everyone, pilot it with two or three teams on real studies. Check how its data can be exported before anything is stored in it, so the team is never stuck with findings it can't move. Ask how it handles a request to delete one person's data, because a patient who withdraws consent has to be removed from recordings, transcripts and the repository alike.

The audit often turns up a cost outside the hours, too: several teams paying for tools that do the same job. Count what is already paid for before buying anything new. Write down who owns the approved list and when each tool comes up for renewal, so a tool nobody uses is noticed before it renews.

Every tool that handles participant data needs a security and privacy review before anyone uses it. Research ops can run that review once, with security, legal and the team that buys software, and keep a list of approved tools. Then a team starting a study picks from the list instead of repeating the review.

AI-assisted analysis, automated transcription and AI-moderated interviews change who can run a study and how fast. Research ops is well placed to set the rules for using them: which kinds of study suit them, who reviews what they produce, and how themes are read against the transcripts behind them before a decision rests on them.

Set the tools up to absorb more studies, teams and services without a matching rise in effort, through templates, self-service and systems that connect. Then the team's own time goes to the work that needs judgment.

When you need a dedicated research ops role

At some point, ops work on the side becomes too much for one researcher. Two questions tell you when. How many studies run each quarter, and how many teams run them? More studies put pressure on recruitment and admin. More teams put pressure on governance and knowledge. When both rise together, it's time for a full-time role.

Before that point, one person responsible for each of the four working areas is usually enough.

Research ops can sit inside a research team, in a design operations group or in a wider operations function, and it can serve user research alone or market research and patient experience as well. Two conditions matter more than the reporting line. Someone owns the work, and that person has the authority to set rules other teams follow, such as how often a patient may be contacted or which tools may hold participant data.

In many organizations, the first step is a researcher who takes on operations tasks for the team, such as managing recruitment or looking after the repository. Writing down what they do, and the hours it takes, builds the case for the role.

The role usually goes to a research operations lead or manager who reports to the head of research. The legal team, IT and the people who buy software share governance and tools. Most large organizations start with one dedicated person rather than a whole team. They add more people when the time audit shows one person can't keep up with recruitment, governance and knowledge at the number of studies they run.

A new research ops lead's first ninety days might run in three steps. In the first month, they repeat the time audit with every researcher. In the second, they fix the largest source of waste, which at the hospital group is the search for earlier research: one repository, one set of tags and the rule that every request starts with a search. In the third, they report the first measures against the starting numbers.

Research ops depends on other teams: legal, privacy, security, IT, finance and the teams that run patient services. Agreed routes with each of them, such as a standing privacy review for common study types and one way to pay incentives, let it move quickly without cutting corners.

As the function grows, write down how it works: the services it offers, how to ask for them, the policies, the approved tools and who to contact. A short handbook helps new researchers start and cuts repeated questions.

Look at the priorities again once a year, against a fresh audit. A team running a few studies a quarter needs different support from a group researching all the time across many services. A second audit might show the search for earlier research solved and analysis now the largest block of hours, which moves the next investment there.

A research ops checklist for next quarter

Five steps give you a place to start in one quarter, and a way to measure progress.

1. Run the time audit. Note the hours spent on each task and the days from request to first interview.
2. Pick one area and record where it stands today. Choose the area with the most hours lost or the longest delay, and write down today's numbers.
3. Make the repository the first stop for every new request. No brief goes out until someone has searched past studies and written down the gap.
4. Use one brief, one screener and one consent text. Give every team the same three templates, so studies are run and stored the same way.
5. Count the studies you didn't need to run. Each quarter, count the requests that past studies answered, and watch that number grow.

The fifth step is the start of a wider record. Keep one entry per study from the day it is requested: the question, the team asking, the decision and its date, the method, the participants and the main findings. A month or two after the readout, add what was decided and what happened next. Most of these fields come from the request form and the repository, so the record costs little to keep. Keep it where the repository lives, so a finding and the decision it informed sit side by side.

Over a year, the record answers the question a research budget review asks: which decisions did research change? It also shows where research is not reaching decisions, such as teams that ask for studies and never record an outcome.

Report from it each quarter to leadership, in the same outline each time:

1. What patients told us this quarter: three to five findings, each with its evidence.
2. Decisions research informed, and what happened as a result.
3. What is planned next quarter, and the decisions it will serve.
4. What would help: access, budget or time from other teams.

Short accounts come out of the record too. What the team believed, what the research found and what happened next can be told in a minute at a leadership meeting, and a head of service can repeat it to their own team without the report in hand.

Report the gaps as well. A study that missed its decision date because recruitment took three weeks is also a finding about recruitment, and it goes back on the research ops list.

If a question has been asked before, find the old answer first, and run a new study only for the gap. At the hospital group, that one habit would have saved the second team's study.