关于 tradeoff-analysis
tradeoff-analysis 是用于评估无障碍取舍的设计技能，分析不同用户需求与产品约束间的利弊、严重程度、可逆性和先例，并记录受影响群体、补救措施及复审日期。
主要功能
- 01按用户群体比较利弊
- 02评估任务受阻与使用不便
- 03分析决策可逆性和先例
- 04记录受排斥群体及补救计划
- 05设定取舍复审日期
适用场景
- 01在相互冲突的无障碍需求间做选择
- 02结合期限或性能评估无障碍方案
- 03记录设计决策排除的用户群体
- 04规划延后无障碍支持的补救措施
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/tradeoff-analysis确认已加载。
详细介绍
无障碍权衡分析
严格分析无障碍方面的权衡——因为“我们无法面面俱到”往往确实如此，而权衡决策的质量决定了哪些人会被纳入，哪些人会被排除。
何时需要权衡
用户需求相冲突
- 自动播放字幕有助于失聪用户，但滚动文字会分散 ADHD 用户的注意力
- 简化语言有助于认知无障碍，但可能让部分用户觉得受到轻视
- 高对比度有助于低视力用户，但可能导致部分偏头痛患者眼睛疲劳
无障碍与其他要求的权衡
- 性能：丰富的无障碍功能与页面加载速度
- 截止时间：全面实现无障碍与按时发布
- 复杂度：无障碍自定义组件与更简单但无障碍性较差的原生元素
- 成本：全面测试与预算限制
部分实现
- 可以先让 80% 的功能具备无障碍性，剩余 20% 以后再实现
- 你会选择实现哪 80%，又会因此排除哪些人？
分析框架
针对每项权衡，逐项分析：
1. 选项 A 对谁有益？
- 哪些用户群体的无障碍体验有所改善
- 估计会影响多少用户
- 如果不选择选项 A，障碍有多严重
2. 选项 B 对谁有益？
- 对另一种方案进行同样的分析
3. 每种选项会伤害谁？
- 哪些用户群体会失去无障碍支持，或体验会变差
- 伤害有多严重
- 伤害是永久的还是暂时的（以后会修复吗？）
4. 严重程度是否不对称？
- 无法完成任务（受阻）的用户，受影响的严重程度高于觉得任务更难（遇到阻碍）的用户
- 优先消除阻碍，而不是减少阻力
- 优先考虑永久性残障，而非情境性障碍 （情境性障碍用户还有其他选择；永久性残障用户可能没有）
5. 是否可以撤销？
- 能否在之后以较低成本更改此决定？
- 如果可以：选择更快的方案，并规划后续改进
- 如果不可以：选择更具包容性的方案，并接受延期
6. 会形成什么先例？
- 此决定是否会为未来的功能树立模式？
- 如果不记录，一次性的捷径就会成为标准
- 如果形成了不良先例，其长期成本会超过短期节省
权衡记录
每项权衡都必须使用决策记录格式，并补充以下字段：
此决定会排除哪些人： 列出受影响的具体用户群体。
排除的严重程度： 受阻（无法完成任务）还是遇到阻碍（更难完成，但仍有可能）。
补救计划： 说明何时以及如何为被排除的用户提供支持。 “图表组件的屏幕阅读器支持延期至第 14 个 sprint。临时方案：图表下方的数据表提供相同的信息。已在 JIRA-4521 中跟踪。”
审查日期： 说明何时重新评估这项权衡。
不可逾越的底线
有些权衡绝不可做：
- 绝不能发布完全无法通过键盘操作的功能
- 绝不能为了赶截止日期而移除现有的无障碍支持
- 绝不能降低会阻碍任务完成的无障碍修复的优先级
- 绝不能在没有跟踪工单和截止日期的情况下，把“以后再修”当作可接受的方案
评估问题
- 是否已分析权衡双方分别会让谁受益、伤害谁？
- 是否考虑了严重程度的不对称性（受阻与遇到阻碍）？
- 是否为被排除的用户制定了有记录的补救计划？
- 是否已设定审查日期？
- 此决定是否会形成需要管理的先例？
评论
支持 Markdown