企业官网建设流程全解析

1. 黄金三原则到底是什么，为什么 UI 设计绕不开它

HCI 这个缩写，在圈子里其实有两个截然不同的指向。一个是 Human-Computer Interaction，也就是人机交互，学术界和设计行业天天挂在嘴边的那个；另一个是蓝牙协议栈里的 Host Controller Interface，搞嵌入式或者玩蓝牙抓包的人更熟悉，比如你在 win10 电脑上用 Wireshark 抓蓝牙 HCI 包，那指的就是协议层的接口。

我这篇要聊的是前者，Theo Mandel 在人机交互研究里提出的“黄金三原则”。如果你看过一些 UI 设计相关的书籍或课程，大概率已经听过这套原则的名字，但也仅仅停留在“听过”的层面——知道有三条，却说不清这三条为什么被叫“黄金”，更不知道它们在工作中到底怎么落地。这篇文章就是把这三条原则掰开揉碎了讲清楚，包括它们背后的设计心理学依据、实际项目里怎么用、常见的坑在哪里，以及我这些年踩过的一些真实案例。

先直接把三条原则亮出来，后面逐一拆解：

1. 让用户处于控制地位
2. 减少用户的记忆负担
3. 保持界面一致

这是 Theo Mandel 在其著作《The Golden Rules of User Interface Design》中提炼的核心思想。对比一下业界更熟悉的 Nielsen 十大可用性原则，Mandel 的这三条显得非常凝练，它不做功能级的枚举，而是直接指向了人机交互中最底层的三个矛盾：人和系统之间谁说了算、人能记住多少信息、界面行为是否可预期。

Mandel 本人是美国的一位用户界面设计专家、作家，长期从事软件可用性研究和设计咨询工作。他提出这三条原则的年代，恰好是图形用户界面逐渐取代命令行界面的关键时期，Windows 95、Mac OS System 7 这类系统的普及让普通用户第一次大规模接触图形界面，当时的人们面对“对话框”“菜单”“图标”这些新事物时，最大的痛点就是：不知道点了会怎样、不知道刚才那个操作到底生效了没有、不知道这个界面和那个界面之间有没有关联。Mandel 的三原则正是那套语境下最有解释力的设计框架。

但三十年过去了，这三条原则不但没过时，反而越来越重要。移动端 App、智能硬件、车载系统、甚至语音交互界面，本质上依然逃脱不了这三个核心问题。这也是我想把它当作一个值得反复咀嚼的设计指导思想来写的原因。

如果你是一名刚入行的设计师或产品经理，把这三条原则背下来没有任何意义，把它变成你评审方案、写交互文档、做可用性测试时的一条条检查清单，才算真正接住了这套思想的养分。

2. 拆解三条黄金原则：每一条背后都藏着设计心理学

2.1 让用户处于控制地位：不是你把控界面，而是界面服务于你的意图

这条原则听起来像废话，但实际操作中，大量设计都在无意间剥夺用户的控制权。什么叫用户可以控制？不是指所有功能都暴露出来让用户按，而是指用户能清楚预判自己操作的结果，能随时撤销或退出，当系统出现异常时，用户知道发生了什么、能做什么、找谁负责。

我第一次对这条原则有深刻体感是很多年前做一个企业后台管理系统。系统里有一个批量导入 Excel 的功能，用户点击“导入”之后，页面会显示一个 loading 动画，如果导入过程中有一行数据格式不对，整个导入流程直接失败，之前导入的所有行全部回滚。用户根本不知道具体是哪一行出了问题，只能自己逐行排查 Excel，然后再重新导入一遍。更糟糕的是，导入成功的瞬间没有任何提示，用户以为没点中，又点了一遍，结果导入了两份重复数据。

这就是典型的用户失去控制感的案例。用户无法预判（不知道哪些行会被判定为格式不对）、无法修正（只能整份回滚）、无法感知结果（导入成功了也没有任何反馈）。

要让用户处于控制地位，设计上至少要做三件事：

第一，操作前给出清晰的结果预期。比如导入前先预览，告诉用户“检测到 236 条数据，其中有 3 条可能格式异常，是否仍然导入”，让用户来决定要不要继续。

