在AI深度融入产品设计的今天，沿用30年前的用户体验准则已显力不从心。本文提出一套面向智能时代的全新设计框架——以“对齐用户心理模型”“清晰可读的状态变化”“支持交互动力”三大核心原则，取代传统尼尔森十大启发式，并引入“结构完整性”作为隐形支柱。
对尼尔森 / 诺曼（Nielsen/Norman）最初提出的 10 条用户体验启发式准则的一种建议性重新梳理 —— 浓缩为 3 条核心原则，聚焦于系统行为、用户心理模型以及交互动力，而非停留在表面层面的评判。
在设计这个的时候，前十列表很受欢迎。1994 年出版，30 岁生日快乐！
设计是一种高功能的欺骗。并非因为它不诚实 —— 而是因为它关乎人性。我们通过隐喻、直觉和品味构建系统，将混乱的现实转化为可用之物。有效的设计并非揭示系统 —— 而是提供一个人们能够导航、信任甚至享受的版本。这并非缺陷，而是关键所在。
我花了二十多年时间实践和教授用户体验设计，如今比以往任何时候都更确信：我们的工作并非简化，而是帮助人们自信地应对复杂性。
“设计可以很简单，这就是它如此复杂的原因。”
—— 保罗・兰德
设计与计算之间的联系并非始于屏幕，但在屏幕上表现得最为明显。在那个像素网格中，尼尔森和诺曼给了我们一张地图：十个启发式方法，它们帮助使以用户为中心的设计合法化，并为设计师一直在做的事情提供了语言表述。它从内部系统转移到互联网虚拟空间，再到手持设备，成为用户体验分析的首选方法。
但那已是 30 年前的事了。而我们至今仍以相同方式使用它们，把它们当作一成不变的戒律，而非创新起点。
我最近负责一个项目，评估我们计划重新设计的一个复杂消息系统。另一个团队建议进行启发式评估 —— 这一建议立刻获得青睐。毕竟，10 个启发式方法是一份长长的检查清单，所以总能找出问题。这让每个人都觉得自己是专家。
但我并不信服。这个系统庞大繁杂 —— 技术上功能完备，但逻辑上不连贯。它以不可预测的方式出现故障。即使是常规任务也需要 “专家” 介入。然而，在没有用例或上下文的情况下，评估团队就一头扎了进去。他们对自己的检查清单充满信心，找出了几十处违规之处 —— 却从未触及底层架构。
团队很容易就带着大量违规问题回来了 —— 每一条都是从尼尔森 / 诺曼清单中摘出的要点式指控。感觉就像是在主持正义。
直到我们必须决定如何修复它。
然后分析就站不住脚了。没人有计划。更糟糕的是 —— 似乎没人意识到这有多难。我们就像批评一个糟糕的布局那样批评这个系统。但它不是布局问题。这是架构问题：有状态、递归、反应式，每一处 “违规” 背后都隐藏着错综复杂的逻辑。但设计并不存在于检查清单中。它存在于决策之中。这个系统不需要批评 —— 它需要架构调整。“违规之处” 并非真正的失败。真正的失败在于没人知道这个系统是如何运作的，因此没人知道如何重新设计它。
就在那时我意识到：这些启发式方法不再能帮助我们进行设计了。它们帮助我们执行设计。它们使批评合法化，但并不指导创造。
那么，我们如何区分好与坏的用户体验设计呢？
我们的工具已经发展 ——Figma、Tailwind、AI 辅助工具 —— 但我们的框架却没有。我们还像在 2005 年那样进行设计。就好像屏幕仍然至关重要。就好像人们还只是点击操作。就好像系统只有一种状态。
我们需要的不是十个松散关联的想法，而是三个持久的原则 —— 再加上第四个可选层面，以考虑看不见的系统结构。
启发法：设计用户已然相信的假象 —— 并与他们一同演进它。
用户不会去学习你的系统 —— 他们会将一种理论投射到系统上。他们模拟自己认为系统会做的事，然后通过每次点击来测试这种模拟。你的工作不是纠正他们 —— 而是让他们的假象保持有用。
以注册会计师（CPA）为例：这是一个角色，而非心理模型。但给他们展示一个带有表头的表格，他们就会期望进行排序、复制粘贴、筛选 —— 因为他们的心理模型是 Excel。如果你的表格看起来像电子表格，但表现得像图片，你就打破了他们的模型和信任。
未充分使用的功能并不总是用户体验不佳。它们可能只是与用户带入的模型不匹配。
心理模型是会演进的。初次使用的用户可能需要工具提示或引导流程。高级用户则想要速度、可预测性和节奏。好的设计会适应这种变化。不是通过增加更多选项，而是通过更精准的对齐。
启发法：每一个操作都应锚定理解，而不仅仅是触发响应。
在被证明有用之前，所有设计都是一种 “谎言”。复杂系统 —— 比如健康保险注册或税务申报 —— 令人困惑并非因为数学计算。它们令人困惑是因为你无法得知系统记住了什么、假设了什么，或者你上一次点击实际做了什么。这是状态沟通的失败。
但复杂并不一定意味着难以承受。策划一场婚礼或进行一次大型购物也很复杂 —— 但我们能够应对，因为我们能看到进展、记得自己做到哪一步了，并且感觉对流程有掌控力。
启发法：用户想要的不是自由 —— 而是速度。
当人们感觉自己在前进时，他们就会保持投入。不是点击，不是做决定，而是在推进。心流状态感觉不到时间流逝，而中断则会。
你不需要更多选项 —— 你需要更多节奏。一个出色的用户界面应该感觉像在游戏中打出完美连招，而不是在机场航站楼填写表格。
启发法：从基础开始设计 —— 即使它是隐藏的。
大多数用户体验问题都源于糟糕的架构。糟糕的数据模型、无法访问的标题、无响应的布局 —— 这些都是结构性问题，而非表面问题。一个在 Figma 中看起来不错的用户界面，如果布局网格发生变化、内容模型僵化，或者组件库混乱，在代码实现时就会崩溃。
不要把结构当作用完就扔的脚手架。它就是建筑本身。
客户的 SaaS 仪表盘表现不佳：
内部设计团队进行了一次启发式审计。排名前三的问题是：
现在怎么办？
这些都是真实的观察结果 —— 但并非根本原因。
它们是通过过时视角解读出的表面症状。
实际问题
这不是一致性问题。（启发法 #4：一致性和标准）
这是状态清晰度问题：仪表盘没有显示哪些操作是安全的、哪些已保存，或者切换开关时会发生什么变化。系统表现为反应式，但界面呈现为静态。
这不是自由问题。（启发法 #3：用户控制和自由）
这是动力问题：用户不明白接下来该做什么。系统感觉停滞或模糊不清，所以他们就不再继续操作。
这不是文档问题。（启发法 #10：帮助和文档）
这是心理模型不匹配问题：界面假设用户理解组件之间的相互关系（角色、权限、消息流），但他们并不理解。所以你写了 400 字的帮助文本，而不是修复架构。
1.使界面与用户的心理模型对齐用户以为切换角色权限只会影响当前用户。
实际上，它重写了全局设置。界面没有解释范围。
→ 建议：将操作重新表述为结果，而非配置。
2.使状态清晰可读且变化可预测
完成引导步骤后，没有完成感或反馈。用户不知道进度是否已保存。
→ 建议：将每个阶段变化视为可见的检查点，并提供返回选项。
3.支持动力而非控制
用户放弃产品并非因为他们缺少选项。他们放弃是因为失去了头绪。
→ 建议：引入 “下一步” 提示和软引导，以减少模糊性。
4.结构完整性审计
由于架构侧重于在.NET 平台上使用 Angular。数据结构侧重于单页检索，而非更便于用户上下文加载的连续数据流。一些较为特殊的对话框和设置需要自定义控件。其中许多都是此用例特有的，不易更改或修改。主要设置流程分为 10 个类别，并且命名方式独特，需要用户相当熟悉。由于这些原因，在这些方面进行更改虽然影响重大，但需要额外的架构考量。
→ 建议：构建一个轻量级状态审计服务，记录用户在设置类别之间的导航，并捕获流程是完成、放弃还是重新访问。
如果时间紧迫或团队尚未准备好完全投入，可以考虑从以下方面入手：
给利益相关者的最终总结
“尼尔森的启发法有助于发现表面层面的问题。但它们无法诊断系统层面在信任、流程或心理连贯性方面的故障。这里缺失的不是功能展示的优化 —— 而是叙事逻辑。我们需要帮助用户理解他们交互的 ‘故事’，而不仅仅是装饰位于其上的界面。”
以我们的对比为例，我们能否让客户更认可并尊重我们对其门户使用不佳问题的洞察呢？这是个好的开始，但对设计师来说，没有什么比实际设计更有帮助，所以这里有一些可视化表示。有很多这样的模板可以帮助团队将广泛的目标聚焦于用户，但一个设计成功或失败的具体原因往往归结于对细节的关注。同样，所有协作模板，如产品画布或用户故事地图都很棒，这些只是一些符合这些启发法的不常见示例。
心理模型不一致分析—— 比较用户期望系统做什么与系统实际做什么。
为了展示创建模型版本如何增加惊人的架构和用户复杂性，以玉米卷为例进行比喻。感谢 GitHub 解决了这类混乱问题。
展示如何与用户就财务目标的恐惧和误解进行沟通并建立联系。
状态转换图—— 绘制系统状态如何演变以及用户界面如何进行（或未能进行）沟通。
事件如何改变列表项的设计状态，并影响不同参与者的理解。
交互动力审计—— 跟踪因反馈不清晰、陷入死胡同或缺乏动力而导致用户流失的摩擦点。人们通常不知道如何表达他们 “想要” 什么。他们知道自己拥有什么以及不喜欢什么。找到他们问题的解决方案是我们的工作。
类似于用户旅程地图，一个旅程地图展示设计变更在哪些地方影响最大。
但为什么不对比多个目标呢？好处是人工智能可以完成大部分繁琐工作。
系统结构审计
一些具有结构限制的面向用户体验的元素已列出。
所以这些是应该淘汰的启发法，以及我给出的原因。潜台词始终是：好吧，修复它！当修复成本超过问题本身时，恭喜你，欢迎成为一名设计师！这是一项具有挑战性的工作！我们希望强化自己作为团队整体目标重要贡献者的角色，而不是可有可无的角色。
淘汰原因：因模糊导致的混乱
听起来不错，对吧？但它是什么意思呢？加载条？状态文本？实时同步指示器？这个启发法从未明确说明。在实践中，它的定义太不明确，以至于设计师把它随意应用于任何事物 —— 但仍然忽略了关键所在：对系统行为随时间的建模。可见性不是目标，可理解性才是。
新框架：“使状态清晰可读且变化可预测。”
淘汰原因：被误解为混乱
理论上：赋予用户权力。
实践中：让用户可以撤销操作并返回。
这个启发法假装用户想要自由，但他们实际想要的是流畅感 —— 相信系统不会困住他们。这个原则被用来为不连贯的导航、过多的设置以及让用户瘫痪的无结构工作流程辩护。
新框架：“支持动力而非控制。”
❌ 淘汰原因：基于幻想的设计
这在 1987 年构建自动取款机时是个不错的想法。但大多数现代系统具有如此多的条件复杂性（过滤器、权限、超时、多用户状态），错误预防是不可能的。为优雅失败而设计要现实得多 —— 并且能教会用户系统实际是如何工作的。如果我们能以某种方式去掉登录错误中的红色警示文本，那将会大有帮助。
新框架：“错误应该是有意义的，而非惩罚性的。”
淘汰原因：半对半错且敷衍
这个说法很吸引人，但具有误导性。识别通常更省力，但更慢。而且它已被滥用于制造混乱：充满用户根本不认识的图标的汉堡菜单。更深层次的问题是上下文环境中的认知负荷，而不是记忆与感知之间的简单二分法。
新框架：“为信心而设计，而非为熟悉度。”
淘汰原因：从包豪斯引入的概念
审美极简主义不是一种启发法，而是一种风格选择。认为美与简单是同一回事的观点是错误的。更糟糕的是，它被用来消除功能展示、隐藏功能，并为从无法使用的手势界面到幽灵按钮的一切行为辩护。
新框架：“审美连贯性＞审美愉悦。”
淘汰原因：作为拐杖的启发法
如果你的系统需要文档，那么你的设计已经失败了。更糟糕的是，这个启发法是一种逃避 —— 它没有说明需要何种帮助、何时提供或如何提供。是内联的？模态的？工具提示？真正的指导应该是教会如何让系统自我揭示，而不仅仅是在问题出现时扔出文档。
新框架：“界面应该揭示其模型。”
⚖️ 模棱两可但可挽救的：
这两个并非完全无用，但需要重新思考：
♻️ 重新调整：好原则，烂口号
当然，一致性有帮助 —— 但盲目应用会导致僵化、毫无生气的系统。设计师需要明白何时有目的地打破模式，而不仅仅是像把 Material Design 奉为福音一样照搬。收回刚才的话，学习 Ant Design、Vuetify、Tailwind 的库。永远不要重新发明已经存在且可定制主题的东西，尤其是在有这么多状态的情况下。苹果新的 “玻璃” 设计有一个不错的框架，通过其风格架构自动应用，所以让它看起来像另一个系统不仅是额外的工作，而且没有理解这些在大多数技术栈中有多少是内置的。
新框架：“一致性是节奏，而非相同性。”8.“系统与现实世界的匹配” 应用隐喻不当综合征是的，隐喻有帮助。但哪个现实世界呢？“桌面” 已过时，拟物化来了又走，现在大多数数字系统都有自己的逻辑。这个启发法过于依赖 1995 年的隐喻，且难以演进。更好的做法是教授系统思维，而不是模仿。新框架：“让系统揭示其逻辑，而不是假装成别的东西。”
这些启发法对于更简单的系统曾发挥过作用，但现在它们实际上误导了设计工作，使其偏离了现代系统所需的架构思维。这个领域需要与我们实际面临的复杂性相匹配的框架，而不是 1994 年我们所面临的那种复杂性。
这源于我在《如何用 AI 取代你的开发团队》（ https://medium.com/@michaeldain/using-ai-to-replace-your-dev-team-b2276ccae045）中记录的一个从设计到编码的完整概念实验 —— 标题有点戏谑，但如果你对状态管理或技术栈不熟悉，这是一个很好的入门介绍。
原文标题：The new Usability heuristics
原文链接：https://medium.com/design-bootcamp/the-new-usability-heuristics-e4fa22ffc0a4
作者：Michael Dain
审核：李泽慧 编辑：丁怡豪
本文由人人都是产品经理作者【TCC翻译情报局】，微信公众号：【TCC翻译情报局】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。