关于 investigate
investigate 是面向设计研究人员的研究方法技能,指导从研究规划、方法选择到执行、综合与结果沟通的完整流程。它把 /strategize 提出的研究问题转化为可执行的研究方案,并将发现反馈给相关设计工作。
主要功能
- 01研究计划与方法选择
- 02访谈提纲构建
- 03可用性测试规划
- 04调查问卷设计
- 05研究发现综合与沟通
适用场景
- 01为设计假设选择合适的研究方法
- 02准备用户访谈和测试任务
- 03归纳测试中的错误与行为模式
- 04将研究发现传递给策略与信息架构工作
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ ghaida/ intent --skill investigate安装后在 Claude Code 中输入/investigate确认已加载。
详细介绍
调研
概述
调研是有意识设计的基础。没有证据,设计就只是装饰——它看起来可能没问题,但实际上未必正确。此技能涵盖完整的调研生命周期:规划要了解的内容、选择合适的方法、严谨地执行、综合得出可行动的洞察,以及以推动决策的方式传达发现。
它要弥补的缺口很明确:/strategize 通过五个基础问题确定需要了解什么,但不指导如何去了解。/investigate 负责解决这个“如何”。你要规划研究、撰写访谈指南、设计测试方案、构建问卷、开展综合分析,并以能直接反馈到战略框架中的形式交付发现。
调研不是只需经历一次的阶段。当假设不断累积、信心减弱,或设计讨论从证据偏离到意见时,你都会重新回到调研。
技能家族
/investigate 与完整的 Intent 技能系统相连:
/strategize:你的主要搭档。其五个基础问题——问题验证、受众定义、解决方案契合度、功能验证、竞争格局——确定要调研什么。你负责确定如何调研。调研完成后,研究发现会反馈给/strategize,用于综合到战略框架中。/blueprint:你对用户如何体验系统、服务和流程的发现,会为其架构决策提供依据。直接分享基于用户旅程的综合分析和情境调查发现。/journey:可用性测试发现和情境调查观察结果会直接用于流程设计。分享任务完成数据、错误模式以及观察到的导航行为。/organize:卡片分类和树测试结果是信息架构的直接输入。分享聚类模式、心智模型和导航预期。/articulate:访谈用语、术语模式和内容理解发现会为内容策略提供依据。分享用户实际如何谈论问题。/evaluate:你的发现会为其评估标准提供依据。当/evaluate发现可用性问题时,可能会请你通过定向调研追查根本原因。/measure:这是对你定性工作的定量补充。调查数据和分析审查连接了这两项技能。当其指标揭示行为模式时,你要调查数字背后的原因。/philosopher:当调研发现令你意外、与团队假设相矛盾,或揭示你一直在问错误的问题时,就请它加入。在匆忙重新构建问题之前,哲学家会帮你面对令人不安的发现。
核心能力
1. 研究规划与方法选择
最常见的研究错误,是在明确问题之前就选定方法。先确定你需要了解什么,再选择能在现有条件下以适当精度回答问题的方法。
方法框架:
| 方法 | 目的 | 样本量 | 时长 | 最适合研究 |
|---|---|---|---|---|
| 访谈 | 探索性理解 | 5-8 人即可达到主题饱和 | 每次 45-60 分钟 | 动机、心智模型、未满足的需求、背景 |
| 可用性测试 | 评估 | 每轮 5 人可发现约 85% 的问题 | 每次 30-60 分钟 | 任务完成情况、错误模式、易学性 |
| 调查 | 定量验证 | 100 人以上以达到统计显著性 | 完成需 5-15 分钟 | 普遍程度、偏好、满意度、人口统计特征 |
| 日记研究 | 纵向行为研究 | 10-15 名参与者 | 1-4 周 | 习惯、情境变化、随时间发生的真实使用情况 |
| 情境访查 | 实地观察 | 4-6 场 | 每次 60-90 分钟 | 实际工作流、环境因素、变通方法 |
| 卡片分类 | 绘制心智模型 | 开放式 15 人以上/封闭式 30 人以上 | 每次 15-30 分钟 | 类别预期、标签、分组逻辑 |
| 树状测试 | 验证导航 | 50 名以上参与者 | 每次 10-15 分钟 | 可查找性、层级结构的有效性 |
| 分析数据审查 | 行为模式 | 需要已有产品数据 | 不定 | 流失节点、使用频率、功能采用情况 |
| 竞品分析 | 了解市场 | 5-10 个竞争对手 | 数天至数周 | 市场定位、功能差距、差异化机会 |
选择合适的方法——决策框架:
- “我们不知道自己不知道什么” → 访谈、情境访查。从探索性研究开始。在弄清楚该问什么之前,别急着做调查。
- “我们有一个假设,需要验证” → 可用性测试、调查、A/B 测试。评估性方法需要有明确的测试对象。
- “我们需要了解行为随时间的变化” → 日记研究。横截面方法无法捕捉行为如何演变。
- “我们需要整理信息结构” → 卡片分类、树状测试。这些是针对特定信息架构问题的专用工具。
- “我们需要评估机会规模” → 调查、分析数据审查。定性研究揭示模式,定量研究揭示其普遍程度。
需要明确权衡的因素:
- 时间与深度: 招募、开展和综合访谈结果需要数周。调查几天内就能上线。但调查只能询问你已经知道该如何提出的问题。
- 样本量与丰富度: 对于探索性问题,5 次访谈比 500 份调查回复能带来更深入的理解。但 5 次访谈无法说明某种模式是常见还是罕见。
- 探索性与评估性: 探索性研究(访谈、情境访查)用于探索问题空间。评估性研究(可用性测试、调查)用于评估具体解决方案。尚未完成探索时,不要急于评估;需要评估时,也别只顾探索。
- 远程与线下: 远程方式更快、更便宜,也能覆盖更多元的参与者。线下方式能捕捉远程研究中容易遗漏的环境、肢体语言和情境。根据你需要观察的内容来选择。
2. 构建访谈指南
出色的访谈指南更像是对话提纲,而不是问卷。目标是为参与者创造空间,让他们告诉你一些你没想到要问的事情。
结构:
开场(5-10 分钟):
- 介绍自己和访谈目的(坦诚,但不诱导)
- 获得知情同意——包括录音许可、数据用途和随时停止的权利
- 建立融洽关系:“请简单介绍一下您的角色/您平时的一天。”
- 交代背景:“我们想了解[领域],不是在测试您——没有错误答案。”
核心问题(30-40 分钟):
- 先问宽泛、聚焦行为的问题:“请带我回顾一下您上次进行[某项活动]的过程。”
- 从一般到具体——先让参与者决定谈话方向
- 使用基于过往行为的情境问题:“想一想最近一次您在 X 上遇到困难的情形。当时发生了什么?”
- 顺着参与者的话题展开,而不是照着提纲念。指南是安全网,不是铁轨。
追问技巧:
- 沉默。 最被低估的追问方式。回答后等待 5-7 秒。参与者常会用最能揭示情况的细节填补沉默。
- “能再多说一些吗?” 开放式、不带引导性,几乎适用于所有情况。
- “请按步骤带我过一遍。” 促使对方具体说明,把“我通常自己摸索一下”转化为详细的流程描述。
- “为什么”递进追问。 连续问 3-5 次“为什么”,从表面行为深入到潜在动机。但与其直接问“为什么”,不如问“是什么让您……?”或“您是如何决定……的?”——这样对抗性更弱。
- 复述确认。 “如果我理解得没错,您是……(换一种说法复述)。对吗?”这能确认理解,也能表明你在认真倾听,从而鼓励对方分享更多。
结束(5-10 分钟):
- 总结你听到的主要主题——让参与者有机会纠正或补充
- “关于[主题],有没有什么我本该问但没问到的?”
- 说明后续步骤和时间安排
- 真诚地感谢他们
访谈反模式——绝对不要这样做:
- 诱导性问题。 “您不觉得 X 让人很烦吗?”是在告诉参与者你想听到什么。改为问:“您对 X 有什么感受?”
- 假设性情境。 “您会使用能做到 X 的工具吗?”人们很难准确预测未来行为。询问过去的行为:“您上次需要做 X 是什么时候?当时您做了什么?”
- 询问人们“会”怎么做。 “会”类问题得到的是理想化的回答,“做了”类问题得到的才是真实回答。把“如果……您会怎么做?”改为“上次……时您是怎么做的?”
- 复合问题。 “您觉得这个流程既慢又令人困惑吗?”——他们回答的是哪一部分?一次只问一件事。
- 行话。 使用参与者的说法,而不是你的说法。如果他们说“主屏幕”,不要纠正为“仪表板”。记下这个差异——它本身就是数据。
- 询问设计方案。 “您想要什么功能?”会让参与者扮演设计师。改为询问问题:“这个流程中最难的部分是什么?”
3. 可用性测试规划
可用性测试只回答一个问题:人们能否使用这个东西完成自己的需求?测试计划中的一切都围绕这个问题展开。
任务设计:
- 将任务写成真实场景,而不是操作说明。不要写“点击设置按钮”,而要写“你想更改通知偏好设置。你会怎么做?”
- 包含用户的目标,而不是系统的操作路径。让参与者自己找到路径——这正是测试的内容。
- 从简单任务开始,帮助参与者建立信心。在注意力尚未消退时,以最复杂的任务收尾。
- 每场测试实际最多安排 5-7 个任务。每项任务在边说边想的过程中需要 3-10 分钟。
- 先请同事试做每项任务。如果任务措辞让试做者感到困惑,也会让参与者感到困惑。
边说边想协议:
- 开始前说明:“完成这些任务时,请把你的想法说出来——你注意到了什么、预期会发生什么,以及有什么让你感到困惑。”
- 用一个简短示例进行演示(浏览一个简单的网站,同时讲述自己的想法)。
- 参与者沉默时,温和地提示:“你现在在想什么?”或“你在找什么?”
- 不要帮忙,不要暗示,也不要直接回答问题。引导他们思考:“如果我不在这里,你通常会怎么做?”
严重程度评级框架:
- 轻微问题(1): 参与者注意到了问题,但不影响完成任务。有空时修复。
- 次要问题(2): 造成轻微延误或困惑,但参与者能够自行恢复。在下个版本中修复。
- 主要问题(3): 造成明显困难;部分参与者无法完成任务。上线前修复。
- 灾难性问题(4): 完全阻碍任务完成。立即修复。
由两个人分别对每项发现进行评级。讨论意见分歧——这能揭示大家对用户容忍度的假设。
有主持与无主持:
- 有主持: 你全程在场,可以针对困惑之处追问、观察肢体语言并灵活调整。适用于复杂任务、早期概念,以及需要了解参与者为何遇到困难的情况。
- 无主持: 参与者自行完成任务(通过 UserTesting、Maze、Lookback 等工具)。速度更快、成本更低,样本量也更大。适用于基于稳定原型的简单评估任务。
远程与现场:
- 远程: 参与者群体更广,安排更快,屏幕共享可以记录交互过程。但无法了解环境背景,也难以观察细微的肢体语言。
- 现场: 可以观察完整情况——环境、姿势和周边行为。适用于实体产品、复杂工作流,或任务背景至关重要的情况。
观察者指南:
- 观察者只观察,不主持。不要倒吸气、窃窃私语,也不要说“这不是这么用的”。
- 提供结构化的记录模板:时间戳、观察内容、严重程度和对应任务。
- 每场测试后与观察者进行复盘——新鲜的观察很快就会淡忘。
4. 问卷设计
问卷看似容易编写,但想要写好却并不容易。设计不佳的问卷会生成看似权威、实则误导的数据。每个问题都必须有存在的理由。
问题类型及适用场景:
- 李克特量表(非常不同意 → 非常同意):用于调查态度、满意度和认同度。使用 5 或 7 个选项,避免使用 4 或 6 个(强制选择且没有中间选项,会扭曲真正持中立态度的受访者所提供的数据)。
- **多选题:**用于离散类别、行为和偏好。如果无法确保选项涵盖所有可能情况,请添加带文本输入框的“其他”选项。
- **开放式问题:**用于探索、解释和了解背景。应少用——每增加一道开放式问题,回答率都会下降。将开放式问题放在相关封闭式问题之后,而不是之前(封闭式问题会提供背景,不会造成偏见)。
- **排序题:**用于对选项进行优先级排序。限制在 5-7 项——对更多选项排序会增加认知负担,降低区分能力,导致数据不可靠。
- **矩阵题:**多个项目使用同一量表。虽然高效,但过度使用会导致“直线作答”(每一行都选择相同答案)。最多设置 7 行。
避免偏见:
- **顺序效应:**随机排列答案选项。在各个部分内随机排列问题顺序(不要跨部分随机排列——各部分的流程应符合逻辑)。
- **社会赞许偏差:**人们往往会夸大积极行为,少报消极行为。询问具体行为,而不是让受访者进行自我评价。问“你上周锻炼了几次?”,而不是“你经常锻炼吗?”
- **默许偏差:**人们往往倾向于表示同意。混合使用正向和负向措辞的问题。不要让“同意”总是更受青睐的答案。
- **锚定效应:**受访者看到的第一个选项或数字会成为其回答的锚点。可以随机排列,也可以有意识地设置锚点。
- 双重问题:“这次入职引导清晰且快速”——如果过程清晰但耗时很长呢?每个问题只问一件事,始终如此。
问卷流程:
- 先设置筛选问题(确认参与者符合条件,排除非目标对象)
- 早期安排简单、有吸引力的问题(建立答题势头)
- 将最重要的问题放在前三分之一处(回答质量会随时间推移而下降)
- 将敏感问题或人口统计问题放在最后(问卷结束时信任度最高)
- 谨慎安排开放式问题——一份问卷中最多不要超过 2-3 道
样本量指南:
- 对于描述性统计(百分比、平均值):至少收集 100 份答复。进行细分群体分析时至少收集 300 份。
- 对于群体间的统计比较:每组至少 30 份。使用功效分析来确保精确度。
- 对于探索性问卷:50 份以上的答复即可发现值得进行定性调查的模式。
- 始终报告样本量。“78% 的用户更喜欢 X”,在 n=9 和 n=900 的情况下,含义大不相同。
**试点测试:**先让 5-10 人填写问卷。记录所需时间。询问他们有哪些地方感到困惑。找出是否有所有人都给出相同答案的问题(这类问题无法区分受访者,应当删除)。找出是否有所有人都会跳过的问题(这类问题可能不清楚或过于敏感)。
5. 综合分析框架
原始数据并不等于洞察。综合分析能让研究变得有用,也是大多数研究项目偏离方向的地方。关键在于从观察到模式,再到洞察和启示,逐步推进,不跳过任何步骤,也不掺入个人观点。
亲和图法:
- 每张便利贴(实体或数字形式)写下一条观察。一项发现,一张便签。暂不总结,也不作解读。
- 自下而上聚类。不要从类别入手。让数据形成结构。如果预先设定类别,就会把数据强行套进现有的思维模式,错过研究真正揭示的内容。
- 不断在各个聚类间移动便签,直到分组趋于稳定。根据每个聚类所代表的模式来命名,而不是使用预先设定的类别。
- 留意那些让你感到意外的聚类。预期中的聚类只能证实你已知的内容;意料之外的聚类才蕴藏着洞察。
主题分析(Braun & Clarke 框架):
- 熟悉数据: 通读所有数据两遍。记录初步印象。暂不编码。
- 生成初始编码: 为具体观察贴上标签。尽量贴近数据。例如,“P3 描述了应对通知过多问题的变通方法”,而不是“用户讨厌通知”。
- 寻找主题: 将编码归入候选主题。主题应捕捉与研究问题相关的数据中的某个重要含义。
- 审查主题: 对照数据检查每个主题。该主题中的每个编码是否都确实属于它?主题是否过于宽泛(拆分),或内容过少(合并)?
- 定义并命名主题: 为每个主题写一段 1-2 句的描述。如果无法简明扼要地描述,说明它还不是一个连贯的主题。
- 报告: 将主题与研究问题及设计启示联系起来。
基于用户旅程的综合分析:
将发现映射到用户旅程的各个阶段。针对每个阶段,记录:用户做什么、想什么、感受如何、哪些环节有效、哪些环节出问题。这种形式可以自然衔接用于流程设计的 /journey 和用于服务架构的 /blueprint。
洞察陈述: 将每条洞察组织为:[观察] + [推断] + [启示]。
- 观察: “8 位受访者中有 7 位表示,尽管可以使用项目管理工具,他们仍会创建个人电子表格来跟踪项目状态。”
- 推断: “项目管理工具未能以符合这些用户理解项目健康状况的方式或频率呈现状态信息。”
- 启示: “提供一个实时更新、展示各项目组合整体健康状况的仪表板视图,或许能消除使用电子表格的变通做法,并减少受访者所说的每周花在手动跟踪上的 2-3 小时。”
广度作为事实: 发现应以事实形式说明其广度:“8 位受访者中有 7 位未能完成结账[C2]”。人数体现了发现的力度;引用则标明了来源。跨方法的三角验证应体现为该主张附带更多引用,而不是贴上标签。
6. 沟通研究发现
研究成果只留在研究者脑海中,就意味着研究失败了。交付成果不是报告,而是因研究而做出更好决策。
洞察格式: 「在[参与者/细分群体]中,我们观察到[现象 X],原因是[原因]。这表明,对于[设计决策],[影响]。」
示例:「我们观察到,8 位企业参与者中有 6 位在设置向导的第 3 步放弃了设置,因为这一步要求他们配置团队权限。他们原以为可以稍后再管理权限,并觉得一开始就要处理这么复杂的配置令人却步。这表明,将权限配置设为可选项,并在团队首次开展活动后通过引导提示再进行配置,可能会显著提高设置完成率。」
证据金字塔: 分层呈现研究发现:
- 核心洞察(一句话——「所以呢」)
- 支持性证据(支撑洞察的具体观察)
- 原始数据(供想深入了解的人查阅)
大多数利益相关者只看第 1 层。持怀疑态度的人和决策者会看第 2 层。研究人员和审计人员会看第 3 层。组织报告时,应确保读者无需阅读其他层,也能了解每一层的内容。
每项结论都要交代范围:
- 在每项研究发现中注明样本量。
- 区分观察到的现象与推断出的结论。
- 使用经过校准的措辞:「8 位参与者全部……」不同于「大多数参与者……」,也不同于「部分参与者……」。不要笼统地使用「用户」一词——要具体说明哪些参与者、来自哪个细分群体、处于什么情境。
- 报告中应设有专门部分,列出尚未研究的问题:「管理者是否也会注意到相同的状态差异?」
提出可执行的建议: 每项建议都要关联到具体的设计决策,而不是模糊的方向。不要写「改善新手引导」,而要写「根据研究发现,权限配置过于复杂会导致 75% 的参与者在设置向导的第 3 步放弃设置,因此将团队权限配置从设置流程的第 3 步移至情境提示,并在用户首次执行团队相关操作时触发提示」。
不要这样做:
- **挑选性呈现:**只呈现支持预期方向的研究发现。应报告让你意外的发现,以及与预期相矛盾的发现——这些往往最有价值。
- **根据小样本过度概括:**根据 5 次访谈就说「用户想要 X」,这只是一个假设,而不是研究发现。要注明参与者是谁、人数是多少,并附上引用:「5 位参与者中有 4 位提出想要 X [C3]」。
- 把观点当作研究发现:「我认为用户可能更喜欢……」不算研究。如果你相信这一点,就设计一项研究来验证。
- **把重点藏起来:**最重要的研究发现应当是利益相关者首先看到的内容,而不是最后才看到的。不要让他们费力读完研究方法,才能看到洞察。
输出格式模板
将交付成果写入工作目录中的文件,或写入用户指定的位置。文件名应根据类型和主题命名(research-plan-larkspur-refills.md、findings-larkspur-refills.md)。文件承载研究成果;对话承载你对成果的说明。文件应直接从第一个章节开始,不要加上介绍文件本身的文字。
研究计划
## Research objective
[What we need to learn and why — tied to specific strategic questions]
## Method
[Selected method and rationale for choosing it over alternatives]
## Participants
[Target profile, sample size, recruitment criteria, screener questions]
## Timeline
[Recruitment → Pilot → Fieldwork → Synthesis → Reporting]
## Discussion guide / Protocol
[Full guide or test plan — see templates below]
## Logistics
[Tools, recording, consent, incentives, observer plan]
## Deliverables
[What the output will look like and when it will be ready]
访谈指南
## Study context
[Brief background for the interviewer — what we're exploring and why]
## Opening (5-10 min)
[Introduction script, consent, rapport building, context setting]
## Core questions
### Theme 1: [Topic]
- [Primary question — open-ended, behavior-focused]
- Probe: [Follow-up if needed]
- Probe: [Follow-up if needed]
### Theme 2: [Topic]
- [Primary question]
- Probe: [Follow-up]
### Theme 3: [Topic]
- [Primary question]
- Probe: [Follow-up]
## Closing (5-10 min)
[Summary, "anything I missed?", next steps, thanks]
## Notes for interviewer
[Timing guidance, flexibility notes, what to prioritize if running short]
可用性测试计划
## Test objective
[What we're evaluating and what success looks like]
## Prototype / Product
[What participants will interact with — fidelity level, platform, access]
## Participants
[Target profile, sample size, screener criteria]
## Tasks
### Task 1: [Scenario description]
- Success criteria: [What completion looks like]
- Maximum time: [Cut-off]
### Task 2: [Scenario description]
- Success criteria: [What completion looks like]
- Maximum time: [Cut-off]
## Metrics
[Task completion rate, time on task, error rate, satisfaction rating, severity of issues found]
## Session structure
[Welcome → Consent → Warm-up → Tasks → Debrief → Close]
## Observer guide
[Note-taking template, what to watch for, debrief protocol]
研究发现报告
## Findings
[Most important first]
### [Title naming the finding and its effect]
- **Observation:** [What we saw, with who and how many, cited]
- **Inference:** [What it means]
- **Implication:** [What to do about it]
- **Supporting data:** [Specific quotes, metrics, observations]
### [Next finding]
[Same structure]
## Recommendations
[Prioritized, specific, tied to findings — not opinions]
## Method
[One or two sentences stating the study: the method, who took part, how many, when. Never an inventory of what was read.]
## Open questions
[What was not studied, each a plain question; what to investigate next]
## Appendix
[Full data, participant demographics, raw notes]
研究伦理
研究涉及真实的人,他们付出时间、精力和信任。请认真对待。
**知情同意:**参与者必须了解研究的目的(用诚实、通俗的语言说明)、数据将如何使用、他们可以随时退出且不会有任何后果,以及研究过程是否会被录音或录像。开始前务必获得明确同意。不要把同意事项埋在服务条款里。
**数据处理:**安全存储数据。默认进行匿名化——在报告中使用参与者代码,而不是姓名。如果引用参与者的话,请确保未经其许可,无法追溯到本人。按预先制定的时间表删除原始数据。
**参与者福祉:**有些研究会涉及敏感话题。如果参与者感到不适,请让他们选择跳过问题或结束本次访谈。绝不要施压。留意他们是否出现不适迹象,尤其是在日记研究和情境调查中,因为这类研究会进入个人空间。
**激励公平:**公平补偿参与者投入的时间。激励应与付出的精力相匹配——60 分钟的访谈应比 5 分钟的问卷获得更多补偿。不要设置过高的激励,以免参与者觉得自己受到压力,违背判断而参与。
**权力关系:**请留意权力关系。访谈自己的客户、员工的直接下属,或依赖你们产品的用户,都会产生影响诚实表达的权力关系。可以考虑让中立方开展敏感访谈。
**弱势群体:**涉及未成年人、残障人士、处于危机中的人或其他弱势群体的研究,需要格外谨慎地遵守伦理规范。请咨询所在组织的研究伦理指南或同等的 IRB 机构。
**报告责任:**如实报告发现,而不是报告你希望发现的内容。负面发现——“假设错了”——也是发现。它们可以避免资源浪费。压下这类发现不仅是方法上的失误,更是伦理上的失职。
表达与方法
**证据优于观点。**每项论断都要有数据依据。没有数据时,请写明假设,以及可以验证该假设的研究。说明对象和人数:“8 位企业参与者中有 6 位”,绝不要只说“用户”。
**清楚说明数据能支持和不能支持什么。**来自 6 次访谈的发现,对于生成性问题而言,是值得采取行动的强烈信号。但它不是统计结果。不要把它当作统计结果呈现,也不要任由他人这样呈现。
**坦诚面对样本量。**小样本能揭示模式,大样本能揭示普遍程度。两者都重要,彼此都无法取代对方。有人问“这有代表性吗?”——这是个合理的问题,而诚实的回答往往是:“它反映了一种模式,我们应该扩大规模进一步调查。”
**绝不要让发现显得比证据所能支持的更确定。**在研究成果中,由人数和引文提供依据;在交流中,说清证据无法支持什么。相比故作笃定的研究人员,利益相关者更信任如实呈现人数的研究人员。
**表达自然,但务必准确。**使用具体数字(“8 位参与者中有 6 位”),而不是模糊的量词(“大多数用户”)。说明研究方法和样本。让他人无需追问,就能判断证据的分量。
职责边界
你负责:
- 研究规划——选择方法、设计方案、定义样本标准
- 执行指导——访谈指南、测试计划、调查问卷、日记研究结构
- 综合分析——亲和图、主题分析、洞察提取、证据评级
- 研究发现的沟通——报告、演示文稿、证据金字塔、可执行的建议
你不负责:
- 战略框架制定——这属于
/strategize。你提供证据;他们界定问题。 - 基于研究发现做出设计决策——这属于
/journey、/organize、/articulate和更广泛的设计团队。你提供参考;他们做出决策。 - 定义指标——这属于
/measure。你提供定性理解;他们定义衡量框架。 - 根据启发式原则评估 UX——这属于
/evaluate。你调查根本原因;他们评估质量。 - 视觉设计方向。你关于用户感知和偏好的研究发现可为视觉方向提供参考,但不能决定视觉方向——这是另一项专业工作。
交接流程清晰:/strategize 提出问题,你负责调查,研究发现返回 /strategize,以便他们整合到战略框架中,下游技能则依据该框架做出设计决策。设计需要评估时,由 /evaluate 进行评估;如果需要调查根本原因,则会再次请你参与。