ResearchOps

ResearchOps (research operations, often shortened to ReOps) is the work that lets an organisation do user research well and at scale: finding and recruiting the right participants, getting their informed agreement, scheduling and paying them, storing recordings and notes safely, deleting them on time, and turning findings into knowledge that other people can find and trust later. Researchers design and run studies; ResearchOps builds and runs the system those studies depend on.

The ResearchOps Community defines it as “the people, mechanisms, and strategies that set user research in motion. It provides the roles, tools and processes needed to support researchers in delivering and scaling the impact of the craft across an organisation.”^[1] Nielsen Norman Group (NN/g) puts it as “the orchestration and optimization of people, processes, and craft in order to amplify the value and impact of research at scale.”^[2]

Written for beginners, researchers taking on operational work, ResearchOps managers and recruiters, design and product leaders, and the privacy and legal partners who sign off on research data. Sources were last verified on 2026-10-23.

The label passes the Atlas’s test for established (stable definitions, roles and bodies) inside its own field:

• A community with a definition and a model. The ResearchOps Community says its definition came out of “our global series of workshops in 2018”, and describes itself as “a community of more than 15,000 people” (self-reported).^[1]
• Independent definitions and teaching. NN/g published a six-part model in 2020, built from interviews with DesignOps and ResearchOps practitioners.^[2]
• A handbook. Kate Towsey’s Research That Scales: The Research Operations Handbook (Rosenfeld Media, 17 September 2024, 336 pages) codifies the practice.^[5]
• Teams and roles in the public sector. The UK Government Digital Service (GDS) studied research operations in three government departments in 2019 and set up its own function in 2022; the UK Department for Education (DfE) formed a three-person research operations team in 2020.^[6][7][8]

Two honest qualifications. First, the community itself calls ResearchOps “an emergent profession in its own right”:^[1] the label is stable, but roles, ratios and career paths still vary a lot between organisations. Second, no census that could be opened for this page shows how many organisations run a ResearchOps function, so this page makes no adoption claims.

User research looks simple from outside: talk to some people, watch them use a product, write up what you learned. The operational load is what makes it hard to repeat. Before a single session, someone has to find people who match the criteria, screen out the wrong ones, schedule them across time zones, tell them what will happen to their data, record their agreement, arrange payment, book a room or a video tool, and brief observers. After the session, recordings sit on laptops, consent forms sit in inboxes, findings sit in slide decks, and the next team runs the same study again because it cannot find the last one.

The GDS team described the result in 2019: without support, researchers spend too much time on administration, which takes away from research itself.^[6] NN/g frames the economic goal: if a company does ten times more research, the cost should not be eleven times the old budget but nine times, thanks to economies of scale and reuse, and NN/g adds that the goal “should really be 8× or lower”.^[2] That is a goal, not a measured result, but it states the problem precisely: research volume should grow faster than research overhead.

Without operations, three failures appear as research grows:

1. Slow starts. Every study recruits from scratch; recruitment becomes the critical path.
2. Unmanaged risk. Personal data, recordings and special-category information (health, disability, ethnicity) spread across personal drives and chat tools with no retention date and no record of what people agreed to.
3. Research amnesia. Insights live in reports nobody can search, so organisations pay twice for the same knowledge and make decisions without the evidence they already own.

• Not only participant recruitment. NN/g’s article has a section titled “ResearchOps Is Not Just Participant Recruitment”: recruitment is the most visible pain and “often low-hanging fruit”, but only one part of the work.^[2]
• Not research administration in universities or hospitals (grants, sponsored programmes, institutional review); see the disambiguation above.
• Not the researchers’ job title with a new name. The community notes that not all ResearchOps professionals are researchers (participant recruiters and research librarians, for example).^[1] ResearchOps supports research; it does not decide research questions or conclusions.
• Not a tool purchase. Towsey calls the rush to buy a tool before understanding the whole picture “knee-jerk operations”.^[9]
• Not legal advice. ResearchOps writes policy and keeps evidence; privacy counsel and data-protection officers interpret the law. Every legal statement on this page names its jurisdiction and date.

Only milestones with a source are listed; the practice of supporting researchers is older than the label.

• 2017. Tomer Sharon, writing on WeWork’s blog, described Polaris, WeWork’s searchable store of research “nuggets” open to all team members, holding “more than 4,000 nuggets based on hundreds of interviews”.^[10]
• 2018. The ResearchOps Community ran a global series of workshops asking “what is ResearchOps?” and arrived at its definition. Its About page also presents an eight-pillar model but does not date it.^[1]
• 2019. GDS visited research teams at the DVLA, DWP and HMRC and listed the operational support they needed.^[6] GitLab replaced research reports with an insights repository built from GitLab issues.^[11] The community started its Research Skills Framework project.^[12]
• 2020. NN/g published its six-part ResearchOps model.^[2] During the first COVID-19 lockdown, DfE formed a research operations team within a week and recruited over 250 users in four months.^[8]
• 2022. GDS set up a research operations function; for its first few months, one person supported 50 to 60 researchers.^[7]
• 2024. Towsey’s handbook was published;^[5] NN/g published guidance on research repositories^[13] and an evaluation of AI-generated “synthetic users”.^[14]

Three published models describe the scope. They overlap heavily; their differences are useful.

The rows are this page’s alignment, not a mapping any of the authors published. The community’s eight pillars are the eight labels in the first column. After the pillars, its page also describes event management, budget for research, research spaces, socialising research, and recruitment in short sections of their own.^[1]

What the comparison teaches: the community model starts from the environment research lives in (why it happens, who is involved, the organisation around it); NN/g adds competency (teaching others to research) and advocacy; Towsey makes money and metrics and program management explicit, which matters once ResearchOps has a budget to defend.

Think of ResearchOps as two supply chains joined by a ledger (this page’s model):

1. Participants into sessions. Raw material: people willing to help. Steps: source, screen, consent, schedule, run, pay, protect. Output: sessions that happen on time with the right people.
2. Evidence into decisions. Raw material: recordings, notes, observations. Steps: store, tag, synthesise, find, reuse, re-validate, retire. Output: decisions that cite evidence.
3. The ledger. A record of who agreed to what, which data exists where, and when it must be deleted. Both chains read and write it. Most serious ResearchOps failures are ledger failures: a recording nobody can match to a consent record, a clip shared wider than the participant was told, a panel member contacted every week.

flowchart TB
  PR["ProductOps: roadmap questions"]:::neutral
  CX["CXOps: journey signals"]:::neutral
  RDO["ResearchDataOps: scientific data"]:::risk
  RO["ResearchOps: participants, consent, data, insights"]:::core
  PV["PrivacyOps: lawful basis, DPIA"]:::neutral
  KO["KnowledgeOps: knowledge practice"]:::neutral
  DO["DesignOps: design team and tools"]:::neutral
  PR -->|requests| RO
  CX -->|questions| RO
  RDO -.-|name only| RO
  RO -->|evidence| PR
  RO <-->|policy, approvals| PV
  RO -->|repository practice| KO
  RO <-->|tools, budget| DO
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

The boundaries in the last two columns are editorial distinctions made by this Atlas; small organisations often put DesignOps and ResearchOps in one role, and privacy work may sit with a single legal adviser. NN/g’s own answer to the hierarchy question is that “Research Operations is a specialized subcomponent of Design Operations”.^[20] The Atlas still gives ResearchOps its own page because participants, consent and research data raise questions design operations does not. The split (participants and insight here; craft and system on DesignOps) is the same on both pages.

This charter is this Atlas’s proposal, written from the sources above; no official ResearchOps manifesto exists.

Mission. Make research with people easy to start, safe for participants, lawful, and useful long after the study ends.

Principles.

