ux-research-discovery-testing

UX 研究探索测试

目的

帮助 Agent 基于用户目标、观察到的行为、业务成果和可验证的证据，提出更好的产品、UX、UI 和前端建议。使用此技能选择恰到好处的研究方法、编写访谈和可用性测试计划、综合研究发现、识别机会，并说明有证据支持的产品决策。

这是一份操作手册，指导如何在真实的产品限制下开展实用研究。

何时使用此技能

在用户要求你执行以下任务时使用此技能：

• 规划探索研究、客户访谈、实地走访、情境访查或利益相关者访谈。
• 审查、评估、重新设计或生成 UI，且用户行为、任务完成情况、无障碍性或产品成果至关重要。
• 创建访谈指南、筛选问卷、可用性测试脚本、研究计划、研究综合框架、机会地图、用户旅程地图、用户画像、任务流程或有证据支持的建议。
• 决定下一步要构建、改进、移除或测试什么。
• 评估原型、线上 UI、设计系统组件、引导流程、表单、导航模型、仪表板、空状态、错误流程或内容层级。
• 将定性笔记、分析数据、调查结果、支持工单、截图或观察记录转化为产品决策。

何时不使用此技能

如果任务仅涉及以下内容，请勿将此技能作为主要工具：

• 不涉及用户目标、任务、行为或产品决策的视觉 UI 样式设计。
• 与实际使用无关的品牌标识、插画或美学探索。
• 需要严谨抽样、推断统计或超出轻量级产品研究范畴的实验设计的统计分析。
• 法律、医疗或受监管的人体受试者研究建议。在这些情况下，应建议寻求合格人士审查，并仅提供一般性的 UX 规划指导。
• 生产环境前端编码，且用户已明确说明用户问题、行为、无障碍要求和交互设计。

核心原则

1. 从决策入手，而非从方法入手。 明确研究需要为哪项产品、设计或前端决策提供依据。只选择能减少该决策不确定性的研究活动。

2. 区分业务问题与研究问题。 将“我们应该构建什么？”转化为可研究的问题，了解人们、任务、动机、情境、限制条件和当前的变通做法。

3. 优先关注行为和情境，而非偏好陈述。 将“你喜欢吗？”和“你想要什么？”视为薄弱证据。询问近期发生的具体经历，观察工作过程，测试任务，并检查真实产物。

4. 兼顾客户价值与业务价值。 不要只围绕已发布的功能、高管偏好或个别用户的诉求进行优化。围绕成果开展工作：改变行为，创造客户价值并支持业务发展。

5. 采用最小但可信的研究闭环。 默认开展轻量、迭代式研究，以影响下一步决策。研究应加速学习，而不应流于形式。

6. 明确列出假设。 在研究或评审之前，列出关于用户、情境、动机、限制条件、无障碍需求和业务目标的假设。将高风险假设转化为可测试的问题。

7. 综合运用多种证据。 定性研究解释原因和方式；定量证据揭示发生了什么、在哪里、频率如何，以及变化是否影响了指标。不要要求一种方法回答所有类型的问题。

8. 根据行为、角色和对比情况招募参与者。 招募对相关任务或情境有经验的人。在能够揭示限制或机会时，纳入相邻角色、非用户、近期流失用户、竞争对手的忠实用户、极端用户和受影响的利益相关方。

9. 研究需要团队协作。 在有帮助时，让产品、设计、工程、内容、无障碍、支持、销售和其他利益相关方参与。直接接触用户比长篇报告更有说服力。

10. 让综合分析过程清晰可见。 使用地图、亲和聚类、机会树、任务流程、用户旅程地图、截图和简短的证据说明，建立共同理解。

11. 保护参与者。 说明研究目的、同意事项、录制安排、保密措施、激励方式和研究结果的用途。将同意与保密协议、激励分开处理。尊重参与者的时间与福祉。

