关于 qual-quant-triangulation
用于处理行为数据与访谈结论不一致的研究技能,判断各自能回答的问题,并设计一项能解决争议的研究。输出是可信依据的判断和后续研究方案,而非对两方观点做摘要或折中。
主要功能
- 01识别数据与访谈冲突的含义
- 02按问题类型选择证据来源
- 03确认两类证据针对同一人群
- 04预先定义改变判断的结果
- 05设计能区分争议主张的研究
适用场景
- 01数据显著流失但用户称体验无碍
- 02访谈指出问题而指标未见变化
- 03指标改善但用户体验评价变差
- 04设计后续研究以判断争议原因
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ owl-listener/ designer-skills --skill qual-quant-triangulation安装后在 Claude Code 中输入/qual-quant-triangulation确认已加载。
附带文件EVALS.md
详细介绍
定性与定量三角验证
当仪表板与访谈结论不一致时,你知道该怎么做。
你要做什么
你拿到的是对同一种行为的两种描述——一种来自测量,一种来自报告——你要弄清楚它们为何不一致、哪一种能回答当前真正要问的问题,以及下一项研究应如何设计才能解决分歧。最终产出应是关于该相信什么的判断,以及一项研究设计,而不是对两种来源的总结。
分歧本身就是信息
团队常把冲突视为某个来源出了问题。但冲突通常本身就是一种信号,其表现形式会告诉你该从何处着手:
| 你看到的情况 | 通常意味着什么 |
|---|---|
| 数据显示用户放弃了;用户却表示没有遇到困难 | 他们放弃的原因并非自己归因于界面——可能是价格、时机,或是在到达之前就已做出的决定 |
| 用户报告了严重问题;数据却没有显示影响 | 受影响的群体很小,或者问题发生在开始埋点之前 |
| 数据有所改善;用户却觉得体验更糟 | 你优化了一个代理指标。指标变了,体验却没有 |
| 用户热情高涨;留存率却持平 | 这是表达出来的偏好,而非实际表现。用户在一次体验中的热情,不等于会再次访问 |
| 两者看起来都不错;业务结果却不理想 | 你测量的是任务,而不是该任务所服务的目标 |
| 最后两种情况代价最高,因为直到很久之后,才会看出哪里出了问题。 |
哪种来源能回答哪种问题
把每个问题交给真正能回答它的来源,不要再向另一个来源提问:
- 发生了什么、发生了多少次、发生在哪里——行为数据。访谈不适合做普查;人们对频率的记忆往往很不准确。
- 为什么,以及他们想做什么——研究。再多事件数据也无法还原意图。
- 这件事到底值不值得做——单靠两者都无法回答。这需要判断;把判断包装成发现,正是团队粉饰既定决策的方式。 有人向仪表板提问原因,或向六场访谈询问数量时,你看到的分歧并不是真正的分歧,而是类别错误。
设计能解决分歧的研究
用于解决分歧的研究应比最初的任一项都更聚焦。在开始之前,先写下:存在争议的具体主张是什么、什么结果会让你放弃定性描述、什么结果会让你放弃定量描述。如果没有任何结果能改变你的想法,你就不是在解决冲突,而是在为某个结论搜集依据。 优先采用能区分不同解释、成本较低的工具。对有争议的步骤进行一次会话录制,通常比再做一轮访谈和再看一个仪表板更有效。如果争议在于为什么,就在定性访谈中加入测量,而不是开展两项研究。
最佳实践
- 在查看任一来源之前,先明确哪种来源是该决策的关键依据
- 当两种来源对同一问题的结论冲突时,优先考虑实际表现,而非表达出来的偏好
- 在称其为矛盾之前,先确认两种来源描述的是同一人群——不同群体之间的差异不算分歧
- 不要把两种描述取平均,拼成折中结论;一个两种来源都不支持的中间立场,比直接选择其一更糟
- 不要通过重做能得出你偏好答案的研究来解决冲突
评论
支持 Markdown