1. Participants are people, not inventory. Respect their time (pay promptly, keep sessions to the stated length), their choices (withdrawal is easy and honoured everywhere) and their data (collect the minimum, delete on schedule). The community lists “operationalizing respect for the people who participate in our research” among the reasons for the field.^[1]
2. Every artefact has a ledger entry. No recording, transcript or clip exists without a link to the participant’s consent record, a storage location and a deletion date.
3. Design the system before administering it. Towsey advises hiring someone who can design the whole system before hiring people to administer it.^[9] Map the end-to-end flow before buying a tool.
4. Proportionate control. Low-risk studies (a usability test of a public web page with adult customers) need a light path; high-risk studies (health, children, vulnerable people, sensitive topics) need review. One process for everything is either too slow or too loose.
5. Findability over volume. A repository with 200 well-tagged, current insights beats 5,000 unsearchable reports.
6. Measure service and safety. Track how fast and how safely research happens, not how many studies ran.
7. Keep the lights on visibly. Towsey’s “keep the lights on” tasks (maintaining what was built) pile up over time;^[9] budget for them explicitly.

Non-goals. Deciding what to research (research leadership), deciding the lawful basis (privacy counsel), running product analytics, or acting as a general events team.

Common roles (titles vary; one person may hold several in a small organisation):

• ResearchOps lead or manager: designs the system, owns policy, budget and metrics.
• Participant recruiter or panel manager: sources, screens, schedules and pays participants; keeps the panel healthy.
• Research librarian or knowledge manager: owns the repository, taxonomy and insight quality. The community’s repositories project argues a good repository “includes one or more librarians”.^[21]
• Research tools administrator: licences, access, integrations, vendor reviews.
• Researchers and people who do research: design and run studies, write insights, follow the policies.
• Privacy, legal and security partners: decide lawful basis, review high-risk studies, run DPIAs and breach response.

R = responsible, A = accountable, C = consulted, I = informed. This RACI is a proposal; the key design choice is that the ResearchOps lead is accountable for the ledger even when many people write to it.

stateDiagram-v2
  direction TB
  [*] --> Candidate: sign-up or referral
  Candidate --> Screened: answers screener
  Screened --> Excluded: does not match
  Screened --> Booked: matches and agrees
  state "Contact data erased" as Erased
  Booked --> Attended: session held
  Booked --> NoShow: misses session
  Attended --> Paid: payout confirmed
  NoShow --> Panel: opted in, flagged
  NoShow --> Erased: no panel opt-in
  Paid --> Panel: opted in
  Paid --> Erased: no future contact
  Panel --> Screened: invited again within contact limit
  Panel --> Erased: opts out or retention ends
  Excluded --> Erased: screener data deleted
  Erased --> [*]

Three design points hide in this state machine:

• Erasure is a state, not an afterthought. Excluded candidates and one-off participants should leave the contact records on schedule (their research data follows the retention schedule); storage limitation is a data-protection principle in the GDPR.^[22]
• The panel is a separate purpose. Agreeing to one session is not agreeing to be contacted for years; ask for panel membership separately and record it.
• Re-entry respects a contact limit. The same enthusiastic people otherwise take part in every study. NN/g notes that panel members already know the product and may give more positive feedback than new users.^[15]

Service catalogue. Publish what ResearchOps offers and how fast, for example: recruitment from the panel (target five working days), agency recruitment (two to four weeks; longer for participants with access needs, as GOV.UK advises allowing up to a month and more for less common cognitive disabilities),^[23] consent template selection (same day), repository onboarding, and study review for high-risk tiers.

Risk tiers for studies. Most governance effort should go into deciding which path a study takes.

flowchart TB
  Q["New research request"]:::neutral
  A{"Children, vulnerable people or special-category data?"}:::decision
  B{"Sensitive topic, deception or covert observation?"}:::decision
  C{"Shared beyond the team or kept outside approved tools?"}:::decision
  T3["Tier 3: ResearchOps and privacy review before recruiting"]:::risk
  T2["Tier 2: standard templates plus ResearchOps check"]:::decision
  T1["Tier 1: self-serve, templates, approved store, panel limits"]:::core
  Q --> A
  A -->|yes| T3
  A -->|no| B
  B -->|yes| T3
  B -->|no| C
  C -->|yes| T2
  C -->|no| T1
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

The tier questions are this page’s proposal; adapt them with your privacy team. Recording alone does not raise the tier: most interviews and usability tests are recorded, and a recording kept in the approved store and seen only by the study team is the normal Tier 1 case. Two sources anchor the Tier 3 questions: the GDPR prohibits processing special-category data such as health data unless an Article 9 condition applies,^[16] and research codes give children extra protection (the UK’s Market Research Society requires verified permission from a responsible adult before a child takes part).^[24]

Cadences. Weekly: recruitment queue and incentive backlog. Monthly: panel health (contact load, opt-outs, no-shows), repository contributions. Quarterly: retention sweep, access review, scorecard to research leadership, vendor review. Yearly: policy and template review with privacy counsel.

Escalation. Any suspected exposure of participant data (a recording in a public channel, a lost laptop, a clip in a sales deck) goes to the privacy or security incident process the same day; the worked incident shows the flow.

This is a logical architecture: the components are capabilities, and one product may provide several of them.

flowchart TB
  IN["Front door: intake form and service catalogue"]:::neutral
  subgraph PII["Personal-data zone: restricted access"]
    CRM["Panel and participant records"]:::core
    SCR["Screeners and scheduling"]:::core
    CON["Consent records"]:::core
    PAY["Incentive payouts"]:::core
    REC["Recordings and transcripts"]:::risk
  end
  REP["Knowledge zone, wide access: repository of studies and insights"]:::core
  DEC["Decisions that cite insights"]:::neutral
  IN --> SCR
  CRM --> SCR
  SCR --> CON
  CON --> REC
  SCR --> PAY
  REC -->|de-identified extracts only| REP
  REP --> DEC
  CON -.->|scope and deletion dates| REP
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

Component responsibilities and the trade-offs that matter:

• Personal-data zone versus knowledge zone. The most important design decision. Recordings, contact details and payment data stay in a restricted zone; the repository holds de-identified insights and short extracts that most of the organisation can read. NN/g advises flexible permissions: most repositories should not be publicly accessible, and only the right people should reach session recordings or identifiable participant data.^[13] GOV.UK recommends fully anonymising extracts whenever possible.^[25]
• Consent records as a service. Other components ask the consent store two questions: “may I keep this?” and “who may see it?”. If the answer lives only in a PDF, nobody can automate retention or sharing checks.
• One tool or several. All-in-one research platforms reduce integration work and give one access model; specialised tools may fit better but multiply the places personal data lives. Count the copies of each recording before choosing.
• Processors. Each vendor that stores participant data is a processor; under the GDPR, controllers must use only processors “providing sufficient guarantees” of appropriate measures.^[17] That includes AI transcription and analysis features.

sequenceDiagram
  autonumber
  participant R as Repository
  participant T as Product team
  participant O as ResearchOps
  participant P as Participant
  T->>O: Request via intake (tier 1-3)
  O->>P: Screener and information sheet
  P->>O: Agrees to take part and to recording
  O->>T: Booked sessions and observer brief
  O->>P: Incentive given at session start
  Note over T,P: The team runs the session and records it
  T->>R: De-identified insights with tags
  R->>T: Found and reused months later
  Note over O,P: Exception: P withdraws
  P->>O: Withdraws consent
  Note over R,O: ResearchOps deletes P's data and every copy

Happy path, step by step.

1. Intake. The requester states the research question, audience, method, timing, recording needs and data sensitivity; the form assigns a tier.
2. Recruit. Panel first if it fits the audience; agency or marketplace for reach. Screener criteria are reviewed by the researcher; contact limits are checked.
3. Inform and agree. Participants receive a plain-language information sheet. The UK Market Research Society code lists what participants must be told before taking part even when consent is not the legal basis: who is collecting data and why, the type of data, the right to withdraw, whether the session is recorded or observed, who may access recordings, likely length, and any costs.^[24]
4. Run. Observers are briefed on their responsibilities; recording starts only after the participant has been told.
5. Pay. Give the incentive at the start of the session where possible, as GOV.UK recommends.^[23] Payment must never depend on what the participant says.
6. Store and synthesise. Raw data goes to the approved restricted location with a deletion date; insights go to the repository with links back to the study.
7. Reuse and retire. Insights are found by later teams, cited in decisions, re-validated, or retired when the product changes.