12. 提出行动建议，而不只是呈现发现。 研究发现应引出优先级决策、风险、后续测试和产品改进。

请参阅 references/principle-cards.md，了解每项原则的可复用卡片。

默认建议

除非用户提供了更明确的背景信息，否则请使用以下默认建议。

领域	默认建议	通常最适用的原因	何时调整
研究目标	选择方法前，先确定一个决策和一个主要研究问题。	避免研究缺乏重点和提问过多。	用户明确表示要探索广泛的产品领域时。
探索方法	从 5-8 场半结构化访谈或情境访谈开始，围绕近期的真实经历展开。	对产品工作而言，这种方式足够快捷，也能深入揭示行为、情境、用语和假设。	任务涉及安全关键事项、受到严格监管或需要统计置信度时。
访谈频率	对持续开展工作的产品团队，安排每周与客户接触。对一次性工作，开展能为下一项决策提供信息的最小批次。	持续接触可避免假设过时。	团队无法接触参与者时，则使用二手研究、支持日志、分析数据或内部专家，同时标明置信度较低。
访谈风格	使用访谈指南，但保持灵活。询问近期经历、实例、材料、变通做法和背景。	具体事件比抽象意见更有价值。	研究需要比较不同参与者的指标时。
可用性测试	使用真实任务进行测试，并邀请具有代表性或能带来高学习价值的参与者；只有在不会扭曲任务的情况下，才请参与者边做边说。	相比意见，任务表现更能揭示可用性问题。	产品情境使边做边说不安全、不真实或干扰过大时。
样本量	从小规模开始，反复迭代并持续招募。用小规模测试发现问题，而非估算总体中的发生率。	小批次能快速发现影响重大的问题。	用户需要了解发生率、细分情况或统计置信度时。
参与者标准	根据行为、任务、情境及参与者与产品的关系进行招募，而不仅依据人口统计特征。	单靠人口统计特征很少能说明待完成的工作或心智模型。	人口统计特征直接影响可及性、安全、需求、文化或公平性时。
综合分析	每场访谈后立即由多位团队成员共同分析。将观察结果与解读和建议分开。	减少记忆损失和偏见，避免只在报告交接时才分享研究结果。	保密要求或团队结构不允许广泛参与时。
机会界定	将研究发现归纳为成果、机会、候选方案、假设和测试。	避免团队从一条引述直接跳到某项功能。	用户只需要一份快速的可用性缺陷清单时。
证据强度	相比偏好调查，将观察到的行为、任务成功情况、分析数据和对照测试视为更有力的证据。	降低轻信和自我报告偏差。	研究问题涉及认知度、情绪、品牌认知或明确表达的预期时。
报告	编写简明的决策备忘录，涵盖决策、证据、置信度、建议行动、替代方案、风险和下一项测试。	利益相关者需要的是行动，而非研究档案。	用户要求正式报告或合规材料时。
无障碍	从一开始就将无障碍需求纳入研究标准和可测试要求。	无障碍会影响任务情境、交互成本和实施选择。	始终不能完全省略；仅根据项目范围调整深度。

必要的用户问题

只有在答案会实质性改变研究计划、评审或建议时才提问。先采用建议的默认做法；不要询问常规的最佳实践问题。

产品决策不明确时提问

question({
  question: "What decision should this research or UX critique help you make?",
  recommended_default: "Decide the next product/design change that best improves the user's primary task while supporting the business outcome.",
  options: [
    "Decide what problem or opportunity to pursue",
    "Decide which solution or concept to build",
    "Find usability issues in an existing UI/prototype",
    "Prioritize improvements for a shipped product",
    "Other / custom"
  ]
})

目标用户或情境不明确时提问

question({
  question: "Who is the primary user or participant group, and what real-world context should we design or test for?",
  recommended_default: "Recruit people who recently tried to complete the target task, plus one adjacent or contrasting group if it may reveal hidden constraints.",
  options: [
    "Current users performing the target task",
    "Prospective users or non-users",
    "Competitor users / recent switchers",
    "Internal users, operators, support, or admins",
    "Other / custom"
  ]
})

