分解粒度可选，粒度不同时得到的方案排序应当保持一致
别名: 分解粒度 · 方案排序 · 稳健性检查 · 关键成本
概念解释
GOMS 可以按按键、命令、子任务或页面转场选择分解粒度（decomposition granularity）。粒度影响绝对数字，但不该改变候选方案的相对排序；若换粒度后排序反转，说明分解遗漏了关键成本或规则错误。这一条谈的是同一个模型在不同精细程度下会不会给出自相矛盾的结论——这是一个关于分析本身是否可靠的检验手段，而不是关于模型适用范围或者能不能预测什么的问题，因此和同组其余几条谈的都是不同的事情。
机制
细粒度的分解会暴露按键、指向和心理准备这类最小动作，粗粒度的分解则会把这些细节合并，只突出页面、模式切换和责任交接这类更大的结构。两种粒度算出来的绝对数字必然不同——细粒度累加的小数目更多，粗粒度累加的大数目更少——但只要两种分解都没有遗漏真正重要的成本，它们应该在"哪个方案更好"这个结论上保持一致，因为决定优劣的从来不是数字本身有多大，而是两个方案之间共同拥有、又互相不同的那部分结构：额外的步骤、额外的模式、额外的等待、额外的决策点。排序之所以会在换粒度后反转，通常是因为其中一种粒度的分解方式，恰好把这部分关键差异悄悄合并没了——比如粗粒度分解把"等待系统响应"直接并入了"点击提交"这一步，如果两个方案的等待时长其实差异很大，粗粒度版本就会看不出这个差异，得出和细粒度版本不一样的结论。
边界
不同问题本来就应该选不同的粒度，这不是需要消除的矛盾：产品还在草图阶段、只是想比较两种大致的信息架构时，用子任务级的粗粒度分解就够了；具体到某个组件该配哪个快捷键，就需要按键级的细粒度分解才能看出差异。粒度一致性检查要求的不是"所有细节数字必须相等"，而是"结论对合理范围内的粒度变化保持稳健"——如果换一种同样合理的切法，排序说反转就反转，说明这个结论本身没有站在真正重要的差异上，而是恰好踩中了某种切法制造出来的假象。跨设备做比较时尤其要注意粒度和标定必须在同一层级下进行，否则设备之间常量本身的差异会和粒度差异叠加在一起，很难分清到底是哪一层出了问题。
怎么落地
- 对需要谨慎判断的关键方案，同时做一份粗粒度和一份细粒度的分解，分别记录步骤数、模式切换次数、等待环节和最终排序。
- 一旦发现两种粒度给出的排序不一致，先检查是不是某一层遗漏了系统响应时间、错误恢复步骤，或者两个方案的方法选择规则本身就不一样——排序反转往往是分解本身有缺口的信号，而不是模型不可靠的信号。
- 在报告里写清楚用的是哪种粒度、包含哪些项、排除哪些项，以及背后依据的选择规则，让读者能自己判断这份分解合不合理。
- 验证办法：用真实的最终任务测试去验证模型给出的排序是否和实测结果一致；如果模型排序和实测结果不一致，先怀疑分解本身漏掉了某个关键成本，而不是直接怀疑 GOMS 这套方法本身不管用。