Deep Research: Finding participants for user research - Service Manual - GOV.UK¶

Source: https://www.gov.uk/service-manual/user-research/find-user-research-participants
Snapshot: ../../sources/md/www-gov-uk-service-manual-user-research-find-user-research-parti-570dbc7f2ea1.md
Category: Discovery & Product Strategy (product_discovery)
Chapters: 02-discovery, 05-validation, 19-iteration, 01-method

TL;DR¶

这是英国政府数字化服务（GDS）发布的权威指南，强调用户研究必须招募真实或潜在的用户，特别是要包含残障人士和数字弱势群体；核心策略包括基于数据定义招募标准、组合使用多种招募渠道（中介、第三方、现场）、严格的隐私保护以及前置的激励支付，以确保研究结果的有效性和包容性。

核心观点¶

用户必须是真实的：研究对象必须是服务的实际用户或潜在用户，严禁仅使用内部员工或也就是试试的路人代替，因为他们的行为模式完全不同。
包容性是硬指标：必须招募残障人士（包括认知障碍、运动障碍等）或使用辅助技术（如屏幕阅读器）的用户。即使当前没有这类用户，也要招募具有类似需求的人进行测试，以防未来产生阻碍。
基于画像定义标准：招募标准（Screener）不能凭空想象，应基于现有社会调查、统计数据、分析数据或用户画像。标准应涵盖人口统计学、特定经历（如刚搬家）和访问方式（如只在图书馆上网）。
渠道决定样本质量：
- 专业中介：适合招募大众用户，速度快（约10天），需提供详细简报。
- 第三方组织/慈善机构：适合触达特定或弱势群体，需建立长期信任关系。
- 现有用户：通过Newsletter或反馈渠道邀请，转化率高但需注意频率。
- 现场拦截（Pop-up）：去用户出没的地方（如图书馆），适合快速验证，但需获得场地许可。
激励应前置支付：建议在研究会话开始时就支付激励（现金或代金券）。这能消除受试者的心理负担（我必须说好话才能拿钱），也方便在会话出现问题时（如受试者不合适）礼貌终止并依然给予补偿。
隐私最小化原则：仅收集绝对必要的个人信息，仅在团队内部分享给必须知道的人，且一旦不再需要（通常是研究结束后）立即销毁联系方式。
避免职业受试者偏差：不要重复使用同一批参与者，也不要过度依赖那些总是很闲的人。通过混合使用不同的招募渠道来抵消单一渠道的偏差。
残障招募需预留缓冲期：招募特殊需求用户通常需要更长时间（普通残障约1个月，罕见认知障碍需6-8周），且可能需要额外的后勤支持（如手语翻译、交通辅助）。
知情同意不仅是签字：要在会话前提供清晰的信息单（Information Sheet），让参与者在放松、知情的状态下参与，这对研究质量至关重要。

可落地做法¶

1. 定义招募标准 (Screener Design)¶

行动：起草一份招募问卷（Screener）。
内容：
- 必须项：符合产品的核心用户画像（如过去3个月内购买过车险）。
- 排他项：排除竞争对手员工、近期参加过类似研究的人、行业专家（除非产品是给专家用的）。
- 配额：设定性别、年龄、技术熟练度、设备类型的比例（如：50% iOS, 50% Android）。

2. 建立混合招募流水线 (Recruitment Pipeline)¶

对于大众C端产品：
- 签约 1-2 家靠谱的用户招募代理商，建立标准化的 Brief 模板。
- 在产品官网/App设置加入用户体验计划的入口，建立私域用户池。
对于B端/专业产品：
- 与客户成功团队（CSM）合作，定期从活跃客户中筛选访谈对象。
- 联系行业协会或专业论坛的版主协助招募。
对于包容性测试：
- 与视障协会或老年大学建立联系，每季度至少进行一次专项招募。

3. 执行合规与隐私保护¶

行动：制作标准化的《用户研究知情同意书》和《研究说明页》。
关键点：明确告知数据将如何被记录（录音/录像）、存储多久、谁能看到、以及用户随时退出的权利。
数据处理：建立定期清理机制（如脚本自动提醒），确保参与者的 PII（个人身份信息）在项目结束后 30 天内从硬盘/云盘彻底删除。