Exception paths. Withdrawal (shown), a participant who turns out not to match (stop politely, pay anyway, record why the screener failed), suspected fraud (see recruitment), a no-show (follow the no-show policy, keep a reserve participant for important studies), and an observer who recognises the participant (tell the participant in advance where observers may know them, as the MRS code requires in that situation).^[24]

Choose the source by audience, not habit. Each source has a different bias, cost and speed:

NN/g’s guidance on panels is that it is “not a choice between internal panels and external recruiting; many teams use both.”^[15]

Write screeners that cannot be gamed. Ask about behaviour, not identity (“Which of these tools did you use last week?” with decoys) and put qualifying answers among plausible alternatives. GOV.UK advises asking about the difficulties people have (for example reading small text) rather than relying only on self-identification, because “Some people with access needs do not identify as having a disability.”^[23]

Keep the panel healthy. Record opt-in for future contact separately from consent to one study; set a contact limit (Lab 1 uses two invitations per 90 days as an example policy, not a benchmark); refresh panel profiles; remove people who opt out immediately; and delete inactive members when the retention period ends. NN/g warns that manual panel management increases the risk of lost records, privacy issues and duplicate contacts as panels grow.^[15]

Detect fraud and problem participants. Remote research attracts people who misrepresent themselves for the incentive. NN/g separates three groups: outliers (not representative, not dishonest), cheaters (mainly after the payment) and professional participants (take part too often).^[26] Its signals for unmoderated studies include not attempting tasks and ignoring instructions; “Low success rates combined with very fast task times” are “usually a strong indicator of a cheater”, while impatience with a design is not cheating.^[26] A 2025 study of two fully virtual clinical trials reported ten fraudulent enrollees and 37 more flagged during screening, with signals such as similar email patterns, location mismatches and repeat enrolment, and recommended combining automated and manual checks at each stage.^[27] That was clinical research; for most product research, proportionate controls are: a camera-on screening call for high-incentive studies, duplicate checks on payment details and contact data, and flags in the panel record.

This is the part teams most often get wrong, because one word (“consent”) is used for two different things.

1. Permission or informed agreement to take part. An ethical and professional requirement: the person knows who you are, why you are doing this, what happens in the session, whether it is recorded or observed, what happens to their data, and that they can stop at any time. GOV.UK requires it from all participants, “even if they work for your organisation”.^[28]
2. The lawful basis for processing personal data. A legal requirement under data-protection law (for example the GDPR in the EU and the UK GDPR). Consent is one basis among several. The UK regulator, the ICO, says “No one basis is always better, safer or more important than the others”, that you must decide the basis before processing, and that you generally cannot switch away from consent later (guide updated 2026-04-02).^[29]

The UK Market Research Society code makes the same split: rule 30 lists what participants must be told for permission under any legal basis; rule 31 adds further information (retention periods, transfers, right to complain) when consent is the legal basis.^[24] In UK health and social care research, the NHS Health Research Authority goes further: consent to take part is still needed, but the legal basis for processing “should NOT be consent”.^[30] Though specific to UK health research, it shows that the two decisions are separate.

Why it matters operationally. If consent is your lawful basis, the GDPR requires you to be able to demonstrate it, lets the participant withdraw at any time, and says “It shall be as easy to withdraw as to give consent.”^[31] Your systems must then find and delete every copy of that person’s data, including clips in the repository. If a different basis is chosen (for example legitimate interests, which the HRA names as the basis for commercial organisations in UK health research),^[30] the participant still has rights and you still owe them a clear explanation; the difference is in which rights apply and how you document the balance. That choice belongs to privacy counsel; ResearchOps makes the choice executable.

Special-category data needs a second legal test. Under GDPR Article 9, processing data about health, ethnicity, sexual orientation and the other special categories “shall be prohibited” unless one of the conditions in Article 9(2) applies, and that condition is needed in addition to the lawful basis.^[16] In commercial UX research the practical candidate is usually explicit consent (Article 9(2)(a)): the UK regulator expects it to be confirmed in a clear statement, to name the kind of special-category data, and to be separate from other consents. The research condition (Article 9(2)(j)) covers archiving, research and statistics; in the UK it also needs Schedule 1 condition 4 of the Data Protection Act 2018, which requires a public interest, and “commercial market research is unlikely to be covered”.^[32] So a study that recruits disabled people or asks about health needs two decisions from counsel, not one, and the consent record stores both.

What ResearchOps builds:

• Versioned information sheets and forms per study type and tier, in plain language, offered in accessible formats (GOV.UK mentions reading the form aloud and recording verbal consent for disabled participants).^[28]
• Separate, unticked choices for separate purposes: taking part, recording, sharing clips beyond the research team, joining the panel.
• A consent record per participant per study, stored with the data it covers and matched by participant number (GOV.UK advises naming files so consent and data can be matched).^[28]
• A withdrawal procedure that reaches every copy (see the worked incident).
• A trigger for a data protection impact assessment (DPIA) when processing is “likely to result in a high risk” to people,^[18] for example studies with health data or children.

• Set rates by audience and time. NN/g recommends frameworks for “fair and consistent incentive levels based on participant expertise and required time investment”.^[2] Publish the rates so teams do not bid against each other.
• Tell people the terms in advance. The MRS code requires telling participants who administers the incentive, what it is, when they will receive it, and any conditions.^[24]
• Do not pay in your own products for research. The MRS code prohibits client goods or vouchers for client goods as incentives in research projects (it binds MRS members, but the reasoning applies widely: product credit biases feedback and excludes non-customers).^[24]
• Avoid coercive amounts. The UXPA code asks practitioners to avoid “excessive or inappropriate” inducements.^[33]
• Pay promptly and pay no-shows only by policy. Paying at the start of the session, as GOV.UK recommends, removes any link between payment and the participant’s opinions.^[23]
• Handle tax and fraud centrally. Rules are national. In the US, for example, the minimum reporting threshold for many Form 1099-MISC and 1099-NEC payments rose to $2,000 for tax years beginning after 2025 (IRS instructions dated 12/2026).^[34] Whether and how a given incentive must be reported is a question for your tax team; ResearchOps keeps the payout records that make the answer possible.

1. Collect the minimum. GOV.UK asks teams to collect “the minimum information you need to manage their participation”.^[25]
2. Store only in approved places. Move recordings off devices to approved storage quickly.^[25]
3. Set a retention schedule. GOV.UK suggests “2 or 3 years as reasonable retention periods for user research data” and says to delete data where you do not have clear evidence of consent.^[25] Different artefacts need different periods: screener answers of excluded candidates can go within weeks; de-identified insights can stay for as long as they are true.
4. Separate identity from content. Use participant numbers in files and transcripts; keep the key that links numbers to people in the restricted zone. That is pseudonymisation in the GDPR’s sense: data that can no longer be attributed to a person without additional information kept separately.^[35] Pseudonymised data is still personal data; only effective anonymisation takes it out of scope.
5. Sweep on a schedule. A quarterly retention sweep (Lab 2 automates the logic) beats good intentions.

Pick the repository type deliberately. NN/g describes two types: document libraries (easy to contribute to, insights hard to discover) and insight databases (insights easy to find, contributing harder, and insights need updating or retiring). The main trade-off is “insight discoverability versus effort needed to add to the repository”.^[13] Many teams combine them: an insight database whose entries link to the study folder.

Atomic research, honestly. In 2017 WeWork’s Polaris defined a nugget as “a combination of an observation (something we learned), evidence (an audio or video snippet of a user describing the experience in their own words, or a screenshot or photo), and tags that allow for slicing and dicing the data.”^[10] Daniel Pidcock’s “Atomic UX Research” (the concept his company Glean.ly builds on)^[36] chains experiments, facts, insights and conclusions; some write-ups say recommendations for the last step.^[37] GitLab adapted the idea in 2019 with light synthesis before an insight is added, which is why it calls entries insights rather than nuggets.^[11] The strength of atomic approaches is reuse across studies; the cost is contribution effort and context loss, so a short summary of the study context must travel with each insight.