成功成果不明确时提问

question({
  question: "What user behavior or business outcome should improve if this work succeeds?",
  recommended_default: "Use one user behavior metric tied to a business outcome, such as task completion, activation, retention, conversion, reduced support contact, or successful self-service.",
  options: [
    "Task completion / fewer errors",
    "Activation or onboarding success",
    "Conversion or revenue action",
    "Retention or repeat use",
    "Support reduction or operational efficiency",
    "Other / custom"
  ]
})

参与者招募渠道或研究限制不明确时提问

question({
  question: "What access do we have to users, artifacts, analytics, and the product/prototype?",
  recommended_default: "Use the best available evidence now, flag confidence, and propose the next smallest research loop.",
  options: [
    "Can interview or observe users directly",
    "Can run moderated or unmoderated usability tests",
    "Have analytics/support tickets/session recordings",
    "Only have stakeholder knowledge right now",
    "Other / custom"
  ]
})

当无障碍需求可能改变计划时进行询问

question({
  question: "Are there known accessibility needs, assistive technologies, language needs, or situational constraints that must be included?",
  recommended_default: "Plan for keyboard, screen reader, magnification, color contrast, reduced motion, cognitive load, mobile constraints, and diverse language proficiency unless the product scope clearly narrows this.",
  options: [
    "Known assistive technology users",
    "Known cognitive/language/access constraints",
    "No known data; include baseline accessibility coverage",
    "This is an accessibility-specific study",
    "Other / custom"
  ]
})

完整的决策集请使用 references/decision-prompts.md 中可直接用于 question-tool 的提示词。

工作流

1. 梳理请求

确定：

• 产品或功能领域。
• 阶段：探索、概念、原型、已发布的 UI、重新设计或持续优化。
• 要做出的决策。
• 目标用户、受影响的角色和情境。
• 现有证据和材料。
• 风险：无障碍、隐私、安全、信任、业务影响、技术限制。
• 截止时间和研究渠道。

如果其中任何必要信息缺失，请提出一个有针对性的问题。否则，基于假设继续，并明确标注这些假设。

2. 选择研究模式

根据要做出的决策选择合适的研究模式：

• 生成式／探索性： 当团队还不确定正确的问题或机会是什么时使用。采用访谈、实地走访、日记／记录法、利益相关者访谈、二手研究、支持工单审查和竞品观察。
• 描述性／解释性： 当问题已存在，但团队需要了解工作流、情境、用户群体、心智模型、任务或限制时使用。
• 评估性： 当有概念、原型、UI、流程或竞品体验需要测试时使用。采用基于任务的可用性测试、启发式评审、无障碍评审、认知走查和原型测试。
• 因果性／定量： 当已发布的产品具有可衡量的用户行为，且团队需要了解某项变更是否会影响某个指标时使用。采用分析、A/B 测试、漏斗分析和任务指标，同时通过定性研究解释原因。

3. 明确决策和假设

在撰写计划或建议之前：

1. 说明业务成果。
2. 说明能够促成该成果的用户行为。
3. 说明目标用户／情境。
4. 列出已知事实。
5. 列出假设。
6. 找出风险最高的假设。
7. 选择能够降低这些风险的最轻量方法。

4. 规划轻量级探索

对于探索或访谈，提供：

• 研究目标。
• 研究问题。
• 基于行为／情境的参与者标准。
• 招募渠道和筛选问题。
• 访谈／环节指南。
• 同意和录制计划。
• 角色：主持人、记录员、观察员、招募人员、分析人员。
• 日程安排和综合分析计划。
• 决策产出：机会图谱、发现备忘录、旅程／任务图或建议。

5. 开展访谈或情境访查

遵循以下主持规则：