第二，操作中提供可中断或可恢复的机制。比如导入任务进入队列，进度可查看，不需要的时候可以取消，已处理的记录不会回滚。

第三，操作后给予明确的反馈。成功的提示、失败的原因，都要在用户当前视野范围内出现。这个我们后面在“减少记忆负担”那条里还会再展开。

再举一个我们日常天天遇到的例子：输入密码。很多 App 在密码框里只看到一个掩盖的圆点，没有“显示密码”的开关，也没有“大小写锁定已开启”的提示。用户一遍遍输入，一遍遍提示错误，却不知道自己到底哪里输错了，手机键盘的大小写状态又看不见。这种情况下的挫败感，本质上就是界面没有给用户足够的信息来保持控制感。

Mandel 在这条原则里还特别强调了一点：避免使用“模态”阻断用户。弹窗是模态交互的典型，尤其是那种“是否确定要删除？此操作不可恢复”的二次确认弹窗，在很多场景下纯粹是设计偷懒，把所有风险都扔给用户判断。真正好的做法是提供“撤销”能力，让操作可以随时反悔，这比反复询问用户“你确定吗”要高级得多。Gmail 的“撤销发送”就是教科书级别的示范。

2.2 减少用户的记忆负担：界面要当外挂大脑，而不是考卷

人的工作记忆容量是非常有限的。认知心理学里有一个著名的“7±2”法则，说的是人在短期记忆里一次只能保留大约 5 到 9 个信息组块。UI 设计中如果要求用户记住前面几步操作的内容，或者记住某个按钮在哪个位置的导航路径，那么这个界面就是在给用户出一张隐形考卷。

Mandel 的第二条原则，核心思路就是“把信息放在界面上，而不是放在用户脑子里”。

具体落地有几个非常有效的手法：

• 识别优于回忆：用图标加文字展示功能，让用户看到就能认出来，而不是让用户凭记忆去猜。
• 提供默认值：表单里的默认选项、默认勾选，能帮用户减少决策负担。
• 保存上下文：用户离开页面再回来，表单内容、滚动位置、筛选条件还在，而不是一切清零重来。
• 清晰的状态可见性：系统当前处于什么状态，处理到哪一步了，下一步会发生什么，都要可见。

我刚入行时做过一个数据管理后台，有个很典型的反面教材：一个多步骤的表单，分四步填写，用户填到第三步时因为临时离开或者误操作刷新了页面，所有已填内容全部丢失，只能从头再来。测试用户一句话让我印象特别深：“我填了十分钟的东西，说没就没了，我再也不想用这个系统了。”

后来我们用 localStorage 做了表单草稿的实时保存，每填完一个字段就自动保存一份草稿，刷新或关闭后重新进入，直接恢复。操作非常简单，但体验的提升是飞跃性的。这就是“减少记忆负担”原则的实际体现——用户不应该需要记住自己“刚才填了什么”。

同样属于记忆负担范畴的，还有一种情况：跨页面的一致性极差。比如同一个操作，在列表页叫“编辑”，到详情页叫“修改”，再到设置页叫“变更”，用户每次都要重新学习这套语言的映射关系，这就是让用户的大脑白白加班。

2.3 保持界面一致：一致性能换来用户的安全感，但别被“一致性”绑架

第三条原则是 UI 设计里被引用最频繁、却也被误解最深的一条。一致性并不仅仅是“按钮都长得一样”“标题字号统一”这么简单，它指的是：用户已经学会的交互方式，在新场景中依然适用，用户已有的知识能迁移到新的界面，而不会被反复打脸。

从这个角度来看，一致性至少包含几个层面：

• 视觉一致性：同一层级的信息用同样的排版和配色，按钮的层级关系一致。
• 交互一致性：同类型操作的手势、点击路径、反馈方式一致。
• 语言一致性：操作文案的动词体系统一，状态描述指代清晰。
• 概念一致性：同一个对象在不同页面里叫同一个名字，用同一个图标。

但这里我特别想说一个容易踩雷的地方：一致性不等于一刀切，不等于所有页面必须长成一个样。我的原则是，对用户高频使用的核心路径，一致性优先级最高；有些低频、特殊场景，可以有针对性地做差异化设计，但要给出明确的视觉或文案引导，让用户知道“这是一个特殊状态”。