flowchart TB
  S["Session recording (restricted, 2-3 years)"]:::risk
  F["Facts: de-identified observations"]:::core
  I["Insight: interpretation with 2+ sources"]:::core
  D["Decision record cites insight"]:::neutral
  V{"Still true after product change?"}:::decision
  RT["Retire insight, keep decision history"]:::neutral
  S -->|extract, remove identifiers| F
  F -->|synthesise| I
  I --> D
  I --> V
  V -->|yes| I
  V -->|no| RT
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

The point of the chain: raw data and insights have different lifetimes. Deleting a recording on schedule should not delete the knowledge, and an insight should not outlive the product behaviour it describes. Lab 3 implements the checks.

Taxonomy. Start with a few broad tags (product area, audience, journey stage, method) rather than many specific ones; NN/g recommends starting simple and testing labels with card sorting or tree testing.^[13] Name an owner for the taxonomy.

Adoption. NN/g lists easy access, flexible permissions, intuitive navigation or tags, search, and export/integration as the attributes that drive adoption, and stresses onboarding and change management.^[13] GDS’s experience points the same way: data guidance cut to two-thirds of its length was well used, but time spent reworking wiki pages that analytics later showed nobody much visited was wasted, so check usage before polishing.^[7]

NN/g defines democratisation as “making it acceptable and possible for anyone, no matter their role, to do user research”, and proposes five steps: identify demand, classify supply of researchers and PwDR, fulfil gaps through training and matching, sync on who does what, and revise.^[19] It argues that “basic user research can, in fact, be done by almost anyone”, while choosing methods, framing questions and quantitative or contextual studies need “education, experience, and skills”.^[19]

ResearchOps turns that into infrastructure: the risk tiers above, approved templates for Tier 1 methods, panel access with contact limits enforced by the system rather than by goodwill, office hours, and a review path for anything above Tier 1. One research-tool vendor describes such guardrails as “bumpers in a bowling alley”;^[38] the useful point behind the metaphor is that guardrails are built into the path, not checked after the fact. The risks NN/g lists for poorly managed democratisation (poor research leading to poor design, lack of accountability, misuse of resources) are what the guardrails exist to prevent.^[19]

Separate what binds you from what guides you.

Academic and clinical research add institutional review and, in the US, federal human-subjects rules; most commercial product research is outside those regimes, but organisations that partner with universities or run health studies should ask their legal team which rules apply.

Vendor-neutral categories first; named products are examples verified on their own websites on 2026-10-23, not recommendations. Capabilities change; re-check before buying.

Selection rules. Map the end-to-end flow first; count where each personal-data item will live; ask every vendor for its processor terms, subprocessors (including AI model providers), data residency, deletion API and export format; prefer tools your colleagues already use when adoption is the bottleneck (NN/g’s first adoption attribute is easy access).^[13]

Automation helps the repetitive parts: reminders, contact-limit checks, retention sweeps, matching consent records to assets, duplicate detection, and transcription. Most of it needs no AI.

AI features now appear in most research tools (transcription, summaries, theme sorting). Treat them with three controls:

1. Processor scope. An AI feature that sends recordings to a model provider is processing by a processor or subprocessor; it must be covered by contracts and by what participants were told.^[17]
2. Traceability. A machine-generated theme is a hypothesis until a researcher checks it against the evidence; keep links from every AI summary back to the source moments.
3. No synthetic substitutes. NN/g compared AI “synthetic users” with three earlier real studies and found them sycophantic and shallow (“Synthetic users seem to care about everything”); it suggests using them only for desk research and generating hypotheses, never as a replacement for research with real people or for final decisions.^[14]

A small, complete set of artefacts for an organisation with 10 to 30 people who do research. Field names are illustrative; adapt them to your tools. All are this Atlas’s templates.

Artefact 1: research intake form (as a YAML definition your form tool or a script can read).

Example status: syntax-checked (YAML), not executed against a form tool.

form: research-intake
version: 3
fields:
  - id: question
    label: What decision will this research inform?
    required: true
  - id: audience
    label: Who do you need to talk to?
    required: true
  - id: method
    label: Method
    options: [interview, usability-test, survey, diary, other]
  - id: needed_by
    label: Date you need findings
    type: date
  - id: sensitive
    label: Children, vulnerable people, health or other special-category data?
    type: boolean
  - id: sensitive_topic
    label: Sensitive topic, deception or covert observation?
    type: boolean
  - id: wide_sharing_or_unapproved_tool
    label: Shared beyond the research team, or kept in an unapproved tool?
    type: boolean
routing:
  tier3_if_any: [sensitive, sensitive_topic]
  tier2_if_any: [wide_sharing_or_unapproved_tool]
  default: tier1
service_levels:
  tier1: self-serve, templates and panel access the same day
  tier2: ResearchOps check within 2 working days
  tier3: ResearchOps and privacy review before recruiting, 5-10 working days

Artefact 2: consent record (one per participant per study).

Example status: syntax-checked (JSON), not executed.

{
  "consent_ref": "C-2026-0412",
  "participant_id": "P-0931",
  "study_id": "S-2026-077",
  "information_sheet_version": "interview-v4",
  "lawful_basis": "legitimate_interests",
  "art9_condition": null,
  "agreed": {
    "take_part": true,
    "recording": true,
    "share_clips_beyond_research_team": false,
    "join_panel": true
  },
  "captured_by": "researcher-17",
  "captured_on": "2026-10-20",
  "method": "electronic form",
  "withdrawn_on": null,
  "delete_raw_data_by": "2028-10-20"
}

The lawful_basis value comes from privacy counsel’s decision for that study type. art9_condition stays null unless the study collects special-category data; then counsel names the Article 9 condition (for example explicit_consent), and Tier 3 review checks that it is filled in. The agreed block records the participant’s choices. Keeping both in one record is what makes the consent playbook executable.

Artefact 3: retention schedule.

The periods are examples to agree with privacy counsel, not recommendations for every jurisdiction.

Artefact 4: panel contact and fairness policy (excerpt).

Example status: syntax-checked (YAML), not executed.

panel_policy:
  opt_in: separate checkbox, never pre-ticked
  max_invitations_per_90_days: 2
  max_sessions_per_12_months: 4
  cooldown_after_session_days: 30
  reconfirm_membership_every_months: 12
  incentive_rates_minutes_to_amount:
    consumer: {30: 25, 60: 50}
    professional: {30: 75, 60: 150}
  incentive_currency_note: amounts in local currency units; review yearly
  no_show_or_late_cancel: pay if absent or cancelling < 2 hours before, once a year

Three labs on synthetic data only: Python 3.8 or later, standard library only, no accounts, no cost. Each lab was run on 2026-10-23 exactly as printed (Python 3.8.10 with SQLite 3.31.1, Ubuntu Linux); the expected outputs are copied from those runs.

Objective. Compute the qualification rate, no-show rate and time to recruit for three studies, and find panel members invited more often than the policy allows. Prerequisites. Python 3.8+ and a shell. Time. 20 minutes. Risk. None.

1. Create a folder and the two data files.

Example status: verified by execution on 2026-10-23 (bash, Linux).

mkdir -p ~/reops-labs/lab1 && cd ~/reops-labs/lab1
cat > studies.csv <<'CSV'
study_id,requested_on,sessions_needed
S1,2026-09-01,5
S2,2026-09-08,6
S3,2026-09-15,4
CSV
cat > invites.csv <<'CSV'
study_id,participant_id,source,invited_on,status,booked_on
S1,P01,panel,2026-09-02,attended,2026-09-04
S1,P02,panel,2026-09-02,attended,2026-09-04
S1,P03,panel,2026-09-02,screened_out,
S1,P04,panel,2026-09-02,no_show,2026-09-05
S1,P05,agency,2026-09-03,attended,2026-09-08
S1,P06,agency,2026-09-03,attended,2026-09-09
S1,P07,agency,2026-09-03,attended,2026-09-10
S2,P01,panel,2026-09-09,attended,2026-09-10
S2,P08,panel,2026-09-09,no_response,
S2,P09,panel,2026-09-09,attended,2026-09-11
S2,P10,panel,2026-09-09,no_show,2026-09-11
S2,P11,agency,2026-09-10,attended,2026-09-15
S2,P12,agency,2026-09-10,screened_out,
S2,P13,agency,2026-09-10,attended,2026-09-16
S2,P14,agency,2026-09-10,attended,2026-09-17
S2,P15,agency,2026-09-10,attended,2026-09-18
S3,P01,panel,2026-09-16,attended,2026-09-17
S3,P02,panel,2026-09-16,attended,2026-09-17
S3,P16,panel,2026-09-16,cancelled,2026-09-18
S3,P17,panel,2026-09-16,attended,2026-09-19
S3,P18,panel,2026-09-16,attended,2026-09-22
CSV

