mcpField
Q
qual-quant-triangulation

qual-quant-triangulation

github.com/owl-listener设计与 UI3.1k661 次安装8 周前更新
代码仓库

关于 qual-quant-triangulation

用于处理行为数据与访谈结论不一致的研究技能,判断各自能回答的问题,并设计一项能解决争议的研究。输出是可信依据的判断和后续研究方案,而非对两方观点做摘要或折中。

主要功能

  1. 01识别数据与访谈冲突的含义
  2. 02按问题类型选择证据来源
  3. 03确认两类证据针对同一人群
  4. 04预先定义改变判断的结果
  5. 05设计能区分争议主张的研究

适用场景

  1. 01数据显著流失但用户称体验无碍
  2. 02访谈指出问题而指标未见变化
  3. 03指标改善但用户体验评价变差
  4. 04设计后续研究以判断争议原因

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/owl-listener/designer-skills --skill qual-quant-triangulation

安装后在 Claude Code 中输入/qual-quant-triangulation确认已加载。

附带文件EVALS.md

详细介绍

定性与定量三角验证

当仪表板与访谈结论不一致时,你知道该怎么做。

你要做什么

你拿到的是对同一种行为的两种描述——一种来自测量,一种来自报告——你要弄清楚它们为何不一致、哪一种能回答当前真正要问的问题,以及下一项研究应如何设计才能解决分歧。最终产出应是关于该相信什么的判断,以及一项研究设计,而不是对两种来源的总结。

分歧本身就是信息

团队常把冲突视为某个来源出了问题。但冲突通常本身就是一种信号,其表现形式会告诉你该从何处着手:

你看到的情况通常意味着什么
数据显示用户放弃了;用户却表示没有遇到困难他们放弃的原因并非自己归因于界面——可能是价格、时机,或是在到达之前就已做出的决定
用户报告了严重问题;数据却没有显示影响受影响的群体很小,或者问题发生在开始埋点之前
数据有所改善;用户却觉得体验更糟你优化了一个代理指标。指标变了,体验却没有
用户热情高涨;留存率却持平这是表达出来的偏好,而非实际表现。用户在一次体验中的热情,不等于会再次访问
两者看起来都不错;业务结果却不理想你测量的是任务,而不是该任务所服务的目标
最后两种情况代价最高,因为直到很久之后,才会看出哪里出了问题。

哪种来源能回答哪种问题

把每个问题交给真正能回答它的来源,不要再向另一个来源提问:

  • 发生了什么、发生了多少次、发生在哪里——行为数据。访谈不适合做普查;人们对频率的记忆往往很不准确。
  • 为什么,以及他们想做什么——研究。再多事件数据也无法还原意图。
  • 这件事到底值不值得做——单靠两者都无法回答。这需要判断;把判断包装成发现,正是团队粉饰既定决策的方式。 有人向仪表板提问原因,或向六场访谈询问数量时,你看到的分歧并不是真正的分歧,而是类别错误。

设计能解决分歧的研究

用于解决分歧的研究应比最初的任一项都更聚焦。在开始之前,先写下:存在争议的具体主张是什么、什么结果会让你放弃定性描述、什么结果会让你放弃定量描述。如果没有任何结果能改变你的想法,你就不是在解决冲突,而是在为某个结论搜集依据。 优先采用能区分不同解释、成本较低的工具。对有争议的步骤进行一次会话录制,通常比再做一轮访谈和再看一个仪表板更有效。如果争议在于为什么,就在定性访谈中加入测量,而不是开展两项研究。

最佳实践

  • 在查看任一来源之前,先明确哪种来源是该决策的关键依据
  • 当两种来源对同一问题的结论冲突时,优先考虑实际表现,而非表达出来的偏好
  • 在称其为矛盾之前,先确认两种来源描述的是同一人群——不同群体之间的差异不算分歧
  • 不要把两种描述取平均,拼成折中结论;一个两种来源都不支持的中间立场,比直接选择其一更糟
  • 不要通过重做能得出你偏好答案的研究来解决冲突

评论

支持 Markdown