分析对象是已确定的方法，用户的探索、犹豫与学习不在模型之内
别名: 已定方法 · GOMS 假设 · 熟练路径 · 分析范围
概念解释
GOMS 模型（GOMS model）分析的是用户已经知道目标、方法和选择规则后的执行路径。它不建模"我该在哪里找""这个图标能不能点""第一次如何学会"这类探索、犹豫和学习过程。这一条讲的是分析对象在输入端就被限定成了什么——在动笔建模之前，"用户已经知道怎么做"这件事就已经是一个必须满足的前提，而不是模型运行之后才发现的某种输出限制；这和"模型只能预测无错误的熟练操作"这类关于输出该怎么解读的说法，问的是两个不同阶段的问题。
机制
GOMS 之所以要求分析对象是已确定的方法，根源在于它要处理的是一个组合爆炸问题：如果把"用户还不知道该用哪个方法"也纳入分析范围，模型就必须同时刻画用户当下的心智模型状态、界面提供的线索、以及用户会怎样根据线索去猜——这已经不是任务分解能处理的问题，而是需要完全不同的认知架构去回答"人在信息不全时会怎么决策"。GOMS 选择的解法是把这团复杂性整个挪到分析范围之外：先假设方法已经确定，只分析确定之后的执行序列。这也是为什么"探索""犹豫""学习"这三个词会被专门点出来——探索对应的是方法还没被选定时的搜索行为，犹豫对应的是选定过程中的不确定性，学习对应的是方法本身会随经验改变，三者共同的特点是它们发生在"方法确定"这个前提成立之前，因此从一开始就不属于这个模型试图回答的问题。
边界
这不意味着分析脱离现实，而是一份关于适用范围的声明。高频的企业内部任务和控制台操作流程，用户经过长期使用后确实会稳定收敛到某个固定方法，这时候"方法已确定"这个前提基本成立，可以直接套用模型；但对首次使用、需要在多个陌生选项间做选择、或者本身就在鼓励用户探索的创作类任务，这个前提从根本上就不成立，套用模型得到的结论也就无从谈起——不是模型算错了，而是分析对象一开始就选错了。判断能不能用 GOMS，第一步应该是确认目标用户是否真的已经收敛到某个稳定方法，而不是先建模再事后发现假设不成立。
怎么落地
- 建模前先用日志或访谈确认目标用户是否已经收敛到某个稳定方法；如果同一个目标下不同用户用的方法差异很大，说明方法本身还没定型，暂时不适合用 GOMS。
- 明确记录建模针对的任务目标、可用方法集合和用户的训练水平，把这些前提写进报告，而不是让读者误以为结论适用于所有用户。
- 对探索阶段的界面草图或新手引导设计，改用观察式的可用性测试而不是 GOMS，因为探索和学习恰恰是这个模型排除在外的部分。
- 验证办法：抽样观察目标用户完成任务的真实路径，如果多数人确实走的是模型假设的那条方法，说明前提成立；如果观察到大量试探、切换方法或反复确认，说明当前任务还没有到可以用 GOMS 分析的阶段。