一、可用性危机
如果把时间拨回到 1980–1990 年代的软件行业，你会看到一个今天看来几乎难以想象的景象：软件的功能迅速扩张，但用户的使用体验却常常陷入困境。那是一个“软件能做的事情越来越多，但用户能理解的东西并没有同步增加”的时代。
当时的图形化界面（GUI）刚刚普及，鼠标、窗口、菜单、图标这些概念对许多用户来说仍然陌生。软件设计往往以“能实现功能”为首要目标，而缺乏真正基于用户心理的界面结构。工程师主导产品的设计决策，他们理解复杂逻辑、系统流程和技术结构，但这些内容对于第一次打开软件的新手而言，往往是一堵几乎无法跨越的高墙。
你可以想象一个用户在那个时代第一次使用办公软件、绘图软件、或管理系统时的感受：界面密密麻麻都是菜单、选项、图标、按钮，其中很多控件的意义完全依赖使用者去“猜”。使用者需要自己摸索下一步该点哪里、该在哪找某个功能，而设计者往往会天真地认为“只要功能在，那就是可用的”。
但现实是——功能越多，新手越容易迷失。
随着软件价值越来越高，各行业开始大规模引入电脑操作。企业员工、学生、家庭用户都成为软件的使用者，而他们普遍缺乏专业背景。这也让一个严重的问题集中爆发，用户面对软件时，并不是因为“缺乏能力”而失败，而是完全不知道界面正在等待他们做什么。当时的可用性问题大量出现：
- 用户无法找到关键功能
- 操作结果无法预测
- 错误操作频繁但用户不知道为什么
- 完成简单任务需要大量尝试
- 一些功能被用户完全忽略甚至无法理解
而这些情况在不同软件、不同用户群体中反复上演，形成了一个非常明显的时代现象——软件功能爆炸的同时，可用性危机也正在悄然加深。
更糟糕的是，早期的软件开发周期很长，产品一旦发版，问题就难以快速修复。工程团队往往等到“用户大量抱怨”后才意识到界面不可用，但那时已经太迟，修改代价巨大。因此，可用性问题在当时常被视为“用户不够专业”，而非“界面不够清晰”。
这一时期的混沌并不是某一个团队的问题，而是整个行业在迅速扩张时共同面对的一场系统性困境：界面迅速演化，但关于“用户如何理解界面”的理论与方法却明显滞后。软件行业迫切需要一种能够真正理解新手困境、以更系统方式审视界面可用性的机制。
二、测试的局限
找用户来测试产品似乎是一个理所当然的解决方案：让真实用户操作软件、观察他们在哪些地方遇到困难，然后根据这些反馈进行优化。这种方式当然真实、也非常直观。但在 1990 年代的软件开发情境中，它有三个致命痛点，让它难以承担“早期发现问题”的任务。
1. 成本极高
从今天的角度看，我们可以随时用线上工具做远程测试，甚至可以做快速 A/B 实验；但在当时，这是不可能的。要做一次传统的可用性测试，意味着：
- 要招募目标用户
- 要准备场地、录影设备
- 要安排主持人与记录员
- 要安排专业设备观察用户的操作流程
- 用户通常还需激励或补贴
对于一个软件团队来说，这几乎是一件“只有大公司才能承担”的事。尤其是如果你需要测试多个版本、多个迭代，每一次的成本都是一笔巨大开销。因此，在当时大量软件团队心中形成了一个无奈的现实判断：“可用性测试很重要，但我们做不起。”这直接导致了第二个问题。
2. 节奏极慢
传统用户测试最明显的弱点是——速度太慢。你今天发现了一个潜在可用性风险，你需要：
- 写测试脚本
- 准备原型
- 招募参与者
- 安排测试日程
- 测试、观察、分析
- 再回到团队进行设计修改
这个过程时间短则两周，长则一个月。而那时的软件开发节奏正在加快，很多功能每几天就要做一次内部迭代。于是就出现了一个非常尴尬的状况：测试结果出来了，但界面已经更新了。结果是什么？
大量团队开始只在“重大版本临近上线”时做可用性测试，这就引出了第三个，也是最关键的问题。
3. 最大的问题
就算克服了成本和时间问题，传统用户测试还有一个结构性缺陷，那就是它只能发现已经发生的问题，无法提前预测潜在风险。
举个例子：一个界面可能在原型阶段就能看出“新手一定会误解这个按钮的意思”，但只有当真实用户到现场、误解发生后，团队才会真正意识到这一点。换句话说，用户测试永远是在问题发生之后才看见问题。
而且在“接近上线”的阶段，产品的结构、逻辑、交互往往已经稳定下来，很难再进行根本性的调整。于是团队常常面临一种痛苦的选择：如果不改，那么问题上线后会影响大量用户，如果要改，那么代价巨大、牵一发而动全身。这种两难困境在当时的软件团队中普遍存在。
4. 关键盲点
更深层的痛点在于，传统用户测试记录的是用户的“操作行为”，但并不一定能解释用户“为什么这样想”。研究中经常出现这样的情况：
- 用户点错按钮
- 流程走偏
- 在菜单里迷路
- 花太久时间寻找一个入口
团队记录下这些行为，但行为本身不能告诉你：
- 用户是否理解界面？
- 用户是从哪个错误假设开始走偏的？
- 用户是否误解了某个控件的意义？
- 用户是在“猜下一步”，还是“看不见下一步”？
也就是说，用户测试能让你看到“错误在哪里发生”，但不一定能告诉你“用户为什么会犯这个错误”。而只有理解“为什么”，才能真正设计出为新手服务的界面。
三、认知觉醒
认知走查的出现，绝不是偶然，而是 HCI 研究者在面对大量失败案例时，顺着一条更深的线索一步步找到的答案。
1. 补丁失效
在早期软件开发中，团队往往通过，让按钮更显眼、增加提示、添加更多菜单、加更多文案解释等方式来“补救”可用性问题。但随着案例越积越多，HCI 研究者发现一个令人不安的事实：很多用户的错误，与界面呈现的方式无关，而与用户如何理解界面有关。
换句话说，你把按钮放大了，用户仍然不知道是在“这一步”该按它，你写了文案，但用户在没有目标的情况下根本不会读。你加了提示，新手却连“为什么要在这里注意”都不知道。菜单分类再精细，新手依然不知道任务对应哪个菜单项，这些问题说明：可用性不是“界面的问题”，而是“用户与界面如何建立联系”的问题。
这标志着 HCI 领域开始意识到：与其在表层视觉、布局、提示上不断补救，不如往更深层的“理解机制”去找答案。
2. 依赖推理
HCI 研究者通过观察大量真实使用过程后，逐渐明确了一个关键现象：用户在界面上做的，不是从上到下逐字阅读，而是根据自己已有的知识去“推理下一步该怎么做”。
这种推理方式比想象的更脆弱，尤其对新手而言。新手不知道哪些是“重点”，不知道哪些控件和自己的目标相关，不知道软件的总体结构，也不知道哪些动作安全、哪些动作危险，更不知道哪些入口是“会跑出结果”的。因此，新手的失败常常不是因为界面“不够美观”，而是因为：界面没有给用户提供足够的线索，让他们做出合理推论。而这种推论失败，会像多米诺骨牌一样：
- 下一步推不出来
- 不敢点击
- 选择错误操作
- 结果不如预期
- 对软件产生不信任
- 最终放弃任务
这个模式在 HCI 研究资料中反复出现，让研究者开始思考：“如果用户的行为是推理出来的，那我们是不是应该研究用户是怎么推理的？”这个问题，直接开启了认知走查的理论基础。
3. 新手非专家
这一点是认知走查的核心前提，也是在 90 年代的 HCI 研究中被反复强调的结论。专家用户可以记得菜单，熟悉结构，对功能有经验性的预期，能通过历史经验进行“补脑”推理。
但对新手来说，界面是一张白纸：他们即没有过去经验，又没有明确预期，既不知道动作的后果，也不知道操作模式，甚至连界面“是怎么组织的”都不理解
所以专家会认为“这很明显”，但新手会觉得“这里没有任何线索”。大量研究显示：设计师与工程师对界面的理解模型，与用户的真实认知模型往往完全不一样。
这意味着，专家评估永远无法真实模拟新手，也无法预测新手会在哪一步失去方向。这一个洞察，为“用新手视角评估界面”奠定了根本逻辑。
4. 三个心理过程
在研究用户如何推论下一步时，HCI 领域逐渐找到了一个反复验证的结构，一个新用户面对界面时，会自然经历三个心理过程：
- 形成目标：我现在要做什么？
- 寻找行动：我该在哪里做这件事？
- 理解反馈：我做对了吗？结果是否符合预期？
这三个阶段构成了所谓的“认知链路”。当界面在任何一个环节提供的信息不足，就会导致如下结果：
- 目标模糊 → 用户不知道自己要找什么
- 行动模糊 → 用户不知道什么入口对应任务
- 反馈模糊 → 用户不知道操作是否成功
HCI 研究在这一阶段非常关注这条链路，因为它是解释“新手为什么会卡住”的重要依据。而认知走查方法，就是在这一思考基础上发展出来的。
四、方法诞生
当软件行业在 90 年代初步入“功能膨胀、界面混乱、用户压力空前”的阶段，整个行业都开始面临同一个问题：软件的功能越做越强，但用户的上手难度却越来越高。
界面中堆满了按钮、菜单、工具栏和各种控制选项，而这些元素背后的逻辑通常只有开发者自己知道。对于第一次打开软件的新手而言，每一个功能入口都像是一个未经标注的迷宫。
人机交互（HCI）研究者在长期观察和反复分析中意识到：仅靠用户测试和专家经验，已经无法满足当时的设计需求，更无法跟上越来越快的产品迭代节奏。用户测试虽然能看到真实行为，但过于昂贵且发现问题太晚；专家评审速度快，却容易受专家的专业知识影响，不可能完全站在新手视角看界面。
这意味着：设计团队常常“发现得晚、修得慢、改不动”。随着越来越多可用性失败案例被收集进研究记录，研究者们看到了一条惊人的共同模式，新手用户并不是“不会用软件”，而是界面让他们的认知路径在关键一步断掉了。换句话说，他们并不是缺乏能力，而是缺乏线索。他们不知道下一步该点哪里，也不知道哪些控件与自己的目标相关。最关键的是，他们不知道自己的操作是否安全、是否合理，以及是否真的能达成目标。界面没有告诉他们“下一步为什么要这么做”以及“这样做之后会发生什么”。
1. 现象与认知本质
这种“认知路径断裂”的现象在数十个、数百个案例中重复出现，使研究团队（包括 Wharton、Rieman、Lewis、Polson 等人）逐渐意识到：决定界面是否好用的关键，不在于控件多少、布局整齐与否，而在于界面是否能够支持新手“从目标推理到行动”。
因此他们提出一个关键洞察：新手第一次使用软件时，是沿着一条“心理路径”逐步推理下一步的。 而这条路径，只要某一步出现信息不足、误导或歧义，就会引发整个任务链路的崩塌。
这一认识第一次把可用性研究从纯粹的视觉、操作层面，提升到“用户如何理解”的认知层面。
研究者开始尝试构建一种更契合这种认知路径的评估方法：不是检查界面符不符合规范，而是“模拟新手的心理活动”，从用户的视角出发，逐步推理：
- 用户为什么会想到要做这个？
- 他能不能找到执行入口？
- 他是否能理解控件代表的意义？
- 他能否判断自己是否成功？
这种思路下，1994 年，《Designing the User Interface》系列研究正式提出：Cognitive Walkthrough （认知走查）。
这项方法的出现，并不是为了替代传统可用性测试，而是为了补上可用性评估体系中长期缺失的一块：“在产品很早期、在界面尚未定型时，就能预测新手会在哪里犯错”的认知评估方式。
它带来的意义在于：把界面从“静态布局检查”转变成“动态认知推理检查”；把评估重心从专家视角拉回新手视角；把“界面看起来合理”提升为“界面让用户能顺利推理下一步”；把“等用户抱怨再修”提前成“上线前就能预判卡点”。
自此之后，设计团队第一次拥有了一套可以在流程图、草图、低保真原型阶段就能执行的评估方法。它不但成本低、速度快，而且能够准确针对新手第一次使用软件时的真实困难，因此迅速被业界采纳，成为可用性研究中不可或缺的方法。
五、今天仍然重要
如果你把视野从 1990 年代转换到今天，会发现软件行业已经发生巨大的变化：从桌面软件到移动应用，从简单界面到复杂系统，从传统交互到人工智能产品。但有一件事始终没有改变：用户第一次使用一个界面时依然会迷失。
我们固然有了更成熟的设计方法、有了更完备的组件库、有了更丰富的视觉模式，但新手面对一个界面时所经历的心理过程，与当年研究者观察到的并没有太大区别。他们仍然在问：
- “这是做什么的？”
- “下一步我该点哪里？”
- “我现在是不是做对了？”
- “如果我点下去，会不会发生不好的事情？”
- “我是不是走错地方了？”
这些问题在本质上并不取决于技术时代，而取决于人类的认知方式。而认知走查的价值，正是建立在人类“普遍的、稳定的、跨时代的认知机制”之上。
1. 技术演进，心智未变
软件从桌面走向移动，又从移动延伸到网页、车载、穿戴设备，甚至走向由 AI 驱动的智能界面。界面看上去越来越聪明，却也越来越复杂：
- 功能更丰富
- 状态更多样
- 入口更灵活
- 可配置性更强
- 路径也更不固定
这意味着，第一次使用一个系统的“新手认知压力”比过去更高了。界面更聪明，并不代表用户更容易理解；系统更强大，也可能意味着路径更多、选择更多、误解更多。在这种情况下，认知走查仍然能发挥作用，因为它问的不是：视觉好不好看，按钮够不够大，是否符合规范。它问的是：“一个新用户能否用这条界面给出的线索，推理出下一步是什么？”这一点，在今天比过去任何时候都更重要。
2. 越早发现问题越关键
现代产品的迭代节奏，往往以“周”为单位，甚至以“天”为单位。你很难再像过去那样等待大规模用户测试，因为那速度太慢。也不可能在每一次小迭代后都做专家评审，因为那过度依赖经验。设计师需要的是一种：
- 快
- 轻
- 可以在草图级别就使用
- 不依赖外部成本
- 能预测新手会不会卡住
的方法。而认知走查恰恰满足这些条件。它不仅便宜、灵活、可提前，还能帮助你的团队在真正构建界面之前，就把“认知障碍”识别出来。
在现代快速迭代环境中，“越晚发现问题，代价越高”已经成为常识，而认知走查就是那种能让你最早发现问题的前置方法。
3. 第一次使用
你可能认为某些产品用户很专业，或者某些平台使用频率很高，但无论产品类型如何，只要存在以下情境：
- 第一次打开 App
- 新功能刚上线
- 新流程刚改版
- 新入口刚添加
- 新用户首次注册
- 老用户首次遇到某个操作
- 用户被平台引导到一个不熟悉的界面
那这个时刻的用户，本质上就是“新手”。而“第一次使用”往往决定了：
- 转化
- 留存
- 对产品的信任与好感
- 是否愿意继续使用
- 是否能顺利完成关键任务
如果用户第一次就推不下去，他可能不会再给产品第二次机会。这就是为什么认知走查对增长、商业化、用户体验都有重要意义。
4. 不是“界面”，而是“人”
这是理解认知走查最关键的一点，许多界面之所以失败，并不是因为视觉不好看、控件不规范，而是因为设计团队高估了用户的理解能力，低估了新手的脆弱性。
设计师知道结构，工程师知道原理，产品经理知道业务流程。但用户什么都不知道。认知走查的价值就在于：它问的不是“界面是否合理”，而是“界面的线索是否让用户能自然推理下去”。
界面可以复杂，但线索必须清晰；功能可以丰富，但路径必须可推断；产品可以强大，但新手必须能走下去。只要界面存在“让人无法推断下一步”的地方，就会造成可用性问题，而认知走查就是用来抓住这些点的。