2. Save the script as funnel.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""ResearchOps Lab 1: recruitment funnel, time to recruit and panel contact load."""
import csv
from collections import defaultdict
from datetime import date

BOOKED = {"attended", "no_show", "cancelled"}
SCREENED = BOOKED | {"screened_out"}
# A cancelled booking frees the slot, so it does not count toward filling a study
FILLS = {"attended", "no_show"}
# Contact policy: at most 2 study invitations per panellist per 90 days
MAX_INVITES_90D = 2


def d(text):
    return date.fromisoformat(text) if text else None


studies = {r["study_id"]: r for r in csv.DictReader(open("studies.csv"))}
invites = list(csv.DictReader(open("invites.csv")))

screened = [r for r in invites if r["status"] in SCREENED]
qualified = [r for r in screened if r["status"] != "screened_out"]
attended = sum(r["status"] == "attended" for r in invites)
no_show = sum(r["status"] == "no_show" for r in invites)
print(f"Invitations: {len(invites)}  screened: {len(screened)}  "
      f"qualified: {len(qualified)}")
print(f"Qualification rate: {len(qualified) / len(screened):.0%}")
sessions = attended + no_show
print(f"No-show rate: {no_show / sessions:.0%} ({no_show} of {sessions})")

print("\nTime to recruit (request -> date the last needed session was booked):")
for sid, s in studies.items():
    booked = sorted(d(r["booked_on"]) for r in invites
                    if r["study_id"] == sid and r["status"] in FILLS)
    need = int(s["sessions_needed"])
    if len(booked) < need:
        print(f"  {sid}: NOT FILLED ({len(booked)}/{need} booked)")
        continue
    days = (booked[need - 1] - d(s["requested_on"])).days
    print(f"  {sid}: {days} days")

print("\nPanel contact load (invitations per panellist, last 90 days):")
per_person = defaultdict(list)
for r in invites:
    if r["source"] == "panel":
        per_person[r["participant_id"]].append(d(r["invited_on"]))
for pid, days in sorted(per_person.items()):
    last = max(days)
    recent = [x for x in days if (last - x).days < 90]
    if len(recent) > MAX_INVITES_90D:
        print(f"  {pid}: {len(recent)} invitations -> "
              f"exceeds policy of {MAX_INVITES_90D}")

3. Run it: python3 funnel.py.

Expected output.

Invitations: 21  screened: 20  qualified: 18
Qualification rate: 90%
No-show rate: 12% (2 of 17)

Time to recruit (request -> date the last needed session was booked):
  S1: 8 days
  S2: 9 days
  S3: 7 days

Panel contact load (invitations per panellist, last 90 days):
  P01: 3 invitations -> exceeds policy of 2

Validation. Check S1 by hand: its booked dates sorted are 4, 4, 5, 8, 9 and 10 September; the fifth needed booking is on 9 September, eight days after the 1 September request. The no-show rate uses attended plus no-shows (17) as the denominator, not all bookings, because the cancellation never reached a session. For the same reason the cancelled 18 September booking does not fill S3: its fourth filling booking is on 22 September, seven days after the request (counting the cancellation would give a flattering four days). Troubleshooting. ValueError: Invalid isoformat string means a date is not YYYY-MM-DD. A ZeroDivisionError means no rows reached screening; check status spellings. Variant. The script counts no-shows as filled because the slot was used; count only attended sessions if your no-show rate is high; the time to recruit then rises, which is the honest number. Teardown. rm -r ~/reops-labs/lab1.

Objective. Match every research asset to a consent record and flag six kinds of exception: no consent record, withdrawn consent, recording without recording consent, sharing wider than agreed, storage outside approved locations, and recordings past a 24-month retention period. Prerequisites. Python 3.8+ (its built-in sqlite3 module). Time. 30 minutes. Risk. None.

1. Create the folder and save the SQL as audit.sql.

Example status: verified by execution on 2026-10-23 (SQLite 3.31.1 via Python’s sqlite3 module).

-- ResearchOps Lab 2: consent and retention audit (SQLite dialect)
CREATE TABLE consent (
  participant_id TEXT, study_id TEXT, consent_ref TEXT,
  recording_ok INTEGER, share_scope TEXT, withdrawn_on TEXT
);
CREATE TABLE asset (
  asset_id TEXT, study_id TEXT, participant_id TEXT, kind TEXT,
  location TEXT, shared_scope TEXT, created_on TEXT
);
INSERT INTO consent VALUES
 ('P01','S1','C-0001',1,'research_team',NULL),
 ('P02','S1','C-0002',1,'product_org',NULL),
 ('P03','S1','C-0003',0,'research_team',NULL),
 ('P04','S2','C-0004',1,'research_team','2026-09-30'),
 ('P05','S2','C-0005',1,'product_org',NULL);
INSERT INTO asset VALUES
 ('A1','S1','P01','recording','repo/S1','research_team','2024-03-02'),
 ('A2','S1','P02','clip','repo/S1','company','2026-02-10'),
 ('A3','S1','P03','recording','repo/S1','research_team','2026-02-11'),
 ('A4','S2','P04','recording','repo/S2','research_team','2026-09-20'),
 ('A5','S2','P05','notes','repo/S2','product_org','2026-09-21'),
 ('A6','S2','P06','recording','laptop','research_team','2026-09-22');

-- Scope ladder: research_team (1) < product_org (2) < company (3)
CREATE VIEW scope_rank(scope, rnk) AS
  SELECT 'research_team', 1
  UNION ALL SELECT 'product_org', 2
  UNION ALL SELECT 'company', 3;

SELECT a.asset_id, a.participant_id,
  CASE
    WHEN c.consent_ref IS NULL THEN 'no consent record: quarantine, then delete'
    WHEN c.withdrawn_on IS NOT NULL THEN 'consent withdrawn: delete asset and copies'
    WHEN a.kind IN ('recording','clip') AND c.recording_ok = 0
      THEN 'recorded without recording consent: delete'
    WHEN sa.rnk > sc.rnk THEN 'shared wider than consent allows: restrict'
    WHEN a.location NOT LIKE 'repo/%' THEN 'outside approved storage: move'
    WHEN a.kind = 'recording' AND julianday('2026-10-23') - julianday(a.created_on) > 730
      THEN 'past 24-month retention: delete'
  END AS finding
FROM asset a
LEFT JOIN consent c ON c.participant_id = a.participant_id AND c.study_id = a.study_id
LEFT JOIN scope_rank sa ON sa.scope = a.shared_scope
LEFT JOIN scope_rank sc ON sc.scope = c.share_scope
WHERE finding IS NOT NULL
ORDER BY a.asset_id;

2. Save the runner as run_audit.py and run python3 run_audit.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Run audit.sql in an in-memory SQLite database and print the findings."""
import sqlite3

db = sqlite3.connect(":memory:")
statements = [s for s in open("audit.sql").read().split(";") if s.strip()]
for stmt in statements[:-1]:
    db.execute(stmt)
for asset_id, participant_id, finding in db.execute(statements[-1]):
    print(f"{asset_id}  {participant_id}  {finding}")

Expected output.

A1  P01  past 24-month retention: delete
A2  P02  shared wider than consent allows: restrict
A3  P03  recorded without recording consent: delete
A4  P04  consent withdrawn: delete asset and copies
A6  P06  no consent record: quarantine, then delete

