作为产品经理，你是否曾在一次迭代后看到整体满意度飙升，却仍有用户抱怨“怎么用？”——那是因为用户的认知模型与系统设计产生了冲突。SUS（系统可用性量表）就是你检测这种冲突的第一道镜头。

SUS 只由十条题目组成，答案分为四个等级：强烈不同意、不同意、同意、强烈同意。它的优点在于既快速又具可比性。标准化的得分可以让你在不同版本、不同产品间横向对比，甚至跨行业。

心理学里，认知模型是用户对世界的简化映射——当你打开电商页面，用户会想“选好商品 → 直接付款 → 结束”。如果页面把付款步骤拆成三步并且需要在中间跳转回“商品列表”，这就形成了认知偏差，SUS 里对应的项往往会掉分。

举个常见案例：某在线教育平台在上线新课程购买流程后，SUS 平均分从 72 降到 58。细看“我觉得系统很难使用”这项的分数突然高达 65%，而“我觉得系统需要我花很多时间学习”也从 30% 升到 55%。这两条题目都与“学习成本”相关，说明用户的认知模型（“一次性下单就能完成支付”）与系统实际流程（“多次点击、多次确认”）不匹配。

要从 SUS 里定位冲突，先把每条题目的平均分拆出来，按正负面归类。正面题目分高说明用户在对应维度满意；负面题目分高则是痛点。接着把痛点对应到功能模块：例如“我觉得系统需要我花很多时间学习”就指向上手层面，往往隐藏在登陆、搜索或付款路径的多余步骤里。

在具体分析时，你可以将 SUS 与用户画像交叉表格：不同年龄层、不同技术水平的用户会在同一条题目上给出截然不同的分数。若中老年用户在“我觉得系统很容易学习”这项得分特别低，说明他们的认知模型对界面复杂度更敏感，可能需要简化流程或提供帮助文档。

Spotify 在推出新版本前做了大规模 SUS 测试。结果显示“系统易于学习”得分从 78 降到 62，导致团队重构了欢迎页，把新功能的切换按钮隐藏到更直观的位置。此举后，SUS 恢复到 75，并伴随留存率提升 4%。这就是认知模型冲突通过 SUS 发现、定位并解决的典型实例。

总结：SUS 不只是一个“可用性”指标，它是洞察用户认知模型与系统实际设计差异的窗口。把 SUS 当作诊断工具，而不是单纯的满意度追踪，你可以在早期迭代中捕捉到隐藏的痛点，避免后期大刀阔斧的改版。

你是否已经把 SUS 融入到你的产品迭代周期？如果还没有，为什么不试试看，让认知模型的冲突成为你改进的催化剂？