--- title: "ResearchOps" slug: researchops category: product term_status: established evidence_status: partially_verified summary: "ResearchOps (research operations) is the people, processes and tools that let an organisation run user research safely and repeatedly: recruiting and paying participants, managing consent and data, and keeping insights findable." audience: [Beginners, UX researchers, ResearchOps managers and recruiters, Design and product leaders, Privacy and legal partners] last_verified: 2026-10-23 key_takeaways: - "ResearchOps is an established label within UX and product research, with a practitioner community, published models and a 2024 handbook; outside UX, \"research operations\" means unrelated research administration." - "It runs two supply chains: participants into sessions (recruit, consent, schedule, pay, protect) and evidence into decisions (store, tag, find, reuse, retire)." - "Consent to take part and the legal basis for processing data are different things; decide both, record both, and make withdrawal as easy as agreeing." - "A repository fails without an owner, a small taxonomy and a retirement rule for insights; the tool matters less than the contribution effort." - "Letting non-researchers do research works only inside guardrails: risk tiers, templates, shared panels with contact limits, and review for the hard cases." - "Measure service and safety (time to recruit, no-show rate, payment latency, consent and retention exceptions, reuse), not the number of studies." related: [designops, productops, researchdataops, privacyops, knowledgeops, cxops] --- ## What ResearchOps is ### In 30 seconds **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."[^reops-about] 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."[^nng-101] 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**. ::: warning Disambiguation: three different things share this name 1. **ResearchOps (this page):** operations for **user research** (UX, design and product research with people). 2. **Research operations in universities and hospitals:** research administration, grants, clinical-trial support. For example, a medical school's internal-medicine department runs a central "Comprehensive Integrated Research Operations" unit that combines research operations (recruitment, procurement, events) with research administration and clinical research administration.[^kumc] This page does not cover it. 3. **Research data operations:** stewardship of scientific data, or clinical data management (one research institute's "Research Data Operations" builds study databases and randomisation systems).[^phri] Scientific data stewardship is on [ResearchDataOps](../researchdataops/), which is unrelated despite the similar name. ::: ### At a glance | Question | Answer | |---|---| | Goal | Research that is faster to start, ethical and lawful, and reusable after the study ends | | Who uses it | UX and product researchers, designers and product managers who run studies, research leaders, recruiters, privacy teams | | In scope | Participant recruitment and panels, screening, scheduling, incentives, consent and permissions, research data handling and retention, repositories and insight management, research tools and vendors, enabling non-researchers, research budget and metrics | | Out of scope | Scientific data under FAIR principles → [ResearchDataOps](../researchdataops/); design systems → [DesignOps](../designops/); product analytics and the roadmap pipeline → [ProductOps](../productops/); the privacy programme and data-protection law → [PrivacyOps](../privacyops/); journey-wide voice of the customer → [CXOps](../cxops/) | | Prerequisites | Basic knowledge of how user research works (interviews, usability tests, surveys); no technical prerequisites | | Key outputs | A participant panel and recruitment service, consent and data policies with evidence, a research repository, an intake and support service, tool contracts, a metrics scorecard | | Term status | **Established** within UX and product research; a young profession (see below) | ### Term status and why the label is established 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).[^reops-about] - **Independent definitions and teaching.** NN/g published a six-part model in 2020, built from interviews with DesignOps and ResearchOps practitioners.[^nng-101] - **A handbook.** Kate Towsey's *Research That Scales: The Research Operations Handbook* (Rosenfeld Media, 17 September 2024, 336 pages) codifies the practice.[^kirkus] - **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.[^gds-2019][^gds-2023][^dfe-2020] Two honest qualifications. First, the community itself calls ResearchOps "an emergent profession in its own right":[^reops-about] 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. ### The problem it solves 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.[^gds-2019] 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".[^nng-101] 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. ### What ResearchOps is not - **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.[^nng-101] - **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).[^reops-about] 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".[^rally-towsey] - **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. ## Vocabulary, origins and neighbours ### Origins and evolution 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".[^wework] - **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.[^reops-about] - **2019.** GDS visited research teams at the DVLA, DWP and HMRC and listed the operational support they needed.[^gds-2019] GitLab replaced research reports with an insights repository built from GitLab issues.[^gitlab-uxr] The community started its Research Skills Framework project.[^reops-rsf] - **2020.** NN/g published its six-part ResearchOps model.[^nng-101] During the first COVID-19 lockdown, DfE formed a research operations team within a week and recruited over 250 users in four months.[^dfe-2020] - **2022.** GDS set up a research operations function; for its first few months, one person supported 50 to 60 researchers.[^gds-2023] - **2024.** Towsey's handbook was published;[^kirkus] NN/g published guidance on research repositories[^nng-repos] and an evaluation of AI-generated "synthetic users".[^nng-synthetic] ### Three maps of the same territory Three published models describe the scope. They overlap heavily; their differences are useful. | ResearchOps Community (labels as printed)[^reops-about] | NN/g six focus areas[^nng-101] | Towsey's eight elements (as described in her interview)[^rally-towsey] | |---|---|---| | Environment · Scope · People · Organisational context | Advocacy | Program management · people and skills | | Recruitment and admin | Participants | Participant recruitment · money and metrics | | Data and knowledge management | Knowledge | Knowledge management | | Governance | Governance | Ethics and privacy | | Tools and infrastructure | Tools | Tools and vendors | | — | Competency | Onboarding and support | 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.[^reops-about] 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. ### Glossary and mental model | Term | Meaning on this page | Example | |---|---|---| | Participant | A person who takes part in a study (customer, prospect, member of the public, employee) | A small-business owner in a 45-minute interview | | Screener | Questions that decide whether a candidate matches the study criteria | "Which accounting tool do you use today?" | | Panel | A curated group of people who opted in to be contacted for future research[^nng-panels] | 2,000 customers who ticked "contact me for research" | | Recruitment agency / marketplace | An external supplier that finds participants for a fee | Used for people who are not your customers | | Incentive | Payment or gift that thanks participants for their time | A voucher sent the day of the session | | Permission to take part | The participant's agreement to join a session, after being told who, why, how long, recording and observers | An information sheet and a signed form | | Lawful basis | The legal ground for processing personal data under data-protection law (consent is one of several) | Legitimate interests for storing contact details in a panel | | Special-category data | Data such as health or ethnicity; under the GDPR its processing is prohibited unless an Article 9 condition applies, in addition to a lawful basis[^gdpr-9] | Recruiting people with a disability | | Controller / processor | The controller decides why and how personal data is processed; a processor handles it on the controller's behalf[^gdpr-28] | Your company (controller); a transcription vendor (processor) | | DPIA | Data protection impact assessment: a documented risk assessment the GDPR requires before likely high-risk processing[^gdpr-35] | Before a study that collects health data | | Research repository | A central place where research artefacts and outputs are stored so others can find them[^nng-repos] | A searchable insights database | | Nugget / atomic insight | One observation with its evidence and tags[^wework] | "Admins wait for a colleague before setup" + two clips | | Retention schedule | How long each kind of research data is kept and how it is destroyed | Recordings: 24 months; consent records: as long as the data they cover | | People who do research (PwDR) | Non-researchers who run studies, such as designers and product managers[^nng-democratize] | A PM running five usability tests | | Intake | The front door where teams request research support | A form that routes a request to a tier | #### A mental model: two supply chains and a ledger 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. ### How ResearchOps relates to other Ops ::: figure ResearchOps and its neighbours: what crosses each boundary ```mermaid 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 ``` Text equivalent: ResearchOps sits in the centre. ProductOps sends research requests and CXOps sends candidate questions into it, and ResearchOps sends evidence back to ProductOps. ResearchOps exchanges policy and approvals with PrivacyOps, shares its repository practice with KnowledgeOps, and shares tools and budget with DesignOps. ResearchDataOps, which handles scientific data, is linked only by a dotted line labelled "name only": it shares the word "research" but is not part of this chain. ::: | Neighbour | Shared scope | What ResearchOps owns | What the neighbour owns | |---|---|---|---| | [DesignOps](../designops/) | Often one team in smaller organisations; shared tools and budget | Participants, consent, research data, repository | Design systems, design team health and tooling | | [ProductOps](../productops/) | Turning customer insight into roadmap decisions | Producing and storing trustworthy evidence | Product analytics, the insight-to-roadmap process | | [CXOps](../cxops/) | Customer feedback | Studies with recruited participants | The cross-journey voice-of-the-customer loop, surveys at scale | | [PrivacyOps](../privacyops/) | Personal data of participants | Applying privacy policy to research, keeping consent evidence | The privacy programme, lawful-basis decisions, DPIAs, rights requests | | [KnowledgeOps](../knowledgeops/) | Knowledge that must be findable and kept current | The research repository | Knowledge practice across the organisation | | [ResearchDataOps](../researchdataops/) | The word "research" | Nothing in common | FAIR stewardship of scientific data | 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".[^nng-dofaq] 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](../designops/)) is the same on both pages. ## Principles and operating model ### Charter and principles 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.[^reops-about] 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.[^rally-towsey] 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;[^rally-towsey] 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. ### Fundamentals and building blocks | Building block | What it is | Minimum viable version | Mature version | |---|---|---|---| | Intake and service catalogue | How teams ask for help and what they can get | A form and a shared inbox | Tiered catalogue with service levels and self-serve paths | | Participant sourcing | Where participants come from | One agency plus a customer opt-in list | Governed panel plus agencies and marketplaces for reach | | Consent and permissions | What participants are told and agree to | A plain-language information sheet and form per study type | Versioned templates, consent records linked to every asset | | Scheduling and logistics | Getting people and observers into sessions | Shared calendar link and a session checklist | Integrated scheduling, reminders, accessibility support | | Incentives | Thanking participants | Vouchers sent by one owner | Policy with rates by audience, payout tool, tax and anti-fraud checks | | Research data management | Where data lives and when it dies | Approved folder structure and a retention rule | Retention schedule, automated sweeps, access reviews | | Repository | Where knowledge lives | A document library with a naming convention | An insight database linked to studies and decisions | | Enablement | Helping non-researchers research | Templates and office hours | Training path, risk tiers, review service | | Money and metrics | Budget and evidence of value | A spend log | Scorecard, unit costs, quarterly review | ### Roles, ownership and RACI 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".[^reops-repos] - **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. | Activity | ResearchOps lead | Recruiter / panel | Librarian | Researcher or PwDR | Privacy / legal | |---|---|---|---|---|---| | Research data and consent policy | A | C | C | C | R (lawful basis) | | Study risk tiering | A | I | I | R (self-assess) | C (high tier) | | Recruitment and screening | A | R | I | C (criteria) | I | | Consent records and incentives | A | R | I | R (in session) | C | | Session conduct and notes | I | I | I | A/R | I | | Repository entries and tags | A | I | R (quality) | R (content) | I | | Retention sweeps and deletion | A | R (panel data) | R (repository) | R (own files) | C | | Withdrawal and rights requests | A | R | R | R | C (statutory deadlines) | 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. ### The participant lifecycle ::: figure Participant lifecycle: states and the events that move a person between them ```mermaid 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 --> [*] ``` Text equivalent: a person enters as a candidate through sign-up or referral and becomes screened when they answer the screener. Screened people who do not match are excluded and their screener data deleted. Those who match and agree are booked; booked people either attend or miss the session. Attendees are paid (the payout is confirmed); they then either join the panel, if they opted in to future contact, or have their contact data erased. No-shows who opted in to the panel stay in it with a flag; other no-shows have their contact data erased. Panel members can be invited again within the contact limit, and leave the panel when they opt out or when the retention period ends. "Contact data erased" covers contact and screener details; recordings and notes follow the retention schedule. ::: 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](#reference-implementation-operating-artefacts)); storage limitation is a data-protection principle in the GDPR.[^gdpr-5] - **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.[^nng-panels] ### Operating model and governance **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),[^govuk-find] 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. ::: figure Study risk tiering: which path a research request takes ```mermaid 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 ``` Text equivalent: a new request is checked in order. If it involves children, vulnerable people or special-category data, it goes to Tier 3, review by ResearchOps and privacy before recruiting. Otherwise, if it involves a sensitive topic, deception or covert observation, it also goes to Tier 3. Otherwise, if material will be shared beyond the research team or kept in a tool that is not on the approved list, it goes to Tier 2: standard templates plus a ResearchOps check. Everything else is Tier 1: self-serve with templates, recordings kept in the approved store, and panel contact limits. ::: 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,[^gdpr-9] 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).[^mrs] **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](#worked-incident-a-withdrawal-after-clips-were-shared) shows the flow. ## Architecture and workflow ### Reference architecture: the research operations stack This is a logical architecture: the components are capabilities, and one product may provide several of them. ::: figure Reference architecture for research operations, with the personal-data boundary ```mermaid 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 ``` Text equivalent: the intake form and service catalogue form the front door and feed screeners and scheduling. A restricted personal-data zone holds panel and participant records, screeners and scheduling, consent records, incentive payouts, and recordings and transcripts (highlighted as the highest risk). Panel records feed screening; screening leads to consent records and to incentive payouts; consent records govern recordings. Only de-identified extracts cross from recordings into the knowledge zone, which has wide access and holds the repository of studies and insights, which in turn feeds decisions. A dotted line from consent records to the repository carries the sharing scope and deletion dates. ::: 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.[^nng-repos] GOV.UK recommends fully anonymising extracts whenever possible.[^govuk-data] - **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.[^gdpr-28] That includes AI transcription and analysis features. ### End-to-end workflow: one study from request to reuse ::: figure Sequence of one study, with the withdrawal exception ```mermaid 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 ``` Text equivalent: the product team requests research through intake, and the request gets a tier. ResearchOps sends the participant a screener and information sheet; the participant agrees to take part and to be recorded. ResearchOps gives the team booked sessions and an observer brief, and gives the participant the incentive at the start of the session, as the incentive policy recommends. The team runs and records the session. The team adds de-identified insights with tags to the repository, where they are found and reused months later. In the exception path, the participant withdraws consent; ResearchOps then deletes that participant's data and every copy, including any in the repository (the [withdrawal runbook](#worked-incident-a-withdrawal-after-clips-were-shared) shows the steps). ::: **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.[^mrs] 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.[^govuk-find] 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](#playbook-recruitment-panels-and-fraud)), 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).[^mrs] ## Practices and playbooks | Practice | Goal | Trigger | Owner | Output | Verification | |---|---|---|---|---|---| | Recruitment and panel management | Right people, quickly, without over-contacting | Booked request | Recruiter | Booked sessions | Time to recruit, no-show rate, contact-limit breaches | | Consent and permissions | Participants know and agree; evidence exists | Every study | Researcher, with templates from ResearchOps | Consent record per participant | Monthly sample of assets matched to records | | Incentives | Fair, prompt, lawful payment | Session held | Recruiter | Payout record | Payment latency, failed payouts | | Research data management | Minimum data, approved places, deleted on time | Study end; quarterly sweep | ResearchOps lead | Retention log | Assets past deletion date (target 0) | | Repository and knowledge | Findable, current insights | Study synthesis | Librarian | Insight entries | Reuse rate, stale-insight count | | Enablement | Non-researchers research safely | Training request; tier-1 study | ResearchOps lead | Trained people, reviewed plans | Review findings, quality spot checks | ### Playbook: recruitment, panels and fraud **Choose the source by audience, not habit.** Each source has a different bias, cost and speed: | Source | Strong for | Watch out for | |---|---|---| | Own panel (opted-in customers) | Speed, existing users, repeat access | Brand familiarity and positivity; the same people every time[^nng-panels] | | Agency | General public, hard-to-reach groups, people with access needs | Lead time and fees; brief them on disability screeners[^govuk-find] | | Self-serve marketplace | Professionals and niche consumer profiles, fast turnaround | Professional participants and fraud; verify carefully | | Intercepts and community partners | People who do not sign up for panels | Consent in context; partner relationships take time (DfE used charities and education networks)[^dfe-2020] | | Colleagues | Pilots of materials only | Not representative; GOV.UK advises against using your own staff for public-facing research[^govuk-find] | NN/g's guidance on panels is that it is "not a choice between internal panels and external recruiting; many teams use both."[^nng-panels] **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."[^govuk-find] **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.[^nng-panels] **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).[^nng-problem] 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.[^nng-problem] 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.[^bu-fraud] 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. ::: caution Fraud controls collect data too Identity checks are personal data processing. In video baseline interviews the clinical study team requested, but did not require, that participants show photo ID on screen, and did not request electronic copies of IDs.[^bu-fraud] Prefer checks that are optional where possible and leave no new copy of sensitive documents. ::: ### Playbook: consent, permission and lawful basis 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".[^govuk-consent] 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).[^ico-lawful] 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.[^mrs] 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".[^hra] 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."[^gdpr-7] 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),[^hra] 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.[^gdpr-9] 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".[^ico-special] 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).[^govuk-consent] - 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).[^govuk-consent] - A withdrawal procedure that reaches every copy (see the [worked incident](#worked-incident-a-withdrawal-after-clips-were-shared)). - A trigger for a data protection impact assessment (DPIA) when processing is "likely to result in a high risk" to people,[^gdpr-35] for example studies with health data or children. ::: note Not legal advice Statements here describe the EU GDPR and UK guidance as of October 2026. Other jurisdictions (for example US state privacy laws, India's Digital Personal Data Protection Act, Brazil's LGPD) differ. Confirm the legal basis, notices and retention with your privacy counsel; check the official GDPR text on EUR-Lex. ::: ### Playbook: incentives - **Set rates by audience and time.** NN/g recommends frameworks for "fair and consistent incentive levels based on participant expertise and required time investment".[^nng-101] 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.[^mrs] - **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).[^mrs] - **Avoid coercive amounts.** The UXPA code asks practitioners to avoid "excessive or inappropriate" inducements.[^uxpa] - **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.[^govuk-find] - **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).[^irs] 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. ### Playbook: research data management 1. **Collect the minimum.** GOV.UK asks teams to collect "the minimum information you need to manage their participation".[^govuk-data] 2. **Store only in approved places.** Move recordings off devices to approved storage quickly.[^govuk-data] 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.[^govuk-data] 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.[^gdpr-4] 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. ### Playbook: repository and knowledge management **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".[^nng-repos] 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."[^wework] Daniel Pidcock's "Atomic UX Research" (the concept his company Glean.ly builds on)[^gleanly] chains experiments, facts, insights and conclusions; some write-ups say recommendations for the last step.[^maze-atomic] GitLab adapted the idea in 2019 with light synthesis before an insight is added, which is why it calls entries insights rather than nuggets.[^gitlab-uxr] 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. ::: figure From session to decision: the evidence chain and where each link expires ```mermaid 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 ``` Text equivalent: a session recording sits in restricted storage for two to three years. Facts are extracted from it with identifiers removed; facts are synthesised into an insight supported by two or more sources; decision records cite the insight. The insight is periodically checked: if it is still true after product changes, it stays; if not, it is retired while the decision history is kept. ::: 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.[^nng-repos] 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.[^nng-repos] 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.[^gds-2023] ### Playbook: enabling people who do research 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.[^nng-democratize] 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".[^nng-democratize] 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";[^rally-selfserve] 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.[^nng-democratize] ## Frameworks, ethics codes and tools ### Methods, standards and frameworks Separate what binds you from what guides you. | Source | Type | What it gives ResearchOps | Binding on | |---|---|---|---| | GDPR (EU) / UK GDPR | Law | Principles (minimisation, storage limitation), conditions for consent, special categories, DPIAs, processor contracts[^gdpr-5][^gdpr-7][^gdpr-9][^gdpr-35][^gdpr-28] | Controllers and processors in scope | | ICO guide to lawful basis (UK) | Regulator guidance | How to choose and document the lawful basis[^ico-lawful] | Interprets UK law | | MRS Code of Conduct 2023 (UK) | Professional code | Permission vs consent, children, incentives, observers, retention[^mrs] | MRS members and company partners | | UXPA Code of Professional Conduct | Professional code | Informed consent, confidentiality, avoiding harm and excessive inducements[^uxpa] | UXPA members (voluntary) | | GOV.UK Service Manual (user research) | Government guidance | Consent, data handling, recruitment, accessibility lead times[^govuk-consent][^govuk-data][^govuk-find] | UK government services; useful elsewhere | | ResearchOps Community model, NN/g model, Towsey's elements | Practitioner frameworks | Scope maps for planning and gap analysis[^reops-about][^nng-101][^rally-towsey] | Nobody; adapt freely | 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. ### Tooling landscape 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. | Tool category | Job it does | Examples (as of October 2026) | Selection criteria | Risks | |---|---|---|---|---| | Participant CRM and panel management | Store opted-in people, history, contact rules | Rally (describes "built-in consent tracking, engagement rules, and access controls");[^rally-home] spreadsheets or CRMs such as Salesforce or HubSpot in smaller teams[^nng-pdb] | Consent fields, contact limits, deletion, access control, data residency | Panel becomes an unmanaged marketing list | | Recruitment marketplaces and agencies | Find people outside your customer base | Respondent (a recruitment platform with screening, scheduling and fraud checks)[^respondent]; specialist agencies | Audience reach, fraud controls, accessibility support, who pays incentives | Professional participants; unclear processor terms | | Scheduling and session tools | Booking, reminders, recording | Calendar and video tools; built into many research platforms | Accessibility, recording controls, storage location | Recordings land in personal cloud accounts | | Incentive payout | Pay participants globally | Tremendous (payouts including research incentives, gift cards, bank and wallet transfers)[^tremendous] | Countries, methods, fraud checks, records for tax | Paying fraudsters; collecting bank data you do not need | | Repository and analysis | Store, transcribe, tag, synthesise, share | Dovetail (describes automatic transcription, AI theme sorting and automatic redaction of names, faces and voices);[^dovetail] Glean.ly (atomic model);[^gleanly] collaboration wikis or databases[^nng-repos] | Permissions, de-identification, search, integrations, export | Raw recordings in a widely shared tool; trusting automatic redaction without human review (see Lab 3) | | Consent and forms | Information sheets, consent capture, records | Form tools; the community's consent form builder (beta)[^reops-repos] | Versioning, link to participant ID, withdrawal handling | Consent stored as unsearchable PDFs | **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).[^nng-repos] ### Automation and AI 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.[^gdpr-28] 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.[^nng-synthetic] ## ResearchOps in practice ### Reference implementation: operating artefacts 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._ ```yaml 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._ ```json { "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](#playbook-consent-permission-and-lawful-basis) executable. **Artefact 3: retention schedule.** | Data | Where | Keep for | Then | Owner | |---|---|---|---|---| | Screener answers, excluded candidates | Recruitment tool | 30 days after study recruitment closes | Delete | Recruiter | | Contact details, one-off participants | Participant records | Until incentive paid and any queries closed (about 90 days) | Delete | Recruiter | | Panel member profile | Panel tool | While opted in; re-confirm yearly | Delete on opt-out or no re-confirmation | Panel manager | | Recordings and raw transcripts | Restricted storage | 24 months (GOV.UK suggests 2–3 years as reasonable)[^govuk-data] | Delete, including copies | Study researcher | | Consent records | Consent store | As long as the data they cover, plus the period your counsel advises for evidence | Delete | ResearchOps lead | | Payout records | Payout tool / finance | As finance and tax rules require | Per finance policy | Finance | | De-identified insights | Repository | While true | Retire (archive) | Librarian | 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._ ```yaml 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 ``` ### Hands-on labs 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. ::: warning Never practise on real participant data Real participant data needs an approved purpose, approved storage and access control. Do not export a panel or consent records to a laptop for these labs. ::: #### Lab 1 (beginner): recruitment funnel, time to recruit and panel contact load **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)._ ```bash 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)._ ```python """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.** ```text 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`. #### Lab 2 (intermediate): consent and retention audit in SQL **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)._ ```sql -- 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)._ ```python """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.** ```text 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. #### Lab 3 (advanced): insight hygiene review **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._ ```json { "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)._ ```python """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.** ```text 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. ### Use cases and scenarios #### Scenario 1: one person standing up research operations for 50–60 researchers (documented, GDS 2022) **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.[^gds-2023] **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".[^gds-2023] **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. #### Scenario 2: a crisis research operations team (documented, DfE 2020) **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."[^dfe-2020] **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.[^dfe-2020] **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. #### Scenario 3: replacing reports with an insights repository (documented, GitLab 2019) **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.[^gitlab-uxr] **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".[^gitlab-uxr] **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). #### Scenario 4: self-serve research in a B2B software company (illustrative) ::: example Illustrative scenario: guardrails before scale A 600-person software company has 4 researchers and about 40 designers and product managers who want to talk to customers. Customer success complains that the same 30 administrators receive research invitations every month. ResearchOps introduces the risk tiers, gives Tier 1 teams panel access through a tool that enforces two invitations per 90 days, provides interview and usability-test templates, and runs weekly office hours. Tier 2 and 3 studies get a review. Success criteria for the first two quarters: median time to recruit for Tier 1 under 7 days; no panel member above the contact limit; zero assets without consent records in the quarterly audit; at least half of new insights from PwDR studies reviewed by a researcher before they are tagged as validated. Pitfall to watch: the panel shrinks if opt-outs rise; track opt-out rate monthly. ::: #### Scenario 5: research with participants who have access needs (illustrative, grounded in GOV.UK guidance) ::: example Illustrative scenario: planning lead times and support A public-facing service must test with screen-reader users and people with cognitive impairments. ResearchOps contacts disability organisations at least a month ahead (GOV.UK suggests 6–8 weeks for less common cognitive disabilities), asks each participant their preferred contact method, communication support and assistive-technology needs, budgets for helpers or interpreters, and offers consent read aloud or recorded verbally.[^govuk-find][^govuk-consent] Success criteria: every planned profile recruited, no session cancelled for missing support, consent evidence for every participant. Pitfall: treating access needs as a screener checkbox rather than a logistics plan. ::: ## Measure, protect and pay for it ### Metrics and KPIs 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. | KPI | Definition / formula | Data source | Pitfall | Cadence | |---|---|---|---|---| | Time to recruit | Median days from accepted request to the booking that fills the last needed session | Intake + scheduling | Counting cancellations, or no-shows when they are frequent, as fills flatters the number (Lab 1) | Monthly | | Fill-by-date rate | Studies fully booked by the requester's date ÷ studies requested | Intake | Requesters pad dates once they learn the target | Monthly | | No-show rate | No-shows ÷ (attended + no-shows) | Scheduling | Mixing cancellations with no-shows | Monthly, by source | | Payment latency | Median days from session to incentive received; % within the promised time | Payout tool | Measuring "sent", not "received" | Monthly | | Contact-limit breaches | Panel members invited above policy in the period | Panel tool | Breaches outside the tool (personal email) are invisible | Monthly | | Ledger exceptions | Assets without a consent record + assets past deletion date + open withdrawals older than the target | Audit query (Lab 2) | Auditing only the repository, not laptops and chat tools | Quarterly (target 0) | | Withdrawal completion time | Days from withdrawal request to confirmed deletion of all copies | Request log | Ignoring copies in slides and chat | Per request | | Insight reuse rate | Sampled decision documents citing at least one repository insight ÷ documents sampled | Sample of product briefs | Counting views instead of citations | Quarterly | | Stale-insight share | Insights whose newest evidence is older than the threshold ÷ all active insights | Repository (Lab 3) | Threshold not tied to product change speed | Quarterly | | Cost per completed session | (Incentives + recruitment fees + tool share + ResearchOps staff share) ÷ completed sessions | Finance + scheduling | Comparing across very different methods | Quarterly | | Researcher time on operations | Self-reported share of week on operational tasks, before and after | Short survey (GDS benchmarked with agreement ratings and "three words";[^gds-2023] the time-share question is this page's addition) | Survey fatigue; use a few fixed questions | Twice a year | **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. #### Worked calculation: cost per completed session and the economies-of-scale test ::: example Illustrative numbers for one quarter (currency units unspecified) - Completed sessions: 48; no-shows: 6. **No-show rate** = 6 ÷ (48 + 6) = 11.1%. - Incentives: 48 × 60 = 2,880, plus 2 no-shows paid under the panel policy × 60 = 120 → 3,000. - Agency fees: 20 agency-recruited sessions × 90 = 1,800 (the other 28 came from the panel). - Tools: 9,000 a year → 2,250 a quarter. - ResearchOps staff: half of one person at 22,500 a quarter → 11,250. - **Cost per completed session** = (3,000 + 1,800 + 2,250 + 11,250) ÷ 48 = 18,300 ÷ 48 = **381**. Now double the volume to 96 sessions with the same staff and tools, the same panel share (56 panel, 40 agency) and the same no-show pattern: incentives 6,000, agency fees 3,600, tools 2,250, staff 11,250 → 23,100 ÷ 96 = **241** per session. Twice the research for 1.26 times the cost: the economies-of-scale effect NN/g sets as the goal.[^nng-101] If instead the panel cannot supply more people (it stays at 28 sessions) and every extra session goes through the agency (68 agency sessions), agency fees become 6,120 and the cost is 25,620 ÷ 96 = 267: still economical, but now dependent on one supplier. The calculation shows where to invest next (panel growth) and what the staffing share hides: one half-time person may not handle twice the volume, which is the capacity question below. ::: ### Privacy, ethics and compliance What applies depends on who you research, where and on what. Common obligations and their operational answers: | Obligation (example jurisdiction) | Operational answer | |---|---| | Lawful basis decided before processing; can rarely switch from consent later (UK, ICO guide 2026-04-02)[^ico-lawful] | Basis set per study type by privacy counsel and stored in consent records | | Demonstrate consent and make withdrawal as easy as giving it, when consent is the basis (EU/UK GDPR Art. 7)[^gdpr-7] | Consent records linked to assets; one-step withdrawal channel; deletion runbook | | Data minimisation and storage limitation (GDPR Art. 5)[^gdpr-5] | Screener and intake fields reviewed; retention schedule; quarterly sweep | | Special categories, e.g. health, ethnicity, sexual orientation: prohibited unless an Art. 9(2) condition applies, on top of the lawful basis (GDPR Art. 9)[^gdpr-9] | Tier 3 review; counsel records the Art. 9 condition (often explicit consent) in the consent record; collect only when the research question needs it; stricter access | | DPIA where processing is likely to be high risk (GDPR Art. 35)[^gdpr-35] | Tier 3 triggers a DPIA screening with the privacy team | | Processor guarantees for vendors (GDPR Art. 28)[^gdpr-28] | Vendor review checklist; subprocessor list includes AI model providers | | Children: verified permission from a responsible adult (UK, MRS code for its members)[^mrs] | Age question first; responsible-adult consent recorded by name and relationship | | Employees as participants: power imbalance | Voluntary participation in fact as well as on paper; GOV.UK requires their consent to take part too;[^govuk-consent] consent is not an appropriate legal basis where there is an imbalance of power,[^hra] so agree another basis with counsel; avoid their managers as observers | **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.[^mrs] **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.[^uxpa] Build stop rules into discussion guides for sensitive topics and give researchers a way to escalate a distressed participant. ### Cost, capacity and sustainability **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,[^nng-pdb] and that specialised panel-management platforms tend to be more expensive than general-purpose tools.[^nng-panels] **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.[^gds-2023] Towsey warns against hiring many administrators without a senior systems designer.[^rally-towsey] 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. ### Assurance of the operating model 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.[^gds-2023] - **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. ## When things go wrong ### Common failures and troubleshooting | Symptom | Likely cause | Diagnosis | Remediation | Prevention | |---|---|---|---|---| | Studies wait weeks for participants | Recruiting from scratch each time; one supplier | Time to recruit by source | Add a panel for frequent audiences; second supplier | Service levels by tier; forecast demand quarterly | | Same customers in every study | No contact limit; panel too small | Contact-load report (Lab 1) | Enforce limits in the tool; recruit fresh segments | Policy plus tooling, not reminders | | No-shows above 20% | Weak reminders, long lead times, incentive only after session | No-show rate by source and lead time | Reminders 24 h and 1 h before; reserve participants | Shorter booking windows | | Suspicious participants in remote studies | Marketplace fraud, gameable screener | Task times, duplicate payment details, inconsistent answers[^nng-problem] | Remove data from cheaters, report to supplier | Behavioural screeners, camera-on screening for high incentives | | Recordings found on laptops and in chat | No approved store or it is inconvenient | Sweep and survey | Move or delete; fix the upload path | Make the approved path the easiest path | | Nobody uses the repository | High contribution effort, no owner, too many tags | Contributions and searches per month | Name a librarian; cut the taxonomy; seed with the most useful items | Start simple and onboard teams[^nng-repos] | | Insights contradict each other | Old insights never retired | Stale-insight share (Lab 3) | Re-validate or retire | Review threshold tied to release cycle | | Incentives late or lost | Manual payouts, unclear owner | Payment latency | One owner and a payout tool | Pay at session start where possible[^govuk-find] | ### Worked incident: a withdrawal after clips were shared ::: example Illustrative scenario A participant in a recorded interview emails three weeks later: "Please delete everything about me." Her study used consent as the lawful basis. Two clips of her session were posted in a product channel and used in a quarterly review deck. ::: ::: figure Runbook: handling a withdrawal when copies exist outside the repository ```mermaid 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 ``` Text equivalent: when a withdrawal arrives, log it, acknowledge it and start the clock. Find all copies using the consent reference and participant ID. If copies exist outside approved stores, their owners delete the chat posts and deck copies and confirm; then delete the copies in the stores (recordings, transcripts, clips, notes). If any insights depend only on her data, retire or rewrite them. Confirm completion to the participant and close the case with evidence, then review why clips left the store. ::: **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. ### Anti-patterns and myths - **"ResearchOps means a recruiter."** Recruitment is the most visible pain, not the whole job.[^nng-101] 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".[^rally-towsey] - **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,[^gdpr-5] and GOV.UK suggests 2–3 years for user research data.[^govuk-data] - **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.[^nng-democratize] - **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.[^nng-synthetic] - **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. ## Deciding and adopting ### When to use and when not to use **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](../researchdataops/)), a voice-of-the-customer programme ([CXOps](../cxops/)), or a product insight-to-roadmap process ([ProductOps](../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. ### Decision framework ::: figure Decision tree: what level of research operations to build, including not building a team ```mermaid 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 ``` Text equivalent: first ask whether three or more people run research each quarter. If not, ask whether research involves sensitive data or groups: if not, build no team, only templates and one agency; if so, add governance first (risk tiers, a DPIA trigger and audits). If three or more people do run research, ask whether recruitment delays most studies: if yes, build a dedicated ResearchOps role or team. If not, ask whether non-researchers want to run studies: if yes, build a dedicated role or team; if no, a part-time owner is enough, plus the same governance step if research involves sensitive data or groups. ::: 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. ### Maturity model This is **this Atlas's maturity model**, not an official standard. | Level | Observable behaviours | Evidence | Exit criteria (to move up) | |---|---|---|---| | 1. Ad hoc | Each researcher recruits, stores and pays their own way | None centrally | A named owner; consent templates; one approved store | | 2. Defined | Templates, a retention rule, an intake form, a list of tools | Policy pages, intake log | Every asset has a consent record and deletion date (sample audit passes) | | 3. Managed | Panel with contact limits; service levels; quarterly sweeps; repository with an owner | Scorecard, audit results | Time to recruit and ledger exceptions on target for two quarters | | 4. Scaled | Risk tiers and self-serve for Tier 1; training path; insight reuse measured | Reuse samples, review records | Decisions routinely cite insights; PwDR studies pass spot checks | | 5. Adaptive | Services redesigned from metrics and participant feedback; budget defended with unit costs | Quarterly reviews with changes made | Sustain; revisit after reorganisations or new regulation | Most organisations should aim for Level 3 before Level 4: opening research to more people on top of an unreliable ledger multiplies the risk. ### Adoption roadmap: 30/60/90 days | Window | Actions | Milestones | Metrics started | |---|---|---|---| | Days 1–30 | Benchmark survey of researchers;[^gds-2023] inventory where research data lives; agree lawful basis per study type with privacy counsel; publish consent templates and one approved store; quick win (fix the most painful access or tooling problem) | Scope on one page; templates live | Researcher benchmark; count of stores holding research data | | Days 31–60 | Intake form with tiers; retention schedule; first sweep; panel opt-in flow with separate panel consent; incentive policy and payout owner | First audit report; panel live | Time to recruit; payment latency; ledger exceptions | | Days 61–90 | Repository with a small taxonomy and seed content; librarian named; Tier 1 self-serve pilot with one team; first scorecard to research leadership | Scorecard reviewed; pilot retrospective | Contact-limit breaches; reuse sample; stale-insight share | 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.[^gds-2023] ## Toolkit ### Checklists **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 ### Templates **Template 1: one-page ResearchOps charter** ```text ResearchOps charter: Version , , owner Mission: make research with people easy to start, safe, lawful and reusable. Serves: Out of scope: Services and levels: panel recruitment ; agency recruitment ; consent templates ; Tier 3 review ; 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 -> 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)[^mrs] ```text [ ] 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** ```text Insight ID: I- Status: tentative | validated | retired Statement (one sentence, no names): Evidence: ; <...> (2+ studies to validate) Context: audience, product version, method, date range Confidence and limits: Used in decisions: Review by: Owner: ``` **Template 4: repository tool decision record** ```text Decision: for the research repository Date: Owner: Context: 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: Review date: ``` ### Deep comparisons | Page | Unique focus | Shared with ResearchOps | Choose it when | |---|---|---|---| | ResearchOps (this page) | Participants, consent and research data, repositories, enabling research | — | The bottleneck is running research with people safely and reusing it | | [DesignOps](../designops/) | Design system as a product, design team health | Tools, budget, often the same team | The bottleneck is design delivery and consistency | | [ProductOps](../productops/) | Insight-to-roadmap process, product analytics | Use of insights | Research exists but does not reach roadmap decisions | | [CXOps](../cxops/) | Voice of the customer across the journey | Customer feedback | You need continuous feedback at scale, not studies | | [KnowledgeOps](../knowledgeops/) | Knowledge as an owned, expiring asset across the organisation | Repository practice | Knowledge problems go beyond research | | [PrivacyOps](../privacyops/) | The privacy programme and rights handling | Participant data | You need the legal and programme layer | | [ResearchDataOps](../researchdataops/) | Scientific data stewardship (FAIR) | Only the word "research" | You manage scientific datasets | ### FAQ **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.[^reops-about] 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.[^mrs] 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.[^nng-repos] 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.[^nng-synthetic] **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. ## Going further ### Advanced topics and emerging direction - **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).[^rally-home] 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).[^respondent] 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.[^gdpr-28] - **Contested or speculative:** synthetic users as a substitute for participants; NN/g's evaluation found them unreliable for that purpose.[^nng-synthetic] - **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.[^bu-fraud] - **Measuring research impact:** linking insights to decisions and outcomes remains hard; the reuse metric above is a practical start, not a solution. ### Learning path | Stage | What to do | Outcome | |---|---|---| | Prerequisites | Run or observe three user-research sessions; read one consent form critically | You know what operations support | | 1-day primer | Read this page's first two parts, the ResearchOps Community About page and NN/g's ResearchOps 101 | You can explain ResearchOps and its scope | | 1-week practice | Do Labs 1–3; draft your organisation's information sheet and retention schedule | You can measure recruitment and audit the ledger | | 30 days | Run the 30-day roadmap actions in a real team (benchmark, inventory, templates) | A first audit and a one-page scope | | Advanced specialisation | Panel management, research librarianship and taxonomy design, privacy engineering for research, or research programme management (Towsey's handbook covers all eight of her elements)[^kirkus] | Depth in one area | | Portfolio project | Design a tiered self-serve programme with templates, panel policy and a scorecard for a real or fictional organisation | Evidence of system design | **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. ## Wrap-up ### Executive recap and cheat sheet | Topic | Remember | |---|---| | What it is | Operations for user research: participants, consent and data, knowledge, tools, enablement | | Term status | Established in UX and product research; young profession; collides with academic research administration | | Core model | Two supply chains (participants into sessions, evidence into decisions) joined by a consent-and-data ledger | | First decisions | Lawful basis per study type; one approved store; retention schedule; consent templates | | Biggest risks | Copies outside approved stores; panels over-contacted; consent confused with lawful basis | | Metrics | Time to recruit, no-show rate, payment latency, ledger exceptions, insight reuse, cost per completed session | | Tools | Panel CRM, recruitment suppliers, payouts, repository; choose after mapping the flow and the data copies | | Watch-outs | AI processors, synthetic users, fraud checks that collect sensitive data, repositories without owners | | Next action | Benchmark researchers and inventory where research data lives | ### A judgement call: open the panel to everyone, or keep recruitment central? **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,[^nng-panels] 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.[^nng-democratize] **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. ### Learning objectives and mastery check 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. ::: answer 1. A team says "we got consent, so GDPR is covered". What is missing? Consent to take part is a permission and ethics requirement; the lawful basis for processing is a separate legal decision (consent is one possible basis). If consent is the basis, they must be able to demonstrate it and make withdrawal as easy as giving it; either way, storage limitation and minimisation apply. ::: ::: answer 2. A quarter has 40 attended sessions, 5 no-shows and 3 cancellations. What is the no-show rate? 5 ÷ (40 + 5) = 11.1%. Cancellations are excluded because those slots never reached a session; track them separately. ::: ::: answer 3. Your repository has 1,200 reports and almost no searches. What do you change first? Name an owner, cut the taxonomy to a few broad tags, seed an insight layer with the most useful findings and link them to the reports, and onboard one team at a time. Measure searches and decision citations, not size. ::: ::: answer 4. Lab 2 shows an asset breaking two rules but reporting only one. Why, and when does it matter? A SQL `CASE` stops at the first true branch. It matters when you count exceptions by type; use one query per rule with `UNION ALL` for complete counts. ::: ::: answer 5. Should a 12-person start-up with one designer hire a ResearchOps manager? Usually not. Write consent templates, choose one approved store and a retention rule, use an agency or marketplace, and revisit when several people run research every quarter or when sensitive data appears. ::: ::: answer 6. A participant withdraws; her clip is in three slide decks. What order do you work in? Log and acknowledge, inform privacy, find all copies by consent reference and participant ID, remove copies outside approved stores first, then stored copies, then review insights that rest only on her data, then confirm and fix the root cause. ::: ::: answer 7. Why can doubling research volume less than double the cost, and what can break that? Fixed costs (staff, tools, panel upkeep) are spread over more sessions. It breaks when the panel cannot supply more people and variable agency fees take over, or when the fixed staff can no longer absorb the extra "keep the lights on" work. ::: ### Conclusion 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. ## Sources and further reading 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. [^reops-about]: [About ResearchOps](https://researchops.community/about/) — ResearchOps Community, page modified 2023-04-17. Checked 2026-10-23. [^reops-repos]: [Research Repositories (community project)](https://researchops.community/blog/project/research-repositories/) — ResearchOps Community, undated. Checked 2026-10-23. [^reops-rsf]: [Research Skills Framework (community project)](https://researchops.community/blog/project/research-skills-framework/) — ResearchOps Community, undated. Checked 2026-10-23. [^nng-101]: [ResearchOps 101](https://www.nngroup.com/articles/research-ops-101/) — Kate Kaplan, Nielsen Norman Group, 2020-08-16. Checked 2026-10-23. [^kirkus]: [Research That Scales: The Research Operations Handbook (review)](https://kirkusreviews.com/book-reviews/kate-towsey/research-that-scales/) — Kirkus Reviews, 2024 (book: Kate Towsey, Rosenfeld Media, 2024; publisher page could not be fetched). Checked 2026-10-23. [^rally-towsey]: [Kate Towsey on Research That Scales](https://rallyuxr.com/post/kate-towsey-on-research-that-scales) — Rally UXR blog (AMA recap), 2024-09-19. Checked 2026-10-23. [^kumc]: [Comprehensive Integrated Research Operations (CIRO)](https://www.kumc.edu/school-of-medicine/academics/departments/internal-medicine/research/comprehensive-integrated-research-operations.html) — University of Kansas Medical Center, undated. Checked 2026-10-23. [^phri]: [Research Data Operations](https://www.phri.ca/what-we-do/research-data-operations/) — Population Health Research Institute, undated. Checked 2026-10-23. [^gds-2019]: [Understanding research operations in government](https://userresearch.blog.gov.uk/2019/05/30/understanding-research-operations-in-government/) — Jonathan Rodriguez, GOV.UK User research in government blog, 2019-05-30. Checked 2026-10-23. [^dfe-2020]: [Research operations](https://dfedigital.blog.gov.uk/2020/10/09/research-operations/) — Tom Adams, DfE Digital blog, 2020-10-09. Checked 2026-10-23. [^gds-2023]: [Lessons from setting up a user research operations function](https://userresearch.blog.gov.uk/2023/11/02/lessons-from-setting-up-a-user-research-operations-function/) — Chris Hyland, GOV.UK User research in government blog, 2023-11-02. Checked 2026-10-23. [^wework]: [Democratizing UX](https://www.wework.com/ideas/democratizing-ux) — Tomer Sharon, WeWork Ideas, 2017-01-12. Checked 2026-10-23. [^gitlab-uxr]: [Why we built a UX Research Insights repository](https://about.gitlab.com/blog/building-a-ux-research-insights-repository/) — Sarah O'Donnell, GitLab blog, 2019-07-10. Checked 2026-10-23. [^gleanly]: [Glean.ly: Atomic UX Research](https://glean.ly/atomic-research) — Glean.ly (vendor page), undated. Checked 2026-10-23. [^maze-atomic]: [Atomic research explained](https://maze.co/collections/user-research/atomic-research/) — Maze (vendor guide), 2025-02-25. Checked 2026-10-23. [^nng-repos]: [Research Repositories 101](https://www.nngroup.com/articles/research-repositories/) — Maria Rosala, Nielsen Norman Group, 2024-07-05. Checked 2026-10-23. [^nng-panels]: [User Panels 101](https://www.nngroup.com/articles/user-panels-101/) — Lola Famulegun, Nielsen Norman Group, 2026-01-23. Checked 2026-10-23. [^nng-pdb]: [Best practices for building and maintaining your own research-participant database](https://www.nngroup.com/articles/research-participant-database/) — Kim Flaherty, Nielsen Norman Group, 2023-05-07. Checked 2026-10-23. [^nng-problem]: [Catching problem participants in remote unmoderated studies](https://www.nngroup.com/articles/problem-participants-remote-unmoderated/) — Kate Moran, Nielsen Norman Group, 2020-08-23. Checked 2026-10-23. [^nng-democratize]: [Democratize user research in 5 steps](https://www.nngroup.com/articles/democratize-user-research/) — Kara Pernice, Nielsen Norman Group, 2022-06-12. Checked 2026-10-23. [^nng-dofaq]: [DesignOps FAQ: 6 Common Questions About Design Operations](https://www.nngroup.com/articles/design-ops-faq/) — Kate Kaplan, Nielsen Norman Group, 2019-11-10. Checked 2026-10-23. [^nng-synthetic]: [Synthetic users: if, when, and how to use AI-generated "research"](https://www.nngroup.com/articles/synthetic-users/) — Maria Rosala and Kate Moran, Nielsen Norman Group, 2024-06-21. Checked 2026-10-23. [^rally-selfserve]: [The rise of self-serve research: what does it mean for Research Ops?](https://www.rallyuxr.com/post/the-rise-of-self-serve-research----what-does-it-mean-for-research-ops) — Lauren Gibson, Rally blog (vendor), 2024-11-06. Checked 2026-10-23. [^bu-fraud]: [How to prevent fraudulent participation in virtual health research](https://www.bu.edu/sph/news/articles/2025/how-to-prevent-fraudulent-participation-in-virtual-health-research) — Boston University School of Public Health (summary of a Journal of Medical Internet Research paper), 2025-11-04. Checked 2026-10-23. [^govuk-consent]: [Getting users' consent for research](https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research) — GOV.UK Service Manual, updated 2018-11-05. Checked 2026-10-23. [^govuk-data]: [Managing user research data and participant privacy](https://www.gov.uk/service-manual/user-research/managing-user-research-data-participant-privacy) — GOV.UK Service Manual, 2018-11-05. Checked 2026-10-23. [^govuk-find]: [Find user research participants](https://www.gov.uk/service-manual/user-research/find-user-research-participants) — GOV.UK Service Manual, updated 2026-09-22. Checked 2026-10-23. [^gdpr-4]: [GDPR Article 4: Definitions (4(5) pseudonymisation)](https://gdpr-info.eu/art-4-gdpr/) — Regulation (EU) 2016/679, text as reproduced by gdpr-info.eu. Checked 2026-10-23. [^gdpr-5]: [GDPR Article 5: Principles relating to processing of personal data](https://gdpr-info.eu/art-5-gdpr/) — Regulation (EU) 2016/679, text as reproduced by gdpr-info.eu. Checked 2026-10-23. [^gdpr-7]: [GDPR Article 7: Conditions for consent](https://gdpr-info.eu/art-7-gdpr/) — Regulation (EU) 2016/679, text as reproduced by gdpr-info.eu. Checked 2026-10-23. [^gdpr-9]: [GDPR Article 9: Processing of special categories of personal data](https://gdpr-info.eu/art-9-gdpr/) — Regulation (EU) 2016/679, text as reproduced by gdpr-info.eu. Checked 2026-10-23. [^gdpr-28]: [GDPR Article 28: Processor](https://gdpr-info.eu/art-28-gdpr/) — Regulation (EU) 2016/679, text as reproduced by gdpr-info.eu. Checked 2026-10-23. [^gdpr-35]: [GDPR Article 35: Data protection impact assessment](https://gdpr-info.eu/art-35-gdpr/) — Regulation (EU) 2016/679, text as reproduced by gdpr-info.eu. Checked 2026-10-23. [^ico-special]: [What are the conditions for processing? (special category data)](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/special-category-data/what-are-the-conditions-for-processing/) — Information Commissioner's Office (UK), last published 2023-12-18. Checked 2026-10-23. [^ico-lawful]: [A guide to lawful basis](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/) — Information Commissioner's Office (UK), updated 2026-04-02. Checked 2026-10-23. [^hra]: [Consent in research](https://www.hra.nhs.uk/planning-and-improving-research/policies-standards-legislation/data-protection-and-information-governance/gdpr-guidance/what-law-says/consent-research/) — NHS Health Research Authority (UK health research), updated 2018-04-19. Checked 2026-10-23. [^mrs]: [MRS Code of Conduct 2023 (PDF)](https://www.mrs.org.uk/pdf/MRS-code-of-conduct-2023.pdf) — Market Research Society (UK), 2023. Checked 2026-10-23. [^uxpa]: [UXPA Code of Professional Conduct](https://uxpa.org/uxpa-code-of-professional-conduct/) — UXPA International, 2005 (English version adjusted 2013). Checked 2026-10-23. [^irs]: [Instructions for Forms 1099-MISC and 1099-NEC (12/2026)](https://www.irs.gov/instructions/i1099mec) — Internal Revenue Service (US), page reviewed 2026-07-01. Checked 2026-10-23. [^rally-home]: [Rally research operations platform](https://www.rallyuxr.com/) — Rally (vendor home page). Checked 2026-10-23. [^respondent]: [Respondent](https://www.respondent.io/) — Respondent (vendor home page). Checked 2026-10-23. [^tremendous]: [Tremendous](https://www.tremendous.com/) — Tremendous (vendor home page). Checked 2026-10-23. [^dovetail]: [Dovetail](https://dovetail.com/) — Dovetail (vendor home page). Checked 2026-10-23. 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.