一、可用性危机
如果把时间拨回到 1980–1990 年代的软件行业，你会看到一个今天看来几乎难以想象的景象：软件的功能迅速扩张，但用户的使用体验却常常陷入困境。那是一个“软件能做的事情越来越多，但用户能理解的东西并没有同步增加”的时代。
当时的图形化界面（GUI）刚刚普及，鼠标、窗口、菜单、图标这些概念对许多用户来说仍然陌生。软件设计往往以“能实现功能”为首要目标，而缺乏真正基于用户心理的界面结构。工程师主导产品的设计决策，他们理解复杂逻辑、系统流程和技术结构，但这些内容对于第一次打开软件的新手而言，往往是一堵几乎无法跨越的高墙。
你可以想象一个用户在那个时代第一次使用办公软件、绘图软件、或管理系统时的感受：界面密密麻麻都是菜单、选项、图标、按钮，其中很多控件的意义完全依赖使用者去“猜”。使用者需要自己摸索下一步该点哪里、该在哪找某个功能，而设计者往往会天真地认为“只要功能在，那就是可用的”。
但现实是——功能越多，新手越容易迷失。
随着软件价值越来越高，各行业开始大规模引入电脑操作。企业员工、学生、家庭用户都成为软件的使用者，而他们普遍缺乏专业背景。这也让一个严重的问题集中爆发，用户面对软件时，并不是因为“缺乏能力”而失败，而是完全不知道界面正在等待他们做什么。当时的可用性问题大量出现：
- 用户无法找到关键功能
- 操作结果无法预测
- 错误操作频繁但用户不知道为什么
- 完成简单任务需要大量尝试
- 一些功能被用户完全忽略甚至无法理解
而这些情况在不同软件、不同用户群体中反复上演，形成了一个非常明显的时代现象——软件功能爆炸的同时，可用性危机也正在悄然加深。
更糟糕的是，早期的软件开发周期很长，产品一旦发版，问题就难以快速修复。工程团队往往等到“用户大量抱怨”后才意识到界面不可用，但那时已经太迟，修改代价巨大。因此，可用性问题在当时常被视为“用户不够专业”，而非“界面不够清晰”。
这一时期的混沌并不是某一个团队的问题，而是整个行业在迅速扩张时共同面对的一场系统性困境：界面迅速演化，但关于“用户如何理解界面”的理论与方法却明显滞后。软件行业迫切需要一种能够真正理解新手困境、以更系统方式审视界面可用性的机制。
二、测试的局限
找用户来测试产品似乎是一个理所当然的解决方案：让真实用户操作软件、观察他们在哪些地方遇到困难，然后根据这些反馈进行优化。这种方式当然真实、也非常直观。但在 1990 年代的软件开发情境中，它有三个致命痛点，让它难以承担“早期发现问题”的任务。
1. 成本极高
从今天的角度看，我们可以随时用线上工具做远程测试，甚至可以做快速 A/B 实验；但在当时，这是不可能的。要做一次传统的可用性测试，意味着：
- 要招募目标用户
- 要准备场地、录影设备
- 要安排主持人与记录员
- 要安排专业设备观察用户的操作流程
- 用户通常还需激励或补贴
对于一个软件团队来说，这几乎是一件“只有大公司才能承担”的事。尤其是如果你需要测试多个版本、多个迭代，每一次的成本都是一笔巨大开销。因此，在当时大量软件团队心中形成了一个无奈的现实判断：“可用性测试很重要，但我们做不起。”这直接导致了第二个问题。
2. 节奏极慢
传统用户测试最明显的弱点是——速度太慢。你今天发现了一个潜在可用性风险，你需要：
- 写测试脚本
- 准备原型
- 招募参与者
- 安排测试日程
- 测试、观察、分析
- 再回到团队进行设计修改
这个过程时间短则两周，长则一个月。而那时的软件开发节奏正在加快，很多功能每几天就要做一次内部迭代。于是就出现了一个非常尴尬的状况：测试结果出来了，但界面已经更新了。结果是什么？
大量团队开始只在“重大版本临近上线”时做可用性测试，这就引出了第三个，也是最关键的问题。
3. 最大的问题
就算克服了成本和时间问题，传统用户测试还有一个结构性缺陷，那就是它只能发现已经发生的问题，无法提前预测潜在风险。
举个例子：一个界面可能在原型阶段就能看出“新手一定会误解这个按钮的意思”，但只有当真实用户到现场、误解发生后，团队才会真正意识到这一点。换句话说，用户测试永远是在问题发生之后才看见问题。
而且在“接近上线”的阶段，产品的结构、逻辑、交互往往已经稳定下来，很难再进行根本性的调整。于是团队常常面临一种痛苦的选择：如果不改，那么问题上线后会影响大量用户，如果要改，那么代价巨大、牵一发而动全身。这种两难困境在当时的软件团队中普遍存在。
4. 关键盲点
更深层的痛点在于，传统用户测试记录的是用户的“操作行为”，但并不一定能解释用户“为什么这样想”。研究中经常出现这样的情况：
- 用户点错按钮
- 流程走偏
- 在菜单里迷路
- 花太久时间寻找一个入口
团队记录下这些行为，但行为本身不能告诉你：
- 用户是否理解界面？
- 用户是从哪个错误假设开始走偏的？
- 用户是否误解了某个控件的意义？
- 用户是在“猜下一步”，还是“看不见下一步”？
也就是说，用户测试能让你看到“错误在哪里发生”，但不一定能告诉你“用户为什么会犯这个错误”。而只有理解“为什么”，才能真正设计出为新手服务的界面。
三、认知觉醒
认知走查的出现，绝不是偶然，而是 HCI 研究者在面对大量失败案例时，顺着一条更深的线索一步步找到的答案。
1. 补丁失效
在早期软件开发中，团队往往通过，让按钮更显眼、增加提示、添加更多菜单、加更多文案解释等方式来“补救”可用性问题。但随着案例越积越多，HCI 研究者发现一个令人不安的事实：很多用户的错误，与界面呈现的方式无关，而与用户如何理解界面有关。
换句话说，你把按钮放大了，用户仍然不知道是在“这一步”该按它，你写了文案，但用户在没有目标的情况下根本不会读。你加了提示，新手却连“为什么要在这里注意”都不知道。菜单分类再精细，新手依然不知道任务对应哪个菜单项，这些问题说明：可用性不是“界面的问题”，而是“用户与界面如何建立联系”的问题。
这标志着 HCI 领域开始意识到：与其在表层视觉、布局、提示上不断补救，不如往更深层的“理解机制”去找答案。
2. 依赖推理
HCI 研究者通过观察大量真实使用过程后，逐渐明确了一个关键现象：用户在界面上做的，不是从上到下逐字阅读，而是根据自己已有的知识去“推理下一步该怎么做”。
这种推理方式比想象的更脆弱，尤其对新手而言。新手不知道哪些是“重点”，不知道哪些控件和自己的目标相关，不知道软件的总体结构，也不知道哪些动作安全、哪些动作危险，更不知道哪些入口是“会跑出结果”的。因此，新手的失败常常不是因为界面“不够美观”，而是因为：界面没有给用户提供足够的线索，让他们做出合理推论。而这种推论失败，会像多米诺骨牌一样：
- 下一步推不出来
- 不敢点击
- 选择错误操作
- 结果不如预期
- 对软件产生不信任
- 最终放弃任务
这个模式在 HCI 研究资料中反复出现，让研究者开始思考：“如果用户的行为是推理出来的，那我们是不是应该研究用户是怎么推理的？”这个问题，直接开启了认知走查的理论基础。
3. 新手非专家
这一点是认知走查的核心前提，也是在 90 年代的 HCI 研究中被反复强调的结论。专家用户可以记得菜单，熟悉结构，对功能有经验性的预期，能通过历史经验进行“补脑”推理。
但对新手来说，界面是一张白纸：他们即没有过去经验，又没有明确预期，既不知道动作的后果，也不知道操作模式，甚至连界面“是怎么组织的”都不理解