ResearchOps
Concept
The operational layer that keeps forms, participant records and rules ready in advance, so no study has to be set up from scratch.
Why it exists
Teams that run one study never had this problem. It showed up once studies became monthly and the same setup work got redone every time. The session itself takes an hour; reaching that hour kept taking three days.
Pagedeck noticed it on the fifth study. Mia went looking for the consent form used last time, dug through a long chat history, and the version she found turned out to predate legal review. While picking participants, an invitation went out to someone who had already sat for an interview the month before — nobody had written down who was contacted when. Meanwhile Noa gave up trying to find results from six months earlier and ran the same study again, because recordings and write-ups lived on individual drives where search couldn't reach them.
ResearchOps isn't a way of doing research; it's the work of holding up the people doing it. What you ask stays untouched. What changes is that the preparation before asking and the storage after it get built once and reused.
How it works
Pull out whatever repeats from study to study, build it in advance, and have the next study take it off the shelf. Six things usually get built. None of them touch the questions themselves, which is the line that keeps this from turning into a review board.
- Consent and incentives. One current version of the consent form — telling participants what gets recorded and how far it may be used — plus a decision on the incentive amount and how it's paid.
- A participant record. A table of who was met, when, and for which study. Add a rule that the same person isn't invited again inside 90 days and you stop leaning on the handful of people who always say yes. This is where the time spent on participant recruiting drops the most. Forty rows is already enough to be useful, because the failure it prevents is not forgetting one name but letting the same five people carry every study.
- A place for the material. Recordings, transcripts and write-ups in one location, each tagged with the question the study was trying to answer. It earns its keep when someone can search that sentence and surface a study from six months ago.
- Rules for handling personal data. How personally identifiable information (PII) — names, phone numbers, anything that points at one individual — gets masked in recordings and notes, and how long any of it is kept. Handle it differently each time and nobody knows which files are due for deletion.
- Repeatable templates. A frame for writing the questions, a table for grouping quotes by theme, a one-page result format. Identical formats let three studies be read side by side.
- Roles and an intake point. How the facilitator and the note-taker split the session, and where a request for research is supposed to land. With no intake point, requests arrive as direct messages and nobody can see the queue.
Pagedeck captured all six in three documents. Preparation for one interview went from three days to half a day after that.
Where it shows up
It shows up once the same study starts repeating. Two thresholds usually decide it: whether a quarter holds two or more studies, and whether more than one person runs them. If neither is true, building the layer costs more time than it saves. Nothing says it has to arrive complete, either — most teams build the piece that hurts most first, and that is almost always the participant record.
Different study types lean on different parts. A customer interview, where one person is met to hear about their experience, spends most of its calendar on finding participants, so the record and the consent form pay off first. A usability test, where someone is given a real task so you can watch where they stall, repeats the same flow before every release, so fixing the task wording and the note format is worth doing. A survey, which puts the same question to many people, gets faster to write when past questions and their results can be found together.
It also touches desk research, the practice of gathering what already exists. Not re-recruiting people for a question already answered inside the company depends on old results being searchable, and making them searchable is the ResearchOps job.
The load grows fastest as the team grows. Three people running studies separately means one user hears from the company three times in a month. From that point on this stops being tidiness and starts being how the relationship with users is protected.
How it sounds at work
"Use the current consent form in the ResearchOps folder. Last month's wording changed."
Stop copying your own version of the form; one copy gets maintained.
"I'm leaving this person out — they sat for an interview last month. It's in the record."
The participant history was checked and an overlap was filtered out.
"Without ResearchOps we burn three days preparing a single interview."
The schedule is stretched by missing setup, not by weak research skills.
Pagedeck has nobody dedicated to research. Mia built this layer alongside her product work, and Noa uses the same documents when she runs a study. Both of them open the participant record first to filter out anyone contacted in the last 90 days, and both file their write-up into the same folder in the same format when they finish. Neither of them owns the layer, so whoever runs the next study fills in whatever turned out to be missing.
The result is that someone who joined last month can find and read a study from six months ago without help. More time was saved by not running the same study twice than by running each one faster.
What people get wrong
The most common reading is that this means buying a tool. Products exist for managing participants and organizing recordings, so paying for one looks like the whole job. An empty tool holds no templates and no rules, though. How soon the same person may be invited back, how long a recording is kept — those are values a team has to set, and without them the tool is one more folder. The rules are the substance here and the tool is only where they get stored. Pay first and six months later you have a tool nobody opens and files still scattered.
The other belief is that a dedicated person has to exist before you can start. The word operations makes it sound like a function that needs staffing. It actually grows the other way around: someone who runs studies builds one form and one record alongside the work, and a person gets added when maintaining it becomes a job of its own. Wait for the hire and the material piling up meanwhile can't be recovered. Collecting scattered files later costs more than putting them in one place from the start.
Where to go next
- User research
see the work this layer holds up
- Participant recruiting
the step that shortens most once the layer exists
Last updated 2026-09-16