检查清单：用户招募准备¶

这份清单可用于每次用户研究启动前的自检：

[ ] 明确画像：是否清晰定义了谁是目标用户，谁不是？
[ ] 多样性检查：样本中是否包含不同年龄、性别、社会经济背景的人？
[ ] 包容性检查：是否至少包含 1 名残障人士或辅助技术使用者？（即使是非专门的可访问性测试）
[ ] 渠道选择：是否选择了最适合该目标群体的招募方式（中介 vs 现场 vs 现有用户）？
[ ] 激励准备：是否准备了适当金额的激励（现金/券）？是否安排在会话开始时发放？
[ ] 文档准备：是否准备了《信息单》和《知情同意书》？
[ ] 后勤确认：是否询问了参与者需要的特殊协助（交通、翻译、大字版材料）？
[ ] 时间缓冲：如果是特殊群体，是否提前了 4-6 周开始招募？
[ ] 隐私合规：是否有计划在研究结束后安全销毁参与者的联系信息？
[ ] 内部回避：是否确认参与者不是项目组的同事或利益相关者？

常见坑与对策¶

常见坑 (Pitfall)	影响	对策 (Countermeasure)
找同事测试 (Dogfooding bias)	同事了解业务逻辑，无法模拟真实用户的困惑，导致盲点。	严格规定：验证阶段严禁使用产研团队内部人员。仅在找 Bug 阶段使用同事。
样本单一 (WEIRD bias)	只招募受过教育、富裕、来自工业化地区的人，导致产品只服务精英。	强制配额：要求中介招募一定比例的低学历、低数字技能或非一线城市用户。
临阵磨枪招特殊用户	项目截止前才想起来找残障用户，根本以此为由放弃测试。	将包容性测试纳入 DoD（完成定义），并提前 1 个月启动招募，或在每个迭代中常态化穿插 1-2 名特殊用户。
激励变成贿赂	结束后才给钱，让用户觉得必须表现好或取悦研究员才能拿到钱。	见面先给钱。明确告知：这笔钱是感谢你付出时间的，与你的回答内容无关，哪怕你觉得产品全是垃圾也会给。
放鸽子 (No-shows)	约了 5 个人，只来了 2 个，浪费团队时间。	招募时超额 10-20%（如需 5 人，约 6 人）；或在研究前 24 小时和 2 小时进行二次确认。

可用于丰富《AI 辅助软件产品》的写作点¶

对应章节：02-Discovery (产品发现)
- 写作建议：在讨论如何通过访谈挖掘痛点时，引用本指南关于招募标准的定义。强调在 AI 产品中，定义领域专家与普通用户的区别尤为重要（例如医疗 AI 需要招募真医生，而不是仅仅对医学感兴趣的人）。
- 素材：使用混合招募渠道的概念，指导读者如何低成本启动第一批用户访谈（从现有社区入手，而非昂贵的中介）。
对应章节：05-Validation (产品验证)
- 写作建议：在可用性测试小节，增加关于包容性设计（Inclusive Design）的段落。
- 素材：引用 GOV.UK 关于残障用户招募的严格要求，指出 AI 产品的交互（如语音对话、视觉生成）对无障碍性的挑战更大，因此必须纳入视障或听障用户进行验证，这不仅是道德要求，往往能发现模型在极端情况下的鲁棒性问题。
对应章节：11-User (用户体系)
- 写作建议：讨论建立Beta Tester Community时的运营规范。
- 素材：借鉴保护参与者隐私一节，制定 AI 产品收集用户反馈数据（特别是 Prompt 和上传文件）时的隐私清洗标准（Data Sanitization），明确区分训练数据与研究记录数据。
对应章节：20-Governance (治理与伦理)
- 写作建议：探讨 AI 伦理中的算法偏见。
- 素材：引用避免招募偏见的观点，论证如果训练数据或测试数据的来源单一（User Recruitment Bias），必然导致 AI 模型的输出偏见。招募多样化的测试用户是治理 AI 偏见的第一道防线。