• 开始时说明同意事项、目的、时长、保密性、录制情况，并允许参与者跳过问题。
• 通过适度的闲聊建立融洽关系。
• 请参与者讲述近期的具体经历：“告诉我你上一次……时的情况。”
• 在继续之前提出追问。
• 提问后以及参与者回答后，都留出沉默时间。
• 使用参与者的语言。
• 询问相关材料、工具、环境、干扰、变通做法、触发因素、人际关系和限制。
• 避免在问题中暗示答案。
• 访谈期间避免教学、修复问题、推销或为设计辩护。
• 将参与者的问题或故障排查留到最后。
• 在有助于界面文案时，记录参与者的原话。

6. 规划可用性测试

对于可用性测试，提供：

• 测试目标和产品决策。
• 测试材料：草图、原型、在线 UI、竞品流程或组件。
• 参与者及其有助于深入了解问题的原因。
• 使用真实情境措辞描述的关键任务。
• 成功标准：完成情况、错误、时间／精力、信心、理解程度、无障碍情况和严重阻碍。
• 主持人脚本。
• 数据采集计划。
• 严重程度分级标准。
• 测试后的综合分析和后续行动。

任务措辞应描述参与者的目标，而非 UI 操作步骤。除非某个按钮本身就是测试对象，否则不要要求参与者寻找特定按钮。

7. 综合证据

综合分析时：

1. 快速回顾笔记和录音。
2. 先记录观察结果，而非解读。
3. 将行为、引述、障碍、动机、变通方法、工具、触发因素、环境和关系归类。
4. 区分发生了什么、这意味着什么，以及该采取什么行动。
5. 将研究发现对应到机会、假设和候选测试。
6. 根据客户影响、业务影响、频率／可信度、风险、无障碍影响和实施成本确定优先级。
7. 说明可信度，并指出哪些情况会改变你的判断。

在有帮助时使用可视化产物：亲和图、用户旅程图、任务流程图、机会解决方案树、截图取证、心智模型图、工作流图或严重程度矩阵。

8. 提出有研究依据的建议

每条建议都应包括：

• 产品决策或变更。
• 使用的证据。
• 用户问题或机会。
• 预期的行为变化。
• 业务价值。
• 无障碍和包容性方面的影响。
• 前端／设计系统方面的影响。
• 权衡与风险。
• 可信度。
• 下一项测试或指标。

优先使用“根据证据，下一步应做 X，因为……”而不是“用户说他们想要 X”。

决策框架

证据阶梯

使用以下阶梯传达可信度：

1. 情境中的观察行为： 实地访问、情境访谈、可用性测试、支持／会话证据。
2. 产品行为数据： 分析数据、转化漏斗、搜索日志、任务成功率、A/B 测试。
3. 产物和变通方法： 截图、电子表格、笔记、工单、表单、人们实际使用的工具。
4. 结构化自我报告： 关于近期行为的访谈、日记研究、设计良好的调查。
5. 较弱的偏好陈述： 喜好、假设性问题、功能请求、笼统的调查回复。

不要丢弃较弱的证据；应适当标注并进行交叉验证。

方法选择

• 需要了解用户是谁以及他们会做什么：访谈、观察、情境访谈、利益相关方／支持团队评审。
• 需要了解界面是否有效：基于任务的可用性测试、无障碍评审、启发式评审。
• 需要了解发布后发生了什么变化：分析数据、转化漏斗、A/B 测试、支持量变化、任务指标。
• 需要了解指标为何发生变化：结合分析数据与访谈、会话回顾、可用性测试或支持分析。
• 需要了解接下来要构建什么：机会发现、体验地图、机会解决方案树、假设映射、概念测试。
• 需要了解如何确定优先级：比较机会，而不只是解决方案；使用客户影响、业务成果、可逆性、风险和成本。

优先级规则