举个例子，一个电商 App 里，商品列表页和购物车页都有“删除”功能。商品列表页的删除是左滑出现删除按钮，购物车页却把删除放在了右上角的垃圾桶图标里。用户在两处学到的是完全不同的心智模型，每次切换页面都要重新理解——这就是一致性出了问题。而解决方式也很简单，统一交互方式，或者在购物车页也支持左滑删除，同时保留垃圾桶图标作为辅助入口。

一致性还有个好处常被忽略：它能降低用户的认知成本，也能降低开发团队的维护成本。一套统一的组件库、规范化的交互模式，不需要每个页面都从零设计，复用和迭代的效率都会明显提升。所以从项目管理角度看，一致性原则其实也是一种效率策略。

3. 黄金三原则在真实项目中的落地方法，照着做就行

3.1 从设计自查到团队评审：把三原则变成一张检查清单

理论讲完了，接下来聊实际的。Mandel 的三原则最妙的地方在于：它不是一个只能停留在纸面上的哲学框架，而是可以直接转化成设计评审时的一张检查清单。

我个人的习惯是，在设计方案完成第一版之后，对照三原则逐条自查一遍，把自己当成一个第一次使用这个产品的用户，从头到尾走一遍关键路径。这一轮自查通常会暴露出大量问题，其中的典型包括：

• 表单提交没有成功提示，成功以后也没有跳转或状态变化，用户会以为提交失败
• 页面加载没有状态反馈，用户反复点击按钮，导致重复提交
• 删除操作没有撤销机制，只靠二次确认弹窗来“背锅”
• 面包屑导航层级不清，用户回退后找不回自己刚才所在的位置

这份检查清单不需要很复杂，几条就够：

如果你想把这个过程正式化，可以把它做成团队评审的一个环节。每次设计评审时，让设计师在展示方案之前，先对照三原则做一轮口头陈述：这套方案是怎么保证用户控制感的、哪里减轻了记忆负担、一致性策略是什么。这一步能把很多潜在问题提前拦截在设计阶段，省掉后面开发联调和用户测试的返工成本。

3.2 实操案例：一个表单页面的三原则改造全过程

纸上谈兵没有用，我拿一个我实际经手过的项目来做完整拆解。那是一个 B 端系统的“新建客户”表单页，最初的设计非常典型：所有字段堆在一个长页面上，必填项没有标识，电话号码格式不做实时校验，填完直接点“保存”，如果某个字段格式不合法，页面顶部弹出一行红字提示，但此时用户往往已经看不到提示的位置。

这个页面从用户体验角度可以说把三原则全犯了：

• 没有反馈：点击保存后没有任何 loading 或进度提示，用户不知道系统是不是卡了
• 增加记忆负担：十几个字段，全部要求用户一次性正确填完，填错了也不指出具体位置
• 一致性缺失：错误提示的样式和系统中其他地方完全不一样，用户根本不知道那是一条错误提示

我们改造的思路很简单，但每条都直接对应三原则：

第一，把表单按业务逻辑分组，每组一个区域标题，降低信息密度。这一步呼应“减少记忆负担”。

第二，必填项在标签上用星号标出，同时把“保存并新建”“保存并返回”“取消”三个按钮的层级区分开，主按钮视觉上第一眼能看到。这一步增强用户控制感，让用户明确知道当前操作的目标。

第三，字段级实时校验，输入错误时在字段下方直接显示错误原因。用户不需要记住哪一行错了，也不需要在一堆红字里找自己的问题。校验的同时保持表单内容不被清空，错误修正后用户能立刻得到正向反馈。

第四，保存成功后弹出 toast 提示，同时页面跳转到客户列表并高亮显示新建的客户记录。整个流程闭环，用户的操作被系统清晰“接住”了。

改造完成后，我们做了一轮小规模的可用性测试，用户完成整个表单的平均耗时从原来的 6 分多钟降到了不到 3 分钟，错误率也下降了近一半。效果直观可见，并且这套改法并不需要什么高深的技术，纯粹是设计原则驱动下的细节优化。

3.3 三原则和现代组件库的关系：为什么好的组件库天生更贴近原则