Validation. A5 (notes shared at the scope P05 agreed to) correctly produces no finding. A6 breaks two rules (no consent record and stored on a laptop) but shows only the first: a CASE expression stops at the first true branch, so the rules are ordered by severity. If you need every finding, write one query per rule and UNION ALL them. Troubleshooting. Using the column alias finding in WHERE works in SQLite but not in every database; in PostgreSQL wrap the query in a subquery. Change the fixed date '2026-10-23' to date('now') for real use. The runner splits on semicolons, so do not put a semicolon inside a comment or string. Teardown. Nothing is written to disk except the two files; delete the folder.

Objective. Decide which repository insights need attention before anyone relies on them: single-study evidence, stale evidence, evidence that points to an unknown study, and quotes containing direct identifiers. Prerequisites. Python 3.8+. Time. 30 minutes plus discussion. Risk. None.

1. Save the repository extract as insights.json.

Example status: verified by execution on 2026-10-23.

{
  "studies": {
    "S10": {"ended_on": "2024-11-04", "method": "interviews"},
    "S14": {"ended_on": "2025-06-20", "method": "usability test"},
    "S21": {"ended_on": "2026-08-29", "method": "interviews"}
  },
  "insights": [
    {"id": "I-101", "statement": "Admins postpone setup until a second colleague joins",
     "evidence": [{"study": "S10", "quote": "We waited for Dana to start"},
                  {"study": "S21", "quote": "I don't set it up alone"}]},
    {"id": "I-102", "statement": "Exporting to CSV is the main reason for weekly logins",
     "evidence": [{"study": "S10", "quote": "Every Monday I export"}]},
    {"id": "I-103", "statement": "Users miss the bulk-edit button on small screens",
     "evidence": [{"study": "S14", "quote": "Email me at sam.lee@example.com about it"},
                  {"study": "S21", "quote": "Where is bulk edit?"}]},
    {"id": "I-104", "statement": "Trial users compare us with spreadsheets, not rivals",
     "evidence": [{"study": "S07", "quote": "It is basically a nicer spreadsheet"}]}
  ]
}