• 先确定机会的优先级，再确定解决方案。
• 尽可能将早期产品决策视为可逆决策。
• 比较多个机会或解决方案，而不是孤立评估一个想法。
• 如果较小规模的测试能够降低风险，就测试假设，而不是测试完整想法。
• 优先解决影响大的可用性和无障碍障碍。
• 不要因为等待完美数据而推迟所有行动。

实用规则

研究规划

• 在编写任何访谈指南或测试脚本之前，先写一段问题陈述。
• 只纳入能支持决策的方法。
• 如果脚本、任务、原型或后勤安排尚不确定，先进行试点或预试点。
• 记录已知假设和潜在偏见。
• 在收集数据之前规划综合分析。

访谈指南

好的指南包括：

1. 介绍、同意、目的、时长。
2. 与任务相关的参与者背景。
3. 按研究问题组织的主体内容。
4. 具体的近期经历和演示。
5. 对相关产物／环境的探查。
6. 可选的设想或理想体验问题，并明确将其视为探索性内容。
7. 总结：遗漏的话题、参与者的问题、激励／后续步骤。

可用性测试脚本

优秀的脚本包括：

1. 开场介绍和知情同意。
2. 提醒参与者：测试的是设计，而不是参与者。
3. 场景设置。
4. 贴近实际的任务。
5. 成功标准和记录字段。
6. 不带诱导性的追问。
7. 任务结束后询问参与者的信心和预期。
8. 总结收尾。

综合分析

• 尽可能以小组形式分析。
• 将观察与解读分开。
• 保持分析结果可追溯到原始记录。
• 将重复出现的模式归纳为洞察。
• 将洞察转化为产品机会、设计原则和可测试的改动。
• 分析时避免过早寻求解决方案。

报告

默认采用简洁的备忘录或带注释的材料：

• 摘要。
• 主要发现。
• 证据和可信度。
• 建议决策。
• 按优先级排序的修复项或机会。
• 风险和权衡。
• 下一项研究或测试。
• 仅在有用时添加附录。

无障碍与包容性要求

始终将无障碍视为用户背景的一部分，而不是最后的合规检查。

• 如果产品面向广泛用户，请纳入有相关残障、使用辅助技术、受到设备限制、有语言需求或面临情境限制的参与者。
• 询问实际使用的工具和设置：键盘操作、屏幕阅读器、放大功能、语音输入、减少动态效果、字幕、对比度、翻译、移动设备限制和认知负荷。
• UI 行为与任务相关时，使用纯键盘操作测试关键任务。
• 检查焦点顺序、可见焦点状态、标签、角色、错误消息、动态更新、减少动态效果时的行为以及触控目标大小。
• 避免因招募不便而将某些人排除在研究计划之外。
• 提供便利措施、无障碍原型、清晰的知情同意流程和灵活的会话安排。
• 如果研究证据缺乏无障碍覆盖，指出这一点并提出后续研究方案。

前端实现指南

当建议会影响前端工作时，请说明实现方面的影响：

• 对控件、导航、标题、表单、列表、表格和页面地标使用语义化 HTML。
• 除非确实需要自定义组件，否则保留原生行为。
• 明确键盘交互、焦点管理、仅在必要时使用 ARIA，以及动态状态的屏幕阅读器播报方式。
• 设计并测试空状态、加载状态、错误状态、离线状态、成功状态、权限状态和部分数据状态。
• 使建议符合设计令牌、组件 API、响应式断点和现有设计系统模式。
• 为目标行为添加分析或事件埋点，但不要在没有与决策相关的指标时添加埋点。
• 将性能和延迟视为用户体验变量，尤其要考虑其对任务成功和信任感知的影响。
• 明确内容要求：标签、辅助文本、错误文案、确认消息和渐进式披露。
• 如果适合使用可复用组件或模式，应避免提出需要脆弱的一次性 UI 的建议。

评审工作流

评审现有 UI、原型或前端实现时，请按以下顺序检查：

