feat: add a plugin for user research with real participants and research operations

Do not implement yet. The issue is a gap record pending an owner interview, not a spec. Read related issues #6306 (UX plugin) and #6298 (UI plugin) and the open questions in this ticket. Done is an agreed split of research-ops vs UX, consent/tooling answers, and a later design—not a plugin in this marketplace until that interview lands.

Problem

The user-experience plugin (#6306) plans research but does not run it: V1 writes research plans, screeners, recruitment briefs, discussion guides, test scripts and surveys, then stops. It never recruits participants or runs sessions. As a result, nothing in this marketplace recruits participants, schedules sessions, handles consent and incentives, runs or records sessions, or keeps a research repository.

Running sessions with real participants, plus research operations (ResearchOps), is this issue's scope. This issue records that gap so it is not forgotten. It is not a design; the scope needs a detailed interview with the owner before any work.

Proposed scope

• Recruiting: screeners deployed in participant tools, panel and recruiting-service access, inclusive recruiting of disabled and older participants.
• Scheduling and session logistics, including incentives.
• Consent, data handling and retention for participant data and recordings.
• Participant notice when a synthetic persona collects data from people (ICC/ESOMAR Code 2025 Art. 4(a)(ii)). user-experience V1 runs no sessions, so this notice belongs here.
• Running sessions through installed testing and survey tools, and collecting their results.
• A research repository the user-experience plugin can write findings into and read prior studies from.
• Routing to installed vendor plugins and MCP servers rather than wrapping vendor APIs.

Out of scope (what user-experience keeps)

• Choosing methods by research question and app stage.
• Writing the instruments: research plans, screeners, recruitment briefs, discussion guides, test scripts, surveys.
• Synthesis: coding, affinity clustering, personas, jobs-to-be-done, journeys.
• Labeling anything not from real users as an assumption to test. Synthetic-user output appears only as a labeled hypothesis, never as a finding.
• Aggregate data only: deliverables and committed files hold no participant names, contacts or identifying quotes.
• Accessibility conformance and the heuristic set, which belong to the UI plugin (/user-interface:design, #6298).
• Developer studies and developer-specific measures, which route to DX (#6302).

Evidence

Confidence labels follow the research behind the user-experience plugin. Vendor rows are what each vendor says about its own product, so they are single-publisher unless marked, and dated 2026-10-04. Naming a vendor here records that a tool exists; it is not a recommendation.

• An agent can review existing evidence (desk research, analytics, support data) without participants. HIGH. Sources: https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs, https://www.nngroup.com/articles/secondary-research-in-ux/
• Drafting plans, screeners, recruitment briefs and discussion guides without participants, and piloting a guide with one participant, is MEDIUM. Source: https://www.nngroup.com/articles/interview-guide/
• Treat findings not from real users as assumptions to test. HIGH. Source: https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs
• Synthetic users can support desk research and hypothesis generation but should complement, not replace, real participants. MEDIUM. Sources: https://www.nngroup.com/articles/synthetic-users/, https://www.cambridge.org/core/journals/proceedings-of-the-design-society/article/can-llmdriven-synthetic-participants-help-user-research-a-case-study-in-designing-augmented-reality-for-education/27F86D08049C21D27721E4229646393E
• Involving disabled users: informal evaluation throughout development is more effective than only formal testing at the end, and user involvement alone cannot determine whether a site is accessible. Guidance, not a standard. MEDIUM (pending verification), single source. Source: https://www.w3.org/WAI/test-evaluate/involving-users/
• Interviews, usability testing and surveys are the methods researchers report using most (92%, 73%, 72%). MEDIUM: a single vendor's survey of its own audience, n=485, mostly people with research titles, not the non-specialist teams this plugin would serve. Source: https://www.userinterviews.com/state-of-research-strategy
• Dovetail's research-repository MCP endpoint exists and requires authentication; Anthropic's connector directory lists it as made by Dovetail. HIGH (vendor docs, directory entry and an unauthenticated probe). Sources: https://developers.dovetail.com/docs/mcp, https://claude.com/connectors/dovetail
• Other vendors state they ship MCP servers for repositories (Condens, Great Question, Maze), recruiting (User Interviews, UserTesting) and surveys or testing (SurveyMonkey, Typeform, Qualtrics, Optimal Workshop, Lyssna). Single-publisher or vendor-plus-probe, MEDIUM. Per the vendors, most are beta, early access or plan-gated: Maze's is beta and Enterprise-only, UserTesting's and User Interviews' are early access, and Condens limits its server to Business plans (Enterprise for custom clients). The surface exists but is young, which supports a later lane rather than V1 (judgment).
• Collecting personal information: collect only the information you need; when consent is the legal basis it must be an explicit agreement, and users who refuse must still be able to use the service. MEDIUM (pending verification), single source, written for UK government services; the guide defers legal basis to a data protection expert. Source: https://www.gov.uk/service-manual/design/collecting-personal-information-from-users

Open questions for a human interview

1. Settled: V1 of user-experience writes instruments only, and this issue owns running sessions and ResearchOps. Still open: which of the proposed scope items ship first.
2. Which participant, recruiting, survey and repository tools do the teams that would use this run, and what is their MCP status for them?
3. What consent, retention and recording rules apply (for example GDPR, and any market-research code the team follows), and who reviews them?
4. Who is the human analyst of record for findings the plugin helps produce?
5. Are AI-moderated sessions allowed, and under what disclosure to participants?
6. Who sets and approves incentives?
7. Where does the research repository live, and should the user-experience plugin read prior studies from it before planning new ones?

Related

• #6306 (user-experience plugin; this is the participants and research-operations sibling)
• #6298 (UI plugin; owns accessibility conformance)
• #6302 (DX; developer studies route to UX methods, developer-specific measures stay with DX)
• #6430 (product analytics, on demand)

🤖 Generated with Claude Code