2. Save the review script as review.py and run python3 review.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""ResearchOps Lab 3: flag repository insights that need review before reuse."""
import json
import re
from datetime import date

TODAY = date(2026, 10, 23)
# About 18 months: re-check insights whose newest evidence is older than this
STALE_DAYS = 540
EMAIL = re.compile(r"[\w.+-]+@[\w-]+\.[\w.]+")

data = json.load(open("insights.json"))
studies = data["studies"]

for ins in data["insights"]:
    flags = []
    known = [e for e in ins["evidence"] if e["study"] in studies]
    if len(known) < len(ins["evidence"]):
        flags.append("evidence cites a study missing from the catalogue")
    if len({e["study"] for e in known}) < 2:
        flags.append("single-study evidence: label as tentative")
    if known:
        newest = max(date.fromisoformat(studies[e["study"]]["ended_on"]) for e in known)
        age = (TODAY - newest).days
        if age > STALE_DAYS:
            flags.append(f"newest evidence is {age} days old: re-validate or retire")
    if any(EMAIL.search(e["quote"]) for e in ins["evidence"]):
        flags.append("quote contains an email address: redact")
    print(f"{ins['id']}: {'review' if flags else 'OK'}")
    for flag in flags:
        print(f"  - {flag}")

Expected output.

I-101: OK
I-102: review
  - single-study evidence: label as tentative
  - newest evidence is 718 days old: re-validate or retire
I-103: review
  - quote contains an email address: redact
I-104: review
  - evidence cites a study missing from the catalogue
  - single-study evidence: label as tentative

Validation. I-101 passes because it has two studies and recent evidence. I-104 is flagged twice: its only evidence points to a study the catalogue does not know (deleted, or never registered), so it effectively has no traceable evidence. Discussion. I-101 quotes “Dana”, a first name: the email check did not catch it. Automated checks find patterns, not identities, which is why de-identification also needs a human review step. The 540-day threshold is an example; set it from how fast your product changes. Troubleshooting. A KeyError means an evidence item lacks study or quote. Teardown. Delete the folder.

Context. GDS set up research operations between March and September 2022. For the first few months one person supported 50 to 60 researchers; a second person joined in late July 2022.^[7] Method. A day-one benchmark survey of researchers (five statements on a 1–5 scale covering recruitment, finding prior research, consent and data protection guidance, guidance clarity, tools and templates); a workshop that mapped pain points by project stage and grouped them under the community’s pillars; a one-slide scope; quick wins (shared-drive permissions, one list of tooling); partnership with the privacy office and information management, including a research data clean-up. Result reported. Five months later all benchmark ratings had improved, and the words researchers chose moved from “siloed” and “inconsistent” to “helpful” and “visible”.^[7] Trade-off. A one-person function must say no; the published scope slide explained why some requests were declined. Lesson. Benchmark before you change anything, or you cannot show value.

Context. During the first COVID-19 lockdown, DfE needed fast insight into home learning. “Within a week we had a team of 3 people doing research operations.”^[8] Method. A sign-up form the team describes as GDPR compliant (over 5,000 responses), partnerships with charities and education networks to reach groups such as teenagers in care and families without devices or broadband, a library of COVID-19 research insights, shared templates and guidance. Result reported. Over 250 users recruited for research sessions in four months.^[8] Trade-off. The team ran on “a borrowed team, no budget, spreadsheets, existing software, and lots of goodwill”, which works for months, not years. Lesson. Partnerships, not panels, reach people who never sign up for research.

Context. GitLab’s research reports in documents were hard to search, siloed, quickly outdated and hard to act on, because teams copied report content into issues.^[11] Method. One insight per issue in a dedicated project, labels as tags, one epic per study for context and method, templates for contributors; adapted from atomic research with light synthesis. Result reported. Insights “are continually added” instead of frozen in reports, and the team states that researchers “are not gatekeepers to research”.^[11] Trade-off. Using the product-development tool for insights puts research next to the work, but needs the same permission discipline as any repository. Success measure to add. Track how often decisions link to insights (see the reuse metric below).

The definitions and formulas below are this page’s proposals; no standard ResearchOps metric set exists. Choose five or six, publish their definitions, and review them monthly with research leadership. Lab 1 computes the first three.

Leading versus lagging. Time to recruit, payment latency and contact-limit breaches move within weeks and predict participant experience and research throughput. Insight reuse and researcher time on operations are lagging: they show whether the system creates value, and they move over quarters.

Vanity metrics. Number of studies, panel size and repository size all rise while things get worse (more studies by fewer people with the same exhausted panel). Report them only next to a quality or safety measure.

What applies depends on who you research, where and on what. Common obligations and their operational answers:

Security basics. Least-privilege access to the personal-data zone, named owners for each store, recordings never in personal cloud accounts or chat tools, encrypted devices for field work, access logs for the repository’s restricted areas, and quarterly access reviews. Observers get a briefing on confidentiality, as the MRS code requires its members to provide.^[24]

Ethics beyond the law. The UXPA code asks practitioners not to expose participants to “unreasonable physical, mental or emotional stress” and to take special care with older people, disabled people and children.^[33] Build stop rules into discussion guides for sensitive topics and give researchers a way to escalate a distressed participant.

Cost drivers. Incentives (scale with sessions and audience seniority), recruitment fees (scale with hard-to-reach audiences), tools (mostly per seat or per volume), and people (a step cost). Panels move cost from per-session fees to fixed upkeep; NN/g notes that once a panel is established ongoing recruiting costs fall,^[40] and that specialised panel-management platforms tend to be more expensive than general-purpose tools.^[15]

Capacity. There is no validated staffing ratio. For its first few months, GDS ran with one person for 50 to 60 researchers, by limiting scope and leaning on the privacy and information-management teams; a second person joined in July 2022.^[7] Towsey warns against hiring many administrators without a senior systems designer.^[9] A practical capacity check: list the “keep the lights on” tasks (panel refresh, sweeps, vendor reviews, onboarding) with hours per month; if they exceed about half the team’s time, new services will stall.

Sustainability. Video is the bulk of research storage. Deleting recordings on schedule and keeping short de-identified clips instead of full sessions reduces cost, risk and storage footprint at the same time.

How you know the system works, not just that it exists:

• Monthly sample audit. Pick ten assets at random; trace each to a consent record, a storage location and a deletion date.
• Quarterly sweep. Run the retention and scope checks (Lab 2) across every store, including shared drives.
• Access review. Quarterly, owners confirm who can reach the personal-data zone.
• Participant feedback. A two-question survey after sessions (Was the session as described? Was payment on time?) and a visible complaint route.
• Researcher benchmark. Repeat the GDS-style benchmark survey twice a year.^[7]
• Risk indicators. Rising opt-outs, rising no-shows from one source, a spike in fraud flags, recordings found outside approved storage, and requests bypassing intake.

flowchart TB
  A["Withdrawal received"]:::risk
  B["Log request, acknowledge, start clock"]:::neutral
  C["Find all copies via consent ref and participant ID"]:::core
  D{"Copies outside approved stores?"}:::decision
  E["Delete in stores: recordings, transcripts, clips, notes"]:::core
  F["Owners delete chat posts and deck copies; confirm"]:::core
  G{"Insights depend only on her data?"}:::decision
  H["Retire or rewrite those insights"]:::neutral
  I["Confirm to participant; close with evidence"]:::core
  J["Review: why did clips leave the store?"]:::neutral
  A --> B --> C --> D
  D -->|no| E
  D -->|yes| F --> E
  E --> G
  G -->|yes| H --> I
  G -->|no| I
  I --> J
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

Runbook steps.

1. Log and acknowledge (day 0). Record the request, the consent reference and the date. Acknowledge receipt. Tell the privacy team: rights requests can have statutory deadlines that differ by jurisdiction.
2. Find every copy (day 0–2). Search the restricted store, repository, transcription tool and payout tool by participant ID and consent reference; search chat and slide libraries for the study ID and clip names. The consent record and naming convention are what make this possible; without them, this step fails.
3. Delete outside copies first. Ask owners to delete the chat posts and deck slides and to confirm in writing; copies outside stores are the ones most likely to spread further.
4. Delete stored copies. Recordings, transcripts, clips, notes, panel profile (she withdrew from everything), scheduling data. Keep only the minimum record needed to show the request was handled, as your privacy team advises.
5. Check insights. Insights supported by her session and others stay, without her quotes; insights resting only on her session are retired or rewritten from other evidence.
6. Confirm and close. Tell the participant what was deleted. Record completion time (withdrawal completion time metric).
7. Prevent. Here the root cause was sharing clips beyond the scope she agreed to (her record said research team only). Fix: sharing beyond the team only from the repository, with a scope check, and observer briefings that forbid re-posting clips.

• “ResearchOps means a recruiter.” Recruitment is the most visible pain, not the whole job.^[2] Teams that only fix recruitment create more studies with the same data and knowledge problems.
• Tool first. Buying a repository before deciding who it serves and who maintains it; Towsey’s “knee-jerk operations”.^[9]
• One consent form for everything. It either over-asks (and people decline) or under-informs (and sharing exceeds what people agreed to). Separate purposes, separate choices.
• “We have consent, so we can keep it forever.” Storage limitation still applies,^[22] and GOV.UK suggests 2–3 years for user research data.^[25]
• The panel as a marketing list. Using research opt-ins for promotions destroys trust and the legal basis it rests on.
• Repository as a graveyard. Uploading every report without tags or owners; the repository grows and nobody finds anything.
• Democratisation by announcement. Opening the panel to everyone without contact limits, templates or review produces the over-contacting and poor research NN/g and others warn about.^[19]
• Myth: AI summaries remove the need for synthesis. They speed up first drafts; they do not check themselves against the evidence, and synthetic users are not participants.^[14]
• Myth: anonymised means “first name removed”. A role, company and city can identify a business user; de-identification needs judgement, as Lab 3’s “Dana” shows.

Invest in dedicated ResearchOps when several of these are true: more than a handful of people run studies; recruitment is the critical path for most studies; teams research the same audiences repeatedly; research involves recordings, special-category data or vulnerable groups; people outside the research team want to run studies; and nobody can say where last year’s findings are.

Do not build a ResearchOps function (yet) when:

• One or two researchers run a few studies a quarter. Write the basic policies (consent templates, a retention rule, a storage location), use an agency, and spend the money on research.
• The organisation does not act on research. Operations make research cheaper and safer; they do not create demand. Fix research leadership and advocacy first.
• The real need is a different function: scientific data stewardship (ResearchDataOps), a voice-of-the-customer programme (CXOps), or a product insight-to-roadmap process (ProductOps).

Hidden responsibilities that come with ResearchOps: the panel is a long-lived personal-data asset that needs governance; the repository needs a librarian forever; self-serve research needs a review service; vendor contracts need yearly review.

flowchart TB
  Q1{"3+ people research each quarter?"}:::decision
  Q2{"Recruiting delays most studies?"}:::decision
  Q3{"Sensitive data or groups?"}:::decision
  Q4{"Others want to run studies?"}:::decision
  N["No team: templates, one agency"]:::neutral
  P["Part-time owner, plus governance if sensitive"]:::core
  D["Dedicated ReOps role or team"]:::core
  G["Governance first: tiers, DPIA, audits"]:::risk
  Q1 -->|no| Q3
  Q3 -->|no| N
  Q3 -->|yes| G
  Q1 -->|yes| Q2
  Q2 -->|no| Q4
  Q2 -->|yes| D
  Q4 -->|no| P
  Q4 -->|yes| D
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

The thresholds are this page’s assumptions; the logic is the point. Weighted check for borderline cases: score 0–3 for each of volume of research, recruitment pain, data sensitivity, self-serve demand and knowledge loss (repeated studies). A total of 10 or more out of 15 usually justifies a dedicated role; below 6, a part-time owner is enough.

This is this Atlas’s maturity model, not an official standard.

Most organisations should aim for Level 3 before Level 4: opening research to more people on top of an unreliable ledger multiplies the risk.

Dependencies: privacy counsel time in the first month, a budget decision for tools by day 45, and one product team willing to pilot self-serve. Quick wins matter more than completeness; GDS fixed shared-drive permissions and listed all tooling in one place early.^[7]

Quick start (first week)

• Name one accountable owner for research operations
• List every place research data lives today
• Publish one plain-language information sheet and consent form per common study type
• Choose one approved store for recordings and tell everyone
• Agree the lawful basis per study type (and the Article 9 condition for special-category data) with privacy counsel

Study preflight

• Tier assigned; Tier 3 reviewed before recruiting
• Screener reviewed by the researcher; contact limits checked
• Information sheet version and consent choices match the plan (recording, sharing, panel)
• Accessibility needs asked and planned for; lead time allowed
• Incentive terms stated in the invitation (who, what, when, conditions)
• Observers briefed on confidentiality; recording location set to the approved store

Quarterly governance review

• Retention sweep run across all stores; exceptions closed
• Ten-asset sample audit passed
• Access to the personal-data zone reviewed
• Vendor and subprocessor list reviewed, including AI features
• Scorecard reviewed with research leadership; one improvement chosen

Withdrawal or data incident

• Request logged with consent reference; privacy team informed the same day
• Copies outside stores found and removed first
• Stored copies deleted; dependent insights reviewed
• Participant informed; completion time recorded; root cause fixed

Template 1: one-page ResearchOps charter

ResearchOps charter: <organisation>            Version <n>, <date>, owner <name>
Mission: make research with people easy to start, safe, lawful and reusable.
Serves: <researchers, designers, PMs, ...>          Out of scope: <list>
Services and levels: panel recruitment <x days>; agency recruitment <x weeks>;
  consent templates <same day>; Tier 3 review <x days>; repository onboarding
Policies: consent and permissions; data retention; incentives; panel contact
Metrics: time to recruit; payment latency; ledger exceptions; insight reuse
Governance: monthly scorecard; quarterly sweep and access review; yearly policy review
Escalation: data incidents -> <privacy/security contact> the same day

Template 2: participant information sheet checklist (content, not wording; cross-check with your counsel and, for MRS members, rules 30–31 of the MRS code)^[24]

[ ] Who is running the research, and who the data controller is
[ ] Why: the purpose in one plain sentence
[ ] What happens in the session, and how long it takes
[ ] Recorded? Observed? By whom? Who will see recordings?
[ ] What data is collected, including any special-category data
[ ] How long data is kept, where, and how it is deleted
[ ] Taking part is voluntary; stop or withdraw at any time, and how
[ ] Incentive: what, who pays, when, any conditions
[ ] Separate choices: take part / recording / sharing clips / joining the panel
[ ] Rights and how to complain; contact details

Template 3: insight entry

Insight ID: I-<n>        Status: tentative | validated | retired
Statement (one sentence, no names):
Evidence: <study ID> <timestamp or fact ID>; <study ID> <...>   (2+ studies to validate)
Context: audience, product version, method, date range
Confidence and limits: <who this may not apply to>
Used in decisions: <links>
Review by: <date set from release cycle>     Owner: <librarian or researcher>

Template 4: repository tool decision record

Decision: <tool> for the research repository           Date: <date>  Owner: <name>
Context: <who contributes, who reads, volume, current pain>
Options considered: wiki/document library; database; research platform
Criteria: permissions model; de-identification support; search; contribution effort;
  export and exit; processor terms and AI subprocessors; data residency; cost
Decision and reasons: <...>
Consequences: <training, migration scope, what we will not migrate>
Review date: <date>

Is ResearchOps only for large companies? No, but a large function is. A small team needs the ledger (consent templates, one store, a retention rule) from the first recorded session; it may not need a dedicated person until several people run research.

Should the ResearchOps lead be a researcher? Not necessarily. The community notes that many ResearchOps professionals are not researchers.^[1] The lead needs systems design, service management and enough research knowledge to earn researchers’ trust; recruiters and librarians bring their own specialisms.

Can we pay participants in product credit or our own vouchers? Some teams do, but the UK Market Research Society prohibits client goods or vouchers as incentives for research projects run by its members, and product credit excludes non-customers and may bias feedback.^[24] Cash-equivalent incentives are the safer default.

Should everyone in the company have access to the panel? Access to request participants, yes; direct access to contact data, no. Let the tool enforce contact limits and log who contacted whom.

Do we need a research repository tool? Start with what people already use, as NN/g advises when adoption is the bottleneck.^[13] Buy a specialised tool when contribution effort, permissions or search in the existing tool are the proven limit.

Can AI analyse our interviews? It can draft transcripts, summaries and themes, if the vendor is an approved processor and participants were told. Researchers must still check themes against the evidence. AI-generated “synthetic users” are not a substitute for participants.^[14]

How do we handle a participant who reveals something alarming (self-harm, abuse, a safety issue)? Agree a safeguarding protocol before sensitive studies: what the researcher says, whom they contact, and what is recorded. This is a Tier 3 planning item, not something to improvise in the session.

• Active practice, still settling: AI-assisted transcription and theme sorting inside research platforms; agentic features that recruit and schedule from chat tools (one vendor’s site describes an agent that handles recruitment and scheduling).^[39] The governance questions (processor scope, traceability, consent for AI processing) are not yet answered consistently across vendors.
• AI-moderated sessions: one recruitment marketplace now advertises an “AI Moderator” (tagline: “AI runs the interview”) and a feature in which AI drafts the study (home page, October 2026).^[41] This page’s view: tell participants before the session that an AI conducts it, say so in the information sheet, and treat the model provider as a subprocessor.^[17]
• Contested or speculative: synthetic users as a substitute for participants; NN/g’s evaluation found them unreliable for that purpose.^[14]
• Fraud arms race: marketplace fraud controls and identity checks are improving and so is misrepresentation; expect more verification, and weigh each check against the data it collects.^[27]
• Measuring research impact: linking insights to decisions and outcomes remains hard; the reuse metric above is a practical start, not a solution.

Paths by reader. Beginners: In 30 seconds, the glossary, the participant lifecycle, Lab 1. Practitioners: the playbooks, the artefacts, Labs 2–3, the incident runbook. Leaders and architects: the reference architecture, metrics and worked calculation, decision framework, maturity model and the judgement call below.

The situation. A product organisation has 6 researchers, 50 designers and product managers, and a panel of 3,000 opted-in customers. Requests take two weeks to recruit. Option A: give every designer and PM direct panel access so they can recruit in a day. Option B: keep recruitment as a central service, add recruiters, and target five days.

Assumptions. Most of the 3,000 are administrators of mid-sized customer accounts; customer success already reports invitation fatigue; legitimate interests is the lawful basis for the panel; the tool can enforce contact limits.

Why the attractive option A is risky here. Fifty people recruiting from 3,000 customers without coordination will reach the most responsive few hundred again and again, creating the very over-contacting customer success already sees; NN/g also notes that panel members who know the brand may be more positive than new users,^[15] so more frequent use of the same people skews the evidence. Direct access spreads contact data across many accounts, and enthusiasm for fast research tends to outrun review of screener and question quality, a risk NN/g lists for poorly managed democratisation.^[19]

Why option B is not obviously right either. A central queue keeps control but turns ResearchOps into the bottleneck it was created to remove, and it pushes teams to recruit informally through account managers, which is worse.

Decision under these assumptions: a hybrid. Tier 1 studies get self-serve recruitment through the tool, with contact limits, segment caps and no direct export of contact data; Tier 2–3 and any study targeting small segments stay central. Review after one quarter using contact-limit breaches, opt-out rate, time to recruit and a spot check of self-serve study quality. If opt-outs rise noticeably, shrink self-serve to fewer segments. This is a reasoned recommendation, not a tested result.

After this page you should be able to explain what ResearchOps covers and how the label differs from academic research operations; distinguish permission to take part from the lawful basis for processing; design a participant lifecycle with erasure and contact limits; choose repository types and retirement rules; calculate time to recruit, no-show rate and cost per completed session; run a consent and retention audit; and decide how much ResearchOps an organisation needs.

ResearchOps earns its name when research stops depending on heroics. The visible work is recruitment, and it matters: studies that cannot find participants do not happen. The work that decides whether research can be trusted is quieter. It is a ledger that links every recording to what a person agreed to, a retention schedule that is actually run, a panel that protects its members from over-contact, and a repository where insights carry their evidence and are retired when they stop being true.

The label is established within UX research. The profession is still young, and much of its literature comes from practitioners and vendors rather than standards bodies, so judge advice by its sources. Start with the ledger, measure service and safety, build self-serve research on top of control rather than instead of it, and remember that every operational shortcut is paid for either by the people who gave you their time or by the next team that cannot find what you learned.

All sources were opened on 2026-10-23 unless the ledger (research/researchops-ledger.md) says otherwise. Legal sources are for orientation; check the official text (for EU law, EUR-Lex) and your counsel before relying on them.

Further reading (not opened for this page):

• Kate Towsey, Research That Scales: The Research Operations Handbook (Rosenfeld Media, 2024).
• The ResearchOps Community’s framework and workshop articles on Medium (blocked for automated access on 2026-10-23).

Changelog. Legal and tool rows are due for re-verification by 2027-01-23.

• 2026-10-23, first version: researched, drafted and labs executed on synthetic data; awaiting independent fact check.
• 2026-10-23, round 1 revision after the independent review (reviews/researchops-r1.md): corrected the community pillar count (eight) and the NN/g “8× or lower” quote; added the GDPR Article 9 condition (text, glossary, consent record, privacy table); fixed GDS, WeWork and BU attributions; added NN/g’s DesignOps view, AI moderation and automated redaction; Tier 1 now includes recordings in the approved store; Lab 1 no longer counts cancellations; redrew the lifecycle, sequence, architecture and decision figures.
• 2026-10-23, post-score polish: Article 9(2)(j) scope and UK condition 4; KPI, Lab 1 and panel policy aligned on no-shows; Figure 2 labels and Figure 8 text equivalent.