1. 用户目标与产品成果： 该设计应支持什么任务？应改变什么行为？
2. 情境与受众契合度： 谁在使用？在什么场景下、受到哪些限制、具备哪些已有知识？
3. 证据： 研究、分析数据、支持反馈、利益相关者知识或观察到的行为能说明什么？
4. 任务流程： 用户能否开始、推进、恢复并完成任务？
5. 信息层级： 最重要的决策、内容和操作是否一目了然？
6. 交互清晰度： 控件、状态、验证、导航和反馈是否易于理解？
7. 无障碍与包容性： 用户能否通过不同输入方式、辅助技术和语言需求操作并理解界面？认知负担是否合理？
8. 内容与术语： UI 使用的语言是否符合用户情境，便于理解？
9. 仅在支持使用时考量视觉设计： 间距、对比度、分组、排版和强调是否有助于明确任务？
10. 前端可行性： 能否使用语义化、响应式、高性能且符合设计系统的组件，以便于维护？
11. 风险与后续测试： 缺少哪些证据？最小且可信的测试是什么？

创建工作流

制定研究计划、UX 建议或设计改进方案时：

1. 明确要做出的决策和期望成果。
2. 确定用户、情境和限制条件。
3. 列出假设和未知事项。
4. 选择能以最小成本降低风险的研究或测试方法。
5. 编写指南、脚本、任务清单或分析框架。
6. 纳入招募、知情同意、角色分工和后勤安排。
7. 明确要收集的证据和成功标准。
8. 纳入无障碍方面的考量。
9. 规划综合分析与报告。
10. 建议后续行动，并说明如何衡量影响。

质量检查清单

定稿前，请确认：

• 产品／设计决策已明确说明。
• 研究问题可以回答。
• 方法与决策相匹配。
• 参与者筛选标准基于行为／情境。
• 问题表述中立，并以真实经历为依据。
• 可用性任务真实可信，不是逐步操作说明。
• 已考虑知情同意、录制、隐私、激励和无障碍便利措施。
• 综合分析将观察结果、解读和建议区分开来。
• 建议已按影响、可信度、风险和工作量排序。
• 同时体现业务价值和用户价值。
• 前端相关建议切实可行且无障碍。
• 已说明局限性和可信度。

请参阅 references/checklists.md 中的完整检查清单。

应避免的常见错误

• 询问用户想要什么，并将答案直接当作路线图。
• 询问用户是否喜欢某种设计。
• 从功能想法出发，而不是从决策或机会出发。
• 用研究来验证早已预设的结论。
• 只招募容易接触的内部参与者。
• 将人口统计特征与行为混为一谈。
• 在没有真实任务的情况下开展可用性测试。
• 在测试过程中帮助参与者。
• 产出冗长的报告，等报告送达时已来不及影响决策。
• 将分析数据视为不言自明。
• 将访谈结果视为具有统计代表性。
• 只优化当前 UI，使其陷入局部最优，却忽略更大的机会。
• 忘记在设计或实现完成前考虑无障碍。
• 在有安全默认选项时，仍过度要求用户补充背景信息。

完整反模式列表请参阅 references/anti-patterns.md。

如何向用户解释建议

使用以下结构：

1. 建议： 清楚说明采取什么行动。
2. 原因： 将建议与用户行为和业务成果联系起来。
3. 依据： 指明信息来源和置信度。
4. 权衡： 说明能获得什么，以及仍存在哪些风险。
5. 下一步： 提出最小规模的测试、实施步骤或衡量指标。

示例：

建议先测试结账错误流程，再重新设计整个结账流程。潜在风险可能不在于视觉打磨，而在于任务恢复：用户需要了解哪里出了问题、如何修复，以及是否已扣款。先针对当前流程开展 5 场基于任务的测试，并制作两项优先修复方案的原型。上线后衡量完成率、错误恢复情况和支持咨询量。