现在做 UI 设计基本都基于组件库，不管是 Ant Design、Element Plus 还是 Material Design，这些组件库本身的设计在很大程度上已经贯彻了可用性原则。比如 Ant Design 里的 Form 组件，天然支持校验规则、错误提示、必填标记，你只要把规则配好，它自动会在字段下方显示错误信息——这其实就是“减少记忆负担”原则的工程化实现。

所以现在的问题已经从“要不要按原则设计”，变成了“怎么在组件库的框架内用好原则”。我经常看到一些团队的问题不是组件不好，而是根本没有理解组件背后的设计逻辑，把组件当积木乱拼。典型的就是：Modal 里面套一个超长表单，用户填到一半误触遮罩层，整个表单被关闭，内容全部丢失；Modal 没有设置确认前的校验，用户点“确定”后也没有 loading 态，连续点了几下，提交了好几次。

这类问题的根源在组件使用方式上，不在组件本身。Mandel 的三原则这时候可以当作使用组件库的指导手册，帮你判断哪些场景该用 Modal，哪些场景该用独立页面或者抽屉。比如：操作内容短、结果明确、需要用户快速确认的场景适合 Modal；信息量大、需要仔细填写或者需要跨页引用的场景，用抽屉或独立页面更合适，因为 Modal 的阻断性会放大记忆负担问题。

4. 用户研究和数据反馈：怎么证明三原则真的有效

4.1 别只靠感觉：用 HCI 的用户测试方法验证设计

Mandel 的三原则本质上是 HCI 领域经验的总结，但你要在工作里把它讲出说服力，光是“我觉得这样好”是不够的，需要借助用户研究的方法来验证。

最常见的方法是可用性测试。找 5 到 8 个目标用户，给他们布置几个真实的任务，观察他们在任务中的操作路径、停顿点、错误操作，收集他们的语音反馈和表情变化。这种方式成本不高，但能暴露大量设计问题，尤其是和三原则相关的那些：用户在哪里犹豫不决（控制感缺失）、在哪里反复回头找信息（记忆负担过重）、在哪里把 A 页面的操作习惯带到 B 页面却行不通（一致性问题）。

另一个方法是在线上产品里埋点收集行为数据。比如表单字段的“焦点停留时间”可以反映用户在哪个字段上困惑；一个按钮的“重复点击率”高说明反馈不及时；页面跳出率高可能意味着用户找不到方向。数据可以帮助你定位问题，但不会告诉你背后的用户心理原因，所以数据和定性测试要结合着用。

4.2 一个真实场景：win10 电脑上怎么抓蓝牙 HCI 包来排查交互异常

前面提过，HCI 在另一个语境下代表蓝牙的主机控制器接口。这里我借着这个双关的热词，分享一个和交互问题排查相关的实操经验，虽然它和 UI 设计不在一个层面，但它同样体现了“反馈闭环”的价值——你的设备状态到底发生了什么，必须能观测到，否则用户面对的就是一个失控的界面。

我之前调试一个蓝牙设备时，遇到一个非常诡异的问题：用户反馈说，在 win10 电脑上，蓝牙鼠标和键盘经常出现“假死”现象，手机连蓝牙耳机也有概率断连。我们一开始怀疑是硬件问题，但换了好几台设备都一样。后来我决定直接在 win10 电脑上抓蓝牙 HCI 包，用 Wireshark 配合微软官方提供的工具来定位。

操作流程大致是这样：

1. 打开“设置”，进入“隐私和安全性”，找到“诊断和反馈”，把“可选诊断数据”打开，这一步是为了让系统输出蓝牙相关的日志。
2. 用管理员身份打开 PowerShell，执行netsh tracing start capture=yes开启系统级网络追踪捕获。
3. 复现问题，让蓝牙设备出现断连或假死。
4. 回到 PowerShell，执行netsh tracing stop结束捕获。
5. 把生成的 ETL 文件用etl2pcapng工具转换成 pcapng 格式，再用 Wireshark 打开分析。
6. 在 Wireshark 的过滤栏里输入btl2cap或btrfcomm，筛选蓝牙逻辑链路控制和适配协议的数据包，观察连接断开时的具体控制信号。

