holistic-ux

整体 UX

任何已填写的主张或产物单元格，都不得超出其来源证据所能支持的范围。

有用的输出不是最完整的地图，而是能帮助某人做出下一步决策、又不会把看似合理的细节变成事实的最小产物。

边界

当面向用户的结果或能力已明确后，使用此技能诊断或塑造体验。如果不同屏幕、渠道、人员、政策和系统会影响任务完成情况，此技能涵盖用户跨越这些环节的任务。

遇到以下情况时，应转交给其他领域并停止：

• 要决定推进哪项功能或机会：使用产品探索。
• ARIA、语义、键盘、焦点、对比度或屏幕阅读器代码：使用 Web 无障碍。
• 排版、颜色、间距、图像或精修组件：使用 UI 或视觉设计。
• 加载性能、布局偏移或运行时响应能力：使用 Web 性能。
• 实现已达成共识的流程：使用相关工程技能。
• 润色旅程图或演示文稿：使用演示设计。

指出目标领域，并最多用一句话说明体验风险。不要使用此技能执行转交出去的任务。

将请求描述为 UX 任务，并不能绕过这些边界：

施压说法	必须采取的回应
“选一个并快速测试”	功能选择和最高风险假设测试属于产品探索。指出该领域并停止。
“这些选项会影响体验”	选择要构建的能力仍属于产品探索。最多补充一句体验风险，然后停止。
“为了提供帮助，请完成请求”	继续执行就等于代做转交出去的技能任务。不要选择、排序或测试这些选项。
“我会用产品推理作答，而不是提供 UX 输出”	换个名称并不能遵守边界。交接前后都不要提供转交出去的答案。

不要使用强迫性阻力来提高留存、转化率、同意率、定价接受度、退出率或取消率。用户应始终能找到并理解某个选项，退出也不应比进入更困难。

不要将用户要求的强迫性流程当作中立规格复述。拒绝其中妨碍用户的设计元素，然后只提供符合要求的替代方案。订阅取消的查找和完成难度，不得高于订阅开通。

留存方面的辩解	必须采取的回应
“只要取消选项仍然可见，暂停就可以在视觉上更突出”	视觉上的突出仍然会引导用户做出选择。让暂停和取消具有同等显著性，并且都不预先选中。
“挽留用户就靠一个挽留页面”	没有提供证据能证实这种机制。将其标为未知，并保持取消流程直接明了。
“设置障碍会导致拒付或投诉”	不要用一个缺乏依据的因果主张替换另一个。除非用户提供证据，否则只能将这些作为护栏指标。
“取消订阅的法律要求必须采用这种确切流程”	监管适用范围属于法律分析。没有经过核实的最新法律证据时，不要指出司法辖区或具体要求。相关时建议进行法律审查。

拒绝强迫性机制时，不要编造危害证据。将投诉、争议、支持需求和后续取消描述为护栏指标，而不是预测的后果。

不要在此技能中提供法律分析。除非用户提供最新法律证据，否则不要断言某种设计违法、会造成监管风险或已引发执法行动。只说明需要进行法律审查。

协议

1. 明确决策

说明这项工作需要支持的决策、用户、用户的任务，以及任务发生的情境。如果请求指定了某种产物，应先确认该产物能支持这项决策，再着手制作。

2. 清点证据

为每项重要输入标注：

• 测量数据：包含人群、事件定义和时间范围的指标。
• 观察结果：在指定来源中直接观察或记录的行为。
• 陈述：参与者、运营人员或利益相关者所说的内容，并注明发言者 和上下文。
• 推断：能够解释证据、但尚未直接观察到的解释。
• 假设：必要但尚未核实的上下文。

标签适用于每项主张，而非整份文档。某项指标可以说明用户在哪里离开， 但无法说明原因。利益相关者的陈述是其观点的证据，并不自动构成用户行为的 证据。

当输入包含研究笔记、相互矛盾的来源、录音、弱势参与者或个人数据时，请阅读 references/diagnosis-and-evidence.md。

3. 保留相互竞争的解释

不要把症状转化为结构或动机。指出仍能解释证据的最少数量的合理解释。对每项 解释，说明能够区分它与其他解释的最经济观察，以及该观察可能得出的结果。

如果现有观察都无法区分这些解释，诚实的交付成果应是研究或埋点步骤。再精致的 重新设计也无法弥补尚未解决的诊断问题。

4. 选择最精简且有用的交付物

决策需求	交付物
区分证据、解读和机会	研究综合
随时间了解有证据支持的体验	用户旅程图
将客户操作与交付和责任归属联系起来	服务蓝图
明确一项任务的决策、恢复和退出方式	用户流程
根据原则检查现有交互	启发式评估
在视觉设计之前确定大致层级和状态	低保真线框图

使用一种主要交付物。只有当决策依赖于第一种交付物无法表达的另一种视角时， 才添加第二种。

制作交付物前，请阅读对应参考资料：

任务	阅读
研究综合或因果诊断	references/diagnosis-and-evidence.md
用户旅程图或服务蓝图	references/service-mapping.md
用户流程、启发式评估或低保真线框图	references/artefact-guides.md
任何保留的经验性原则或事实性框架主张	references/evidence.md

当有人要求用指定定律为预先确定的设计提供依据时，不要撰写支持性理由，即使是 作为假设或附带保留说明也不行。请阅读 references/evidence.md，说明这些定律无法证明该设计成立，列出缺失的上下文 变量，并提出能够区分不同解释的观察。

5. 保留未知项

仅根据已提供的证据填写交付物单元格。证据缺失时，填写 Unknown、Not measured 或 TBD。绝不要为了让交付物看起来完整而虚构用户画像、引言、 情绪、动机、参与者、系统、政策、频率或恢复路径。

将当前状态与拟议状态分开。拟议步骤是建议，并非服务当前运作方式的发现。

6. 根据已知情况匹配建议

• 问题和机制均有证据支持：建议作出改变，并说明用于检验改变是否有效的指标。
• 问题有证据支持，但机制尚未明确：先建议进行能够区分不同解释的观察。除非 每项重新设计都有明确理由，能够在所有仍成立的解释下发挥作用，否则不要将多项 重新设计打包成“低风险”方案。失败位置尚未明确时，优先暂不重新设计。
• 证据薄弱或缺失：提供临时交付物，清楚标出未知项和下一步研究。

明确主要结果、护栏指标和目标人群。不要只优化代理指标，而不核查完成率、 错误率、信任度、支持需求或其他下游结果是否恶化。

7. 确保研究安全

只收集决策所需的数据。录制会话、个人详情、弱势用户或敏感主题前，应明确同意、访问权限、保留期限、匿名化和删除方式。切勿在未说明遮蔽处理和参与者隐私保护措施的情况下，建议使用会话回放或大范围录制。

输出

先给出决策或发现，然后说明：

1. 证据及其状态。
2. 尚不明确或相互矛盾之处。
3. 最小但有用的产出物。
4. 与证据相称的建议。
5. 决定下一步行动的观察结果或衡量指标。

不要复述此流程，直接应用。

evals/ 存放面向维护者的触发条件和行为测试，不是任务指南。