那次排查的结论是，蓝牙鼠标在进入低功耗模式后，和电脑之间的链路层连接因为某些外部射频干扰出现了异常，但系统没有做链路重建，导致设备看起来像“假死”。这个问题的本质上也是一个“状态不可见”的问题——设备状态变了，用户和系统都没有得到明确的反馈，于是体验失控。这和 UI 设计里的反馈闭环其实是一回事，只是发生层面不同。

所以你看，HCI 的双重含义在“反馈”这个主题上竟然能完美交汇：界面需要给用户反馈，协议栈需要给开发者反馈。任何一层缺了反馈，最终都会表现为用户体验的失控。

5. 常见设计问题与排查技巧：快速定位你的界面哪里违背了黄金三原则

5.1 高频违规场景清单和修正方向

在实际工作中，我看到太多团队在产品上线后收到用户差评，却不知道怎么定位原因。很多问题其实一眼就能看出是违背了哪条原则。我把这些年遇到的高频场景整理成一个速查表，方便对照排查：

这份清单可以打印出来贴工位上，做设计自查或者代码走查的时候顺手过一遍，很多低级问题能被直接拦截。

5.2 我踩过的一个低级错误：一致性检查没做到全局，结果出了事故

这里分享一个让我印象很深的翻车案例。我之前负责一个中大型系统的改版，当时组件库还不太成熟，很多页面是历史遗留的，视觉风格五花八门。我们在做新版设计时，把所有新增页面的按钮位置、弹窗样式都统一了，但老页面的入口没有同步改造。结果就是：用户在新版页面学会了“右上角垃圾桶图标是删除”，到了老页面发现删除按钮在底部左下方，还是红色的方块按钮。

问题上线后，用户的投诉量立刻飙升，不是因为这个功能不好用，而是因为用户在新旧页面之间来回切换时，心智模型被反复打碎。后来我们花了两周的时间把所有老页面的删除入口全部统一成同一模式。这件事让我记住一个教训：一致性检查不能只查新页面，必须全局扫一遍，尤其是新旧功能并存的过渡期，跨页面的一致性比单页面内部的一致性更容易出错。

5.3 设计师和开发怎么协同用三原则评审

如果你不是设计岗，而是开发或产品岗，也可以把三原则用在需求评审里。开发在接需求时，如果觉得某个交互实现起来很复杂，可以先用三原则做一轮判断，把问题抛回给产品：

• “这个操作流程里，用户怎么撤销？”
• “这个错误提示放在哪个位置，用户才能看到？”
• “这个交互模式和上次做的那套有什么区别，有没有可能统一？”

这些问题如果能在开发启动前就问清楚，能省掉后面联调时大量的返工。三原则不是设计师的专属工具，它是整个团队可以对齐的语言。

6. 写在最后：关于理论、落地和我的一点体会

Mandel 的黄金三原则之所以是“黄金”，不是因为它高深，而是因为它精确地抓住了人机交互中那些最朴素、最容易出错的地方。它不像某些设计方法论那样需要复杂的前置条件才能使用，也不需要你去背大量的概念，它就是三条朴素到近乎常识的准则。但越是朴素的原则，越需要在真实项目中反复地执行、验证、再执行，才能真正变成团队的设计习惯。

我在实际项目中最大的体会是：这三条原则单独拿出来看都不难，真正的难点在于一致性执行——每个页面都做到用户控制感清晰、记忆负担最小、交互模型统一。这需要设计师有全局视野，也需要开发在产品实现时愿意为“体验细节”多花一点成本。很多时候，用户嘴上说不出来自己为什么觉得一个系统难用，但他的每一步犹豫、每一次误操作、每一次回头找信息，背后都是这三条原则在某个点上被忽视了。

最后再分享一个我一直在用的小技巧：每当你在设计一个功能时不知道该怎么取舍，试着把自己的界面切换成“第一次打开”的心智状态，闭上眼睛想一想，如果我现在对这个系统一无所知，我看到的每一个按钮、每一段文案、每一次跳转，我会不会困惑？这个模拟方式，比任何检查清单都直接，因为它逼着你从用户的角度重新走一遍界面，而这个过程里，黄金三原则会自然地浮出水面。