Alan Cooper · Robert Reimann · David Cronin · Christopher Noessel
V2.0
2026-07-29
《About Face 4》
交互设计精髓
目标导向设计的经典之作。40 个核心观点按五大类重新编排——从方法论到认知心理学,从交互原则到视觉设计,再到系统规范,形成一条完整的知识脉络。
第一篇
设计思维与方法论
1.1
目标导向设计
1.1
目标导向设计
Goal-Directed Design — 从用户目标出发,而非从技术功能出发
不要问"这个功能怎么做",要先问"用户想达成什么目标"。目标是稳定的,而任务和技术手段是多变的。设计的重点是理解用户真正的目标,然后倒推设计解决方案,而非在现有技术框架内填功能。
✓ 正向例子
iPhone 早期的闹钟应用:用户目标是"按时起床",设计师没有堆砌复杂的排班、循环规则、标签分类系统,而是用一个滚轮让用户在 3 秒内设好闹钟。滑动即设置,无需确认按钮。
✗ 反向例子
某企业考勤系统:员工目标是"快速打卡"。但系统要求先选择"考勤类型"(上班/下班/加班开始/加班结束/外出/归来),再确认定位,再输入备注,最后输入密码。为打卡这一简单目标堆砌了 5 步操作。
交互演示 — 点击展开查看正反对比
✓ 正面示范
⏰ 快速闹钟设置
7:30 AM
7
30
AM
✗ 反面示例
📋 复杂考勤打卡
步骤 1/5
1.2
用户研究为先
1.2
用户研究为先
Research Before Design — 没有用户研究的设计只是猜测
不要假设你了解用户。通过民族志观察、情境访谈、用户日记等方法去理解用户真实的行为、动机和环境。利益相关者说什么不等于用户做什么,用户自己说的也不等于他们实际做的。
✓ 正向例子
Cooper 团队在为一款医疗影像系统做设计前,花数周时间在医院放射科实地观察医生的工作流程——发现医生在诊断时需要在 3 个不同系统间反复切换,这是任何访谈中医生都不会主动提及的痛点。
✗ 反向例子
一个创业团队想当然地认为"老年人需要超大字体的手机",未经调研就推出了字体大到每屏只能显示 3 行的手机。实际研究发现,老年人更关心的是防诈骗、一键联系家人,而非单纯的字体放大。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🔍 实地观察发现
观察记录 #12
放射科医生在诊断时需在3个系统间反复切换:PACS查看影像 → EMR查看病史 → RIS追踪检查状态。医生手动在纸上记下患者ID,在3台电脑间轮转。
放射科医生在诊断时需在3个系统间反复切换:PACS查看影像 → EMR查看病史 → RIS追踪检查状态。医生手动在纸上记下患者ID,在3台电脑间轮转。
真实引用
"我每天要在这3台电脑之间来回走50次以上"——受访医生Dr. Chen
"我每天要在这3台电脑之间来回走50次以上"——受访医生Dr. Chen
✗ 反面示例
🤔 会议室里的假设
产品经理:"老年人嘛,肯定需要大字,我们把字体调到最大"
设计师:"同意,再加大按钮,字号搞到28px"
结果:一屏只能显示3行内容,老年人真正需要的"一键呼叫家人""防诈骗"功能完全没有。
1.3
建立人物模型
1.3
建立人物模型
Personas — 用具体的人物画像替代模糊的"用户"概念
"用户想要……"是最危险的句式之一。真实用户千差万别。人物模型(Persona)是将用户研究数据合成为具体、可信的人物原型——有名字、照片、目标、痛点、行为模式。每个设计决策都要能回答"这对我们的首要人物模型有什么好处?"
✓ 正向例子
某银行 App 设计团队定义了"小琳——28 岁的职场新人,对理财焦虑但渴望学习,通勤时间 45 分钟,习惯在地铁上用左手单手操作手机"。这个具体画像指导了单手操作优化和理财教育内容的信息架构。
✗ 反向例子
产品需求文档里写"我们的用户是所有 18-55 岁的智能手机用户"。这个模糊定义无法指导任何具体设计决策——18 岁大学生和 55 岁退休人员的需求、行为、环境完全不同。
交互演示 — 点击展开查看正反对比
✓ 正面示范
👤 清晰人物模型
小琳
年龄:28岁 | 职业:职场新人
目标:减少理财焦虑,学习投资入门
行为:通勤45分钟,习惯左手单手操作
痛点:理财术语看不懂,怕亏钱不敢投
✗ 反面示例
📊 模糊用户定义
"我们的目标用户是
所有18-55岁的智能手机用户"
所有18-55岁的智能手机用户"
这个定义无法回答任何设计问题:
• 首页放几个入口?不知道,用户范围太广
• 用多大字号?18岁和55岁的需求正相反
• 用什么导航?大家的偏好都不一样
• 首页放几个入口?不知道,用户范围太广
• 用多大字号?18岁和55岁的需求正相反
• 用什么导航?大家的偏好都不一样
1.4
基于场景设计
1.4
基于场景设计
Scenario-Based Design — 用叙事定义理想体验
不要从界面控件开始设计,先从"理想用户体验故事"开始。写一段叙述,描述人物模型在理想世界中如何达成目标。这个叙事会揭示出真正的功能需求和交互细节,而不是让你在功能清单上勾选。
✓ 正向例子
设计打车 App 时先写出场景:"小雨走出公司大门,打开 App,地图已自动定位。她看到附近有几辆车,预估 3 分钟到达。她点击'回家'快捷按钮,系统自动匹配。她不需要输入任何地址。"从场景倒推出自动定位、常用地址、预估时间等核心功能。
✗ 反向例子
产品经理直接给出一份功能清单——"要有地图选点、地址搜索、历史记录、收藏地址、路线预览……"工程师按清单实现后,用户发现叫车需要 7 个步骤,因为设计者从未从使用场景出发串联这些功能。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📖 场景叙事驱动设计
🏢 走出公司 →
📱 打开App(自动定位) →
🏠 点击"回家"快捷按钮 →
🚗 系统匹配车辆 →
✅ 3分钟上车
从场景倒推出的功能:自动定位、常用地址、预估时间、一键叫车
✗ 反面示例
📋 功能清单驱动
☑ 地图选点功能
☑ 地址搜索框
☑ 历史记录列表
☑ 收藏地址管理
☑ 路线预览
☑ 价格预估
☑ 车型选择
☑ 支付方式
结果:功能齐全但需7步操作,因为设计者从未串起来走过一遍完整流程
1.5
可用性贯穿全程
1.5
可用性贯穿全程
Usability Testing — 设计过程全程验证,而非最后才测试
不要等到开发完成才做可用性测试。从纸面原型开始就要测试——越早发现问题,修复成本越低。可用性测试不是证明设计正确,而是发现设计的问题。5 个用户就足以发现 85% 的可用性问题。重要的是观察用户做什么,而非听他们说什么。
✓ 正向例子
IDEO 和 Cooper 的工作方式:在设计早期阶段使用纸质原型或低保真可点击原型进行"快速迭代测试"——找 5 个目标用户,观察他们完成任务的过程,记录他们在哪里卡住,当天修改原型,第二天再测。3 轮迭代通常能发现并解决绝大多数关键问题。
✗ 反向例子
某团队在产品上线前一周才请用户来测试。测试中发现了核心导航结构的问题——用户找不到主要功能入口。但此时修改需要重构前端路由和数据库关联,团队最终以"来不及改了"为由上线了一个用户找不到功能的产品。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🔄 持续测试流程
纸面原型
测试5人
测试5人
低保真
测试5人
测试5人
高保真
测试中…
测试中…
开发中
持续验证
持续验证
每轮只测5个用户 → 当天修改 → 次日再测 → 3轮解决85%问题
✗ 反面示例
⏰ 最后关头测试
需求
设计
开发
开发
⚠测试
上线
上线前1周才发现导航结构问题 → "来不及改了" → 带着问题发布
1.6
交互设计不是凭空猜测
1.6
交互设计不是凭空猜测
Design Is Not Guesswork — 每一个设计决策背后都应有据可依
交互设计的每一处细节都应该建立在研究、数据和洞察之上——用户访谈记录、可用性测试数据、行为分析报告、已验证的设计原则。"我觉得这样好"不是设计理由,"用户在测试中这样使用"才是。直觉很重要,但直觉也必须经过验证。
✓ 正向例子
Spotify 的 Discover Weekly:推荐歌单不是设计师凭感觉"挑选"出来的,而是基于数十亿用户的收听数据、协同过滤算法和持续 A/B 测试迭代而成的。每一个设计决策——封面图尺寸、播放按钮位置、歌单长度——都经过数据验证。
✗ 反向例子
某产品经理在会议上说"我觉得用户一定喜欢这个功能",没有调研、没有数据、没有测试,就推动团队开发了一个复杂的"社交分享"模块。上线后使用率仅 0.3%,而真正需要修复的核心体验问题却因资源被挤占而无人关注。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📊 数据驱动的设计决策
🔬 用户研究
5人可用性测试 → 3人找不到"导出"按钮
5人可用性测试 → 3人找不到"导出"按钮
📈 数据分析
78%用户在导出步骤放弃操作
78%用户在导出步骤放弃操作
🎯 设计决策
将导出按钮移至顶部工具栏,字号放大至16px
将导出按钮移至顶部工具栏,字号放大至16px
每个设计决策都有据可依:研究→数据→洞察→决策
✗ 反面示例
💬 会议室里的"我觉得…"
👤 PM:"我觉得用户会喜欢社交分享功能"
👤 设计师:"竞品都做了,我们也应该做"
👤 老板:"就这样,下周上线"
📉 结果:3个月后,分享功能使用率 0.3%,核心体验bug无人修复
1.7
绝不向利益关系人展现你不满意的设计方案
1.7
绝不向利益关系人展现你不满意的设计方案
Cooper's Law — 你不满意的方案,利益关系人可能正好喜欢
这就是所谓的"Cooper's Law"——当你向老板或客户展示两个方案(一个好的和一個妥协的)时,他们总是选中那个你不喜欢的。好的设计往往看起来"显而易见"甚至"无聊",而妥协方案通常看起来更"丰富"、堆了更多功能。只展示你愿意为之负责的设计。
✓ 正向例子
一个成熟的设计团队在做方案汇报时,只带一个方案进会议室——那个经过充分研究、测试和迭代后团队一致认为最好的方案。展示时用用户研究数据和场景叙事支撑每个设计决策,而非让利益关系人在两个方案间"投票"。
✗ 反向例子
设计师准备了方案 A(简洁、聚焦用户目标)和方案 B(妥协版,加入了产品经理要求的各种"万一用到"的按钮)。CEO 看了一眼说"A 太简单了,B 功能更丰富,我喜欢 B"。设计师只能无奈地去实现自己都不认同的设计。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📋 只展示你愿意负责的方案
方案 A — 经过验证的设计
📊 用户测试 N=15
📈 A/B 验证
🎯 目标对齐
一张幻灯片,一个方案,用数据支撑每个决策
不做多选题——只呈现经过充分验证、团队愿意为之负责的设计
✗ 反面示例
🎭 两个方案的陷阱
方案 A
简洁 · 研究驱动
聚焦核心目标
聚焦核心目标
设计师喜欢 ✅
方案 B
功能多 · 按钮多
"看起来更丰富"
"看起来更丰富"
CEO 选了 👈
CEO:"A太简单,B功能多,做B!" → 设计师无奈执行自己不看好的方案
第二篇
用户认知与心理学
2.1
贴近心智模型
2.1
贴近心智模型
Implementation Model vs Mental Model — 让界面贴近用户心智,而非暴露系统内部结构
实现模型是软件内部如何运作(数据库表、API 调用链、类继承关系)。心智模型是用户脑中如何理解事物运作。好的设计让"表现模型"尽可能贴近用户的心智模型,而不是暴露实现细节。
✓ 正向例子
Mac 的"废纸篓":用户的心智模型是"文件扔进垃圾桶即可丢弃",不需要理解 inode、block、文件系统引用计数。拖入即删除,清空即释放空间——完全匹配物理世界心智。
✗ 反向例子
某企业内部系统的消息通知设置:用户看到"Webhook 回调地址""消息队列优先级""重试策略:指数退避"等选项。这是把后端实现模型直接暴露给非技术用户,造成了巨大的认知负担。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🗑️ 符合心智模型
→ 拖入
用户理解:"文件扔进垃圾桶 = 删除"
不需要知道 inode / block / 引用计数
不需要知道 inode / block / 引用计数
✗ 反面示例
💻 暴露实现模型
消息通知设置
2.2
识别优于回忆
2.2
识别优于回忆
Recognition over Recall — 让用户"认出来"而非"想出来"
人类识别能力远强于回忆能力。你能从 100 张面孔中认出朋友,却很难凭记忆画出朋友的精确五官。界面应该让用户看到选项后"认出来",而不是强迫用户记住并"想出来"。下拉菜单优于空白的命令行。
✓ 正向例子
淘宝搜索框的下拉建议:你输入"蓝",下拉列表显示"蓝牙耳机""蓝衬衫""蓝牙音箱"等历史搜索和相关推荐。你不需要回忆起完整的关键词,看到了就能认出来并点击。
✗ 反向例子
某命令行工具要求用户输入完整的 ISO 国家代码(如"CN""US""JP")才能继续。没有下拉菜单,没有模糊搜索,没有列表参考。用户必须准确回忆出代码字符串,否则程序就报错退出。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🔍 搜索建议(识别)
🔍 蓝牙耳机
🔍 蓝衬衫
🔍 蓝牙音箱
🔍 蓝光眼镜
看到了 → 认出来了 → 点击,无需完整回忆
✗ 反面示例
⌨️ 命令行(回忆)
$ country-code █
Error: 请输入准确的ISO国家代码(如CN/US/JP)
用户必须准确回忆出代码字符串,
没有下拉菜单、没有参考列表、没有模糊搜索
没有下拉菜单、没有参考列表、没有模糊搜索
2.3
满意即可原则
2.3
满意即可原则
Satisficing — 用户不会追求最优解,找到"足够好的"就会停
Herbert Simon 提出的"满意即可"(Satisficing = Satisfy + Suffice)概念:真实用户不会穷尽所有选项找最优解——他们在找到第一个可接受的方案时就停止了。设计应帮助用户快速找到"足够好的"方案,而非迫使他们比较一切。
✓ 正向例子
大众点评的"附近美食":你不会一家家比较全城 5000 家餐馆。你会看排名前 10、评分 4.5 以上的,选第一家看起来不错的。平台用排序、评分、距离帮你快速"满意即可",而非让你做穷举决策。
✗ 反向例子
某 B2B 采购平台将全部供应商以无排序的表格列出(3000+ 行),要求用户自行比较所有参数后选择。没有推荐、没有筛选、没有排序。将"满意即可"的消费决策强行变成了"穷尽比较"的分析任务。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🍽️ 帮你快速找到"够好的"
⭐ 4.9 老王面馆 · 步行3分钟 · 人均¥25
⭐ 4.8 川味小馆 · 步行5分钟 · 人均¥35
⭐ 4.7 粤式茶餐厅 · 步行8分钟 · 人均¥50
排序+评分+距离 → 用户从最顶上选一个即可,10秒决策
✗ 反面示例
📊 强迫穷尽比较
供应商列表(共3,247条,无排序、无筛选)
供应商A★★★☆☆¥¥中等3天…
供应商B★★★★☆¥¥¥远7天…
供应商C★★☆☆☆¥近1天…
2.4
保护用户心流
2.4
保护用户心流
Flow State — 让用户沉浸在任务中,不被系统打断
Mihaly Csikszentmihalyi 的心流理论:当人沉浸在某事中时,效率和满足感都达到峰值。软件应该保护和促进用户的心流——消除不必要的打断、自动保存进度、预加载内容。每弹出一次"确认吗?""有新版本!"都是对心流的破坏。
✓ 正向例子
Notion 的编辑体验:你输入时页面自动保存(无保存按钮),侧边栏可以随时收起以扩大编辑空间,Markdown 快捷输入让你手不离键盘。没有自动弹窗,没有"确认离开?"——一切都默默地保护你的写作心流。
✗ 反向例子
某写作软件在用户打字时每隔 20 分钟弹出"有新版本可用,是否立即更新?"的模态对话框,还附带"稍后提醒""跳过此版本""了解更多"三个选项。用户刚进入写作状态就被打断,被迫做出一个不相关的技术决策。
交互演示 — 点击展开查看正反对比
✓ 正面示范
✍️ 保护写作心流
今天我想分享的是关于交互设计的一些思考……
(打字中,没有弹窗,没有保存按钮,没有"确认离开?")
▌
✗ 反面示例
🚫 打断心流
⚠ 软件更新
有新版本 v3.2.1 可用!
更新内容:修复了一些已知问题
更新内容:修复了一些已知问题
(你刚写的文字被遮住了……)
2.5
希克定律
2.5
希克定律
Hick's Law — 选择越多,决策越慢
用户面对 N 个选项时,决策时间与 log₂(N+1) 成正比。这不是说只能有 2 个选项,而是说不要把所有可能性同时摊在用户面前。用分类、搜索、推荐来减少每个时刻的选择数量。
✓ 正向例子
Airbnb 的搜索流程:先选目的地(减少范围)→ 再选日期(再减少)→ 再选人数(再减少)。每一步只呈现与该步骤相关的选择。最终搜索结果页面用地图、价格滑块、设施筛选进一步缩小范围,绝不会一次展示几万条房源。
✗ 反向例子
某企业软件的设置页面将所有 200+ 配置项平铺在一个超长页面中,没有分组、没有搜索、没有分类标签。用户为一个简单设置需要滚动查找数分钟。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🎯 逐步收缩选择
📍 目的地 → 城市
📅 日期 → 本周末
👥 人数 → 2人
🏠 结果:12套房源
每步只呈现与本步相关的选项,从数万套房源逐步缩小到12套
✗ 反面示例
📜 海量平铺选项
系统设置(共213项,无分类)
☐ 启用SSL验证
☐ 邮件通知频率
☐ 会话超时时间
☐ 默认语言
☐ 时区设置
☐ 日期格式
☐ 文件上传大小限制
☐ 用户权限模式
☐ …还有205项
2.6
菲茨定律
2.6
菲茨定律
Fitts' Law — 目标越大越近,点击越快
点击一个目标所需的时间,与目标大小成反比,与距离成正比。重要、常用的按钮应该更大,放置在更容易到达的位置。屏幕边缘(macOS 菜单栏在顶部边缘)具有"无限高度"——鼠标撞到屏幕边界就停住了,实际上增大了可点击区域。
✓ 正向例子
macOS 将菜单栏放在屏幕顶部边缘——鼠标向上甩到顶自动停住,使菜单项拥有"无限高度"的可点击区域。Windows 的右键菜单在光标旁边弹出,最小化了移动距离。两者都是菲茨定律的经典应用。
✗ 反向例子
某网页播放器将"播放/暂停"按钮设计为 12×12 像素的小圆点,放在页面角落,距离用户通常的光标位置很远。而这个按钮是视频页面使用频率最高的控件。小尺寸 + 远距离 = 最差的可点击效率。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🎯 大尺寸 + 近距离 = 快速点击
▶ 播放
⏸ 暂停
⏹ 停止
大按钮(56px)、紧密排列、屏幕边缘 → 快速可达
✗ 反面示例
🔬 微小 + 远距离 = 难以点击
视频播放器
▶
← 距离光标位置很远 →
12×12px小按钮、放在角落、远离光标 → 最难点击的组合
2.7
没有人愿意停留在新手级别
2.7
没有人愿意停留在新手级别
Nobody Wants to Remain a Beginner — 用户渴望成长,设计应支持平滑进阶
没有人以"我是新手"为荣。用户在使用产品时不断学习和进步。好的设计为初学者提供引导和捷径,同时也为高级用户提供快捷键、高级功能和效率工具。永远不要以"用户没那么聪明"为由拒绝提供高级功能——用户会成长,你的界面应该支持这种成长。
✓ 正向例子
Superhuman 邮件客户端:新手可以用鼠标点击完成所有操作,但界面上始终有快捷键提示(如 ⌘K 打开命令面板)。用户自然而然地从鼠标操作过渡到键盘操作,完成从新手到专家的转变。没有一个用户被"锁定"在初级模式中。
✗ 反向例子
某设计工具为了"降低学习门槛",隐藏了所有高级功能,也不提供快捷键。初级用户用得开心,但 3 个月后当他们需要批量导出、自定义网格、高级图层操作时,发现这些功能根本不存在——产品把所有用户都当成了永远的新手。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📈 支持用户从新手到专家的成长路径
🔰 第1周 · 新手阶段
🖱️ 点击操作
💡 提示引导
⚡ 第3周 · 进阶阶段
⌨️ 快捷键 ⌘K
📌 固定常用
🚀 第8周 · 专家阶段
⚡ 命令面板
🔗 自定义工作流
同一个产品,支持从点击→快捷键→自动化的完整成长弧线
✗ 反面示例
🔒 "永久新手模式"
📱 简易设计工具
"为降低学习门槛,我们简化了一切"
❌ 无快捷键
❌ 无批量操作
❌ 无自定义选项
❌ 无高级导出
3个月后的用户评价:
"功能太少了,换别的工具了"
"功能太少了,换别的工具了"
2.8
将用户想象成非常聪明但非常忙的人
2.8
将用户想象成非常聪明但非常忙的人
Smart but Very Busy — 用户有能力理解复杂事物,但没有时间浪费在糟糕的设计上
这是 Alan Cooper 最著名的设计哲学之一。不要假设用户笨——他们不笨,只是不想在你的界面上花费不必要的认知精力。用户能在瞬间判断一个界面是否值得他们花时间。尊重用户的智力,但不要浪费他们的时间。简洁不是把用户当傻子,而是帮他们把精力花在真正重要的事情上。
✓ 正向例子
Google 搜索——一个输入框就能处理"巴黎最好的咖啡店在哪里 评分4星以上 人均不超过20欧元"这样复杂的自然语言查询。背后的技术极其复杂(自然语言处理、知识图谱、个性化排序),但界面极其简单。这同时尊重了用户的智力(能理解复杂查询)和时间(不需要学习高级搜索语法)。
✗ 反向例子
某 App 每次用户执行一个操作后都弹出长达 3 段文字的"温馨提示",用教小孩的语气解释刚才发生了什么。用户读了两次后直接关闭了通知权限。好的设计用清晰的界面本身来沟通,而非居高临下的说教文字。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🔍 极简界面处理复杂需求
Search
"巴黎最好的咖啡店 评分4星以上 人均低于20€"
背后:NLP语义理解 · 知识图谱 · 个性化排序 · 实时索引
用户不需要学习高级搜索语法——把复杂性留给系统,把简洁留给用户
✗ 反面示例
📢 居高临下的"温馨提示"
👋 恭喜你!
你刚才成功发送了一条消息!
消息会出现在对方的聊天列表中。
如果对方在线,会收到通知提醒。
你可以在"设置→通知"中管理提醒方式。
消息会出现在对方的聊天列表中。
如果对方在线,会收到通知提醒。
你可以在"设置→通知"中管理提醒方式。
📸 太棒了!
你上传了一张照片!
照片会保存在你的相册中。
…(每次操作都弹3段说教文字)
照片会保存在你的相册中。
…(每次操作都弹3段说教文字)
用户不是小孩——好的设计本身就说明一切,不需要说教式的"温馨提示"
2.9
不要让用户觉得自己很愚笨
2.9
不要让用户觉得自己很愚笨
Don't Make Users Feel Stupid — 用户的错误通常是设计的问题,而非智力的缺陷
当用户在界面上犯错时——点了错误的按钮、输入了错误的格式、找不到某个功能——他们不应该感到愚蠢。错误消息不应指责用户("非法输入!"),而应帮助用户纠正("日期格式应为 YYYY-MM-DD")。最好的设计甚至不让这些错误有机会发生。设计的目标是让用户感到自己有能力,而非无能。
✓ 正向例子
TurboTax 的报税软件:当用户输入可能有误的数字时,它不说"错误!",而是说"这个数字看起来比去年高很多,你确认是对的吗?"用一种关心而非指责的语气。如果用户确实犯了错,软件提供一键修复建议,而非让用户自己摸索。
✗ 反向例子
某命令行工具在用户输错参数后输出:"FATAL ERROR: Invalid syntax. You must specify --config with a valid path."用户不仅没解决问题,还感觉自己是"犯了致命错误的白痴"。错误信息用词居高临下,把系统限制变成了对用户智力的否定。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🤝 友善的错误提示
💡
这个数字看起来比去年高很多
你去年的收入是 ¥120,000,今年输入的是 ¥1,200,000。这是准确的吗?
用关心而非指责的语气,提供"一键修复"而非"自己想办法"
✗ 反面示例
💢 指责性的错误信息
FATAL ERROR
Invalid syntax at line 4.
Error: You must specify
--config with a valid path.
--config with a valid path.
Type --help for more
information.
information.
$ _
"FATAL ERROR" + 居高临下的语气 = 用户不仅没解决问题,还感觉自己是个"白痴"
第三篇
核心交互原则
3.1
遵循设计原则
3.1
遵循设计原则
Design Principles — 原则是设计的"宪法",不是建议
Cooper 提出了一组交互设计原则作为设计的"宪法",包括:用户界面应该基于用户的心智模型、少就是多、让用户直接操纵、每个操作都要有反馈、让用户感觉掌控一切。这些原则不是"最好遵守",而是设计的底层逻辑。
✓ 正向例子
Google 搜索首页——一个输入框、两个按钮。二十多年来,在无数的功能压力下,首页始终保持极简。因为设计师恪守"用户目标是搜索,不要任何干扰"这一原则。
✗ 反向例子
很多企业门户首页塞满了新闻公告、轮播图、快捷入口、待办事项、天气、股票、生日提醒……用户真正要的"找到并进入目标系统"这个核心任务被淹没在信息噪音中。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🔍 恪守原则的极简搜索
Search
只有一个输入框 + 两个按钮,用户目标(搜索)100%占据视觉中心
✗ 反面示例
🏢 违反原则的混乱门户
📰 董事长讲话 | 🌤 今日天气28°C | 📈 股票行情 | 🎂 员工生日提醒
用户真正需要的搜索功能被埋在信息噪音中,每次都要扫描才能找到
3.2
避免模态打断
3.2
避免模态打断
Modeless Design — 不要让对话框打断用户的流程
模态(Modal)状态是指用户被困在一个"模式"中,必须先处理当前对话框才能回到主流程。虽然某些场景下模态是必要的(如确认支付),但绝大多数模态对话框都可以被非模态方案替代——它们打断用户心流,增加认知负荷,是"懒惰的设计"。
✓ 正向例子
Google Docs 的"分享":点击分享按钮,弹出的是一个悬浮面板而非模态对话框。即使面板打开着,你仍然可以滚动文档、编辑文字、查看其他内容。它是一个"呼之即来,挥之即去"的工具,不是一道关卡。
✗ 反向例子
某 Windows 软件:用户想保存文件,弹出模态对话框要求先填写"文档标签""作者""部门""保密级别"四个必填字段。用户只是想保存一下继续工作,却被卡在了这个保存模式中。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🔲 非模态面板
这是一篇正在编辑的文档。你可以看到分享面板在右侧打开着……
但你仍然可以继续滚动、编辑、查看文档内容。
分享面板不是一道"关卡",而是一个呼之即来、挥之即去的工具。
📤 分享
✗ 反面示例
🚫 模态弹窗打断
用户只是想保存一下继续工作,却被卡在了这个"保存模式"中
3.3
直接操纵对象
3.3
直接操纵对象
Direct Manipulation — 让用户直接"触摸"对象而非通过代理操作
直接操纵是人类最自然的交互方式——用手指点、拖、捏。在数字界面中,这意味着用户应该能直接作用于视觉对象(拖拽排序、缩放图片、滑动删除),而不是通过菜单、对话框、属性面板遥控。
✓ 正向例子
iOS 照片编辑:裁剪时直接用双指捏合缩放、拖动调整构图区域。旋转时用双指旋转。用户感觉是"在操作照片本身",而非操作一组抽象的数字参数。即时预览让每步调整都可见。
✗ 反向例子
某网页端图片编辑器:裁剪需要在侧边栏输入"左: ___px 上: ___px 宽: ___px 高: ___px"四个数值,然后点击"预览"查看效果。切断了直接操纵的闭环,把视觉任务变成了数学题。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🖐️ 直接操纵图像
拖拽裁剪框手柄直接调整构图,所见即所得
✗ 反面示例
🔢 数值输入裁剪
裁剪参数:
px
px
px
px
视觉任务变成了数学题——输入数字 → 点预览 → 不对 → 修改数字 → 再预览 → 循环…
3.4
即时操作反馈
3.4
即时操作反馈
Immediate & Meaningful Feedback — 每次操作都应有回应
用户每执行一个动作,系统都应给予反馈。按下按钮要有状态变化,提交表单要有结果通知,加载中要有进度指示。无声的界面是最让人不安的——用户会怀疑"到底成功了吗?""要不要再点一次?"
✓ 正向例子
Gmail 删除邮件时:邮件条目立即从列表中滑出消失,底部出现一个 Snackbar 提示"已删除",并提供"撤销"按钮。用户同时获得了即时视觉反馈和操作结果确认。
✗ 反向例子
某银行的转账页面:用户点击"确认转账"后,页面没有任何变化,按钮也没有禁用或显示加载状态。用户等了 5 秒没反应,再次点击——结果触发了重复转账。没有任何进度反馈或状态变化。
交互演示 — 点击展开查看正反对比
✓ 正面示范
✅ 即时反馈的按钮
点击 → 禁用+加载态 → 成功反馈 → 恢复,每个状态用户都看得见
✗ 反面示例
❓ 无反馈的按钮
点击后无视觉变化 → 用户疑惑"成功了?" → 再点一次 → 重复转账!
3.5
提供普遍撤销
3.5
提供普遍撤销
Pervasive Undo — 让用户有"后悔药"可吃
人类会犯错,这是不可改变的事实。好的设计不责备用户,而是给用户一个安全网。每个可能产生后果的操作都应该可以撤销——不是用警告对话框阻止用户,而是让用户放心尝试,知道可以随时回头。
✓ 正向例子
macOS 的"存储为"对话框:你要覆盖一个同名文件时,系统不说"确认要覆盖吗?",而是显示"替换"或"取消"——更关键的是,Finder 和 Time Machine 让文件级操作几乎处处可撤销。删错了?从废纸篓还原即可。
✗ 反向例子
某表单系统的"删除"按钮:点击即永久删除,无确认、无回收站、无撤销。用户误触后只能联系管理员从数据库恢复。这种设计把系统的技术限制变成了用户的焦虑。
交互演示 — 点击展开查看正反对比
✓ 正面示范
↩️ 可撤销的操作
✅ 已删除"报告.pdf"
不做警告弹窗,而是让操作可撤销——用户放心尝试,知道可以随时回头
✗ 反面示例
💀 永久删除
无确认、无回收站、无撤销——误触后只能联系管理员从数据库恢复
3.6
预防优于补救
3.6
预防优于补救
Error Prevention — 最好的错误消息是没有机会出现的错误消息
与其写一条友好的错误提示,不如把这个错误变成不可能发生的。用约束设计(输入框只接受数字、日期选择器而非文本输入、按钮在条件不满足时禁用)来主动消除出错的可能性。
✓ 正向例子
航班预订的日期选择:去程日期选择器自动将"返程日期"的最小值设为去程日期 + 1 天。用户无论如何操作都无法选择"返程早于去程"的日期组合——这个错误被设计从根本上消灭了。
✗ 反向例子
某注册表单的日期字段允许用户手动输入任意字符串,提交后弹出"您输入的日期格式不正确,请使用 YYYY-MM-DD 格式"的错误提示。设计者本可以用一个日期选择控件从源头消除这个问题。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📅 日期选择器(约束设计)
返程日期自动限制为去程+1天起 → "返程早于去程"这个错误被设计消灭了
✗ 反面示例
📝 自由文本输入(无约束)
❌ 您输入的日期格式不正确,请使用 YYYY-MM-DD 格式
本可以用日期控件消灭的问题,却留给用户一个错误提示
3.7
消除附加工作
3.7
消除附加工作
Eliminating Excise Tasks — 用户的时间应该花在目标上,而非工具上
附加工作(Excise)是用户为了实现目标而不得不做的、与目标本身无关的操作。比如:在多个窗口间切换、手动输入系统已知道的信息、等待加载时无事可做。好的设计不断追问"能否减少一步?能否预填?能否自动化?"
✓ 正向例子
1Password 浏览器插件:在登录页面检测到用户名和密码字段时,自动填充已保存的凭据。用户不用回忆密码、不用打开密码管理器、不用复制粘贴。填充、登录,一步完成。记住密码、自动填充密码这些附加任务被完全消除。
✗ 反向例子
某报销系统:员工报销一笔差旅费需要(1)手动输入日期(2)选择费用类型(3)输入金额(4)上传发票图片(5)输入发票号码(6)选择成本中心(7)填写事由说明。第 3、5、6 步的信息在发票图片和员工档案中已存在,却要求员工再次手动搬运。
交互演示 — 点击展开查看正反对比
✓ 正面示范
⚡ 自动填充(消除附加工作)
✓ 1Password自动检测并填充 → 一键登录,无需回忆、无需复制粘贴
✗ 反面示例
📋 手动搬运信息(附加工作)
步骤 3/7:输入报销信息
发票号码、金额、成本中心在发票图片和员工档案中已存在,却要求手动搬运
3.8
重大改变必须是非常好的改变
3.8
重大改变必须是非常好的改变
Big Changes Must Be Really Good Changes — 颠覆用户习惯的代价很高,收益必须更高
用户在使用你的产品时会形成肌肉记忆和认知习惯。每次重新设计界面、改变交互方式、移动按钮位置,都是在破坏用户已经建立的神经通路。这并不意味着不能改变——而是改变必须有足够好的理由。新方案的好处必须远大于用户重新学习的成本,否则就是不划算的交易。
✓ 正向例子
iPhone X 去掉 Home 键改用全面屏手势——这个改变极其巨大:数亿用户已习惯按压 Home 键返回桌面。但好处也同样明显:屏幕更大、沉浸感更强、手势操作更流畅。苹果投入了大量资源设计过渡动画和引导,让这个重大改变值得用户重新学习。
✗ 反向例子
某 SaaS 产品每季度做一次"全新改版"——菜单从顶部移到左侧,再移到底部 Tab 栏,又改成汉堡菜单。每次改版都没有明确的体验提升目标,只是"看起来更新了"。用户苦不堪言,每次登录都要重新找功能位置,老用户流失率持续攀升。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📱 值得用户重新学习的重大改变
旧版 · iPhone 8
Home 键
数亿用户已习惯
新版 · iPhone X
全面屏手势
屏幕更大 · 沉浸更强
改变巨大,但好处远大于学习成本 → 值得
✗ 反面示例
🔄 为改变而改变的"季度改版"
用户每次登录都要重新找功能:
Q1 改版:菜单在顶部导航栏
Q2 改版:菜单移到左侧边栏
Q3 改版:菜单改成底部Tab栏
Q4 改版:又改成汉堡菜单
📉 每次改版无明确目标 · 老用户流失率 ↑ 15%
3.9
不论你的界面多酷,越少越好
3.9
不论你的界面多酷,越少越好
No Matter How Cool, Less Is Always Better — 极简不是风格选择,而是可用性要求
每一个额外的元素——按钮、文字、图标、动画、装饰线——都在与真正重要的内容争夺用户的注意力。"少"不是简陋,而是精准——移除任何对用户达成目标不必要的元素。如果必须在"酷炫"和"清晰"之间选择,永远选清晰。这不是说界面不能美——能美且简洁当然最好——但不能以牺牲可用性为代价。
✓ 正向例子
WhatsApp 的聊天界面:除了对话内容和输入框外几乎没有其他 UI 元素。没有花哨的气泡动画、没有装饰性图标、没有多余的按钮。全世界 20 亿用户——不同文化、不同年龄段、不同技术水平——都能在几秒内理解并使用。这就是"少"的极致力量。
✗ 反向例子
某企业官网首页使用了全屏视频背景、粒子动画、滚动视差效果、3D 旋转卡片。视觉效果令人惊叹,但用户找不到公司地址和联系电话——这两个最常被访问的信息被一场视觉秀淹没了。访客平均停留时间高达 2 分钟,但 95% 的人没有找到他们想要的信息就离开了。
交互演示 — 点击展开查看正反对比
✓ 正面示范
💬 极简聊天 — 只有必要元素
在吗?
在的!
明天几点见面?
0个装饰图标 · 0条分割线 · 0个多余按钮 · 20亿用户即开即用
✗ 反面示例
🎪 过度设计 — 找不到关键信息
95% 访客没找到目标信息就离开了
3.10
避免不必要的报告
3.10
避免不必要的报告
Avoid Unnecessary Reporting — 软件不要对用户喋喋不休地汇报它正在干什么
这是 Cooper 关于构建"体贴的软件"(Considerate Software)的核心原则。它的本质是抨击一种根深蒂固的"程序员思维":系统总是喜欢不分巨细地向用户汇报工作进度和内部状态——就像每隔 10 分钟跑进来说"老板,信已经装进信封了""老板,信已经贴好邮票了"的啰嗦助理。用户不关心这些。用户只想把信交给顶级助理,然后继续做自己的正事——软件应该做那个顶级助理。
为什么软件总是喜欢"过度报告"?
① 程序员的"日志思维":开发阶段工程师需要系统不断输出运行状态来排查 Bug。不幸的是,很多设计直接把这种"内部日志"变成了提示框展示给用户。
② 错把"成功"当成"新闻":用户点击"保存",系统弹出大大的对话框【保存成功![确定]】。但保存本来就是系统该做的事——根本不值得打断用户,还逼用户多点一次"确定"来给你鼓掌。
四条具体的执行策略
1. 奉行"没有消息就是好消息"(No News is Good News)
❌ 用户修改资料后弹窗"修改已成功提交!"必须点 OK。
✅ 按钮短暂变 ✓,顶部 Toast 3 秒自动消失"资料已更新"。不打断心流。
❌ 用户修改资料后弹窗"修改已成功提交!"必须点 OK。
✅ 按钮短暂变 ✓,顶部 Toast 3 秒自动消失"资料已更新"。不打断心流。
2. 展示状态,而不是"报告"状态(Show, Don't Tell)
❌ 系统弹出气泡"当前网络连接良好"。
✅ 像 Wi-Fi 信号图标一样,做成安静的视觉指示器——瞥一眼就知道,不需要时绝不跳出来抢注意力。
❌ 系统弹出气泡"当前网络连接良好"。
✅ 像 Wi-Fi 信号图标一样,做成安静的视觉指示器——瞥一眼就知道,不需要时绝不跳出来抢注意力。
3. 隐藏软件的内部机制和技术细节
❌ 启动时显示"正在初始化数据库…正在加载配置文件…正在建立网络握手…"
✅ 用一个优雅的骨架屏或启动动画代替。用户只关心"我什么时候能开始用"。
❌ 启动时显示"正在初始化数据库…正在加载配置文件…正在建立网络握手…"
✅ 用一个优雅的骨架屏或启动动画代替。用户只关心"我什么时候能开始用"。
4. 只报告"可操作的异常"(Actionable Exceptions)
❌ "错误代码 0x80040111:无法连接服务器。"
✅ "网络已断开,您的文档已自动保存在本地。你可以 [检查网络设置] 或 [继续离线编辑]。"——报告的重点不是"我出错了",而是"你需要做什么"。
❌ "错误代码 0x80040111:无法连接服务器。"
✅ "网络已断开,您的文档已自动保存在本地。你可以 [检查网络设置] 或 [继续离线编辑]。"——报告的重点不是"我出错了",而是"你需要做什么"。
✓ 正向例子
手机顶部的状态栏就是"避免不必要报告"的典范:Wi-Fi 信号、电量、时间——全都是以安静图标形式存在的"状态指示器"。用户需要时一瞥即知,不需要时它们绝不出声。没有一个手机会每隔 10 分钟弹窗说"电池还剩 72%!点击确定继续"。
✗ 反向例子
某杀毒软件的行为:开机弹出"已保护您的电脑 1 天",查毒后弹出"扫描完成!发现 0 个威胁",更新病毒库后弹出"病毒库已更新至最新版本"。用户每次操作都被迫停下来点"确定"——这个软件不是在服务用户,而是在不断刷存在感。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🤫 顶级助理 — 安静做事,不刷存在感
Wi-Fi ▂▂▂
🔋 72%
09:41
📝 个人资料
✓ 资料已更新
2秒后自动消失
无弹窗 · 无"保存成功" · 无"点击确定" · 无事发生就是最好的事
✗ 反面示例
📢 啰嗦助理 — 每做一件事都要汇报
用户打开了一个普通网页,然后——
🔔 开机提示
已保护您的电脑 1 天![确定]
已保护您的电脑 1 天![确定]
🔔 扫描完成
发现 0 个威胁![确定]
发现 0 个威胁![确定]
🔔 病毒库更新
已更新至最新版本![确定]
已更新至最新版本![确定]
🔔 网络状态
当前网络连接良好![确定]
当前网络连接良好![确定]
🔔 内存优化
已释放 128MB 内存![确定]
已释放 128MB 内存![确定]
软件不是在服务用户,而是在"刷存在感"——每次正常的、预期内的操作都要邀功请赏
总结:"避免不必要的报告"与#16"提供普遍撤销"和#40"请求原谅而非许可"一脉相承。它们都在强调同一个理念:把用户当成有正事要做的聪明人。优秀的交互设计就像空气——它默默支撑着用户达成目标,而不是像一个喋喋不休的机器,总是渴望得到用户的关注和确认。在设计时,砍掉所有只为了说"我干得不错"的提示框。
3.11
请求原谅,而不是许可
3.11
请求原谅,而不是许可
Ask Forgiveness, Not Permission — 让操作直接生效并提供撤销,而非用确认弹窗阻碍用户
在交互设计中,每次弹出"你确定吗?"都是在向用户"请求许可"——打断他们的心流、增加认知负荷、把用户从行动者变成了审批者。更好的方式是:让操作立刻生效,同时给出清晰可见的"撤销"按钮。用户不需要在每次操作前踌躇犹豫,因为他们知道——即使做了错误决定,也可以"请求原谅"(撤销回来)。这与 #16"提供普遍撤销"一脉相承:好的设计不给用户设置"关卡",而是给用户提供"安全网"。
✓ 正向例子
Gmail 的删除操作:点击删除 → 邮件立即从列表中滑出消失 → 底部浮现"已删除"提示,旁边附带一个「撤销」链接。整个流程没有任何模态弹窗来"请求许可"——操作即刻完成。如果用户删错了,点击"撤销"即可"请求原谅"——邮件完好无损地回到原位。
✗ 反向例子
某系统几乎每个操作都弹确认框:"确认删除?""确认退出?""确认提交?""确认取消?"用户每天看到几十次同样的弹窗,被训练成机械点击"确定"——确认框完全失去了保护作用。真正的误操作发生时,用户已经条件反射地点了"确定",而该系统恰恰没有提供撤销功能。
⚠ 重要的例外情况 — 必须"请求许可"的三个场景
① 真正的不可逆操作:一旦发生,技术上绝对无法恢复。例如:彻底清空回收站、格式化硬盘、drop database。这类操作必须有确认屏障,因为撤销在物理上不可能。
② 涉及现实世界重大损失的操作:后果远超出软件本身。例如:银行转账 500 万、发射火箭、给全公司 1 万人发送全员邮件。做一个 Snackbar"转账已发出,点击撤销"在这里是不够的——钱已经离开账户了。
③ 极高风险的系统级操作:GitHub 删除核心代码仓库时,不仅弹出确认框,还要求用户手动输入一遍项目名称才能确认——这是刻意打破用户的"肌肉记忆",确保这个操作不是在麻木状态下的条件反射。这是确认设计的最高境界:不是"点一下确定",而是"停下来,想一想"。
总结:"请求原谅,而不是许可"体现了现代交互设计对用户的信任与尊重。它告诉设计师:不要做一个唠叨、防备心重的"系统守门员",而要做一个默默在下方铺好安全网、让用户在上面自由飞翔的守护者。
交互演示 — 点击展开查看正反对比
✓ 正面示范
↩️ 操作即生效 + 撤销 = 求原谅而非求许可
📄 重要文档.pdf
📄 报告_v2.pdf
未操作
✅ 已删除"重要文档.pdf"
没有"确认删除?"弹窗 → 直接生效 → 误删了?点"撤销"即可"请求原谅"
✗ 反面示例
🚫 每次操作都"请求许可"——确认弹窗地狱
用户的日常操作流程:
⚠️ 确认删除?
[确定] [取消]
[确定] [取消]
↓ 点击"确定"(条件反射)
⚠️ 确认退出?
[确定] [取消]
[确定] [取消]
↓ 点击"确定"(已经麻木)
⚠️ 确认提交?
[确定] [取消]
[确定] [取消]
每天几十次确认弹窗 → 用户麻木点击"确定" → 确认框形同虚设 → 误操作反而没有撤销!
第四篇
视觉与界面设计
4.1
清晰视觉层次
4.1
清晰视觉层次
Visual Hierarchy — 让用户一眼看到最重要的东西
用户扫描屏幕而非阅读屏幕。通过大小、颜色、对比度、间距、位置的差异来建立清晰的视觉层次。重要的元素要突出,次要的要弱化。如果所有元素都在"喊叫",用户什么都听不到。
✓ 正向例子
Stripe 的支付页面:标题"支付 $29.00"使用最大字号,卡号输入框位于视觉中心,支付按钮有强对比色。辅助信息(如隐私政策链接)使用小号灰色文字,清楚地退到背景中。
✗ 反向例子
某政府网站首页:所有模块同等大小、同等颜色、同等字体。新闻公告、办事入口、领导讲话、友情链接挤在一个页面中。用户的眼球没有落点,每次都要从头扫描才能找到目标。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📐 清晰视觉层次
支付 $29.00
卡号 ████ ████ ████ ████
🔒 您的支付信息已加密 · 隐私政策
✗ 反面示例
📢 所有元素都在"喊叫"
系统公告:今晚维护
欢迎使用XX平台
支付
¥29.00
卡号
有效期
安全码
立即支付
关于我们 | 帮助中心 | 合作联系 | 加入我们
4.2
善用示能性
4.2
善用示能性
Affordances — 控件的外观应暗示其操作方式
按钮应该看起来可以按,滑块应该看起来可以拖,输入框应该看起来可以输入。这是 James Gibson 和 Don Norman 的核心概念。在数字界面中,我们依赖的是"感知示能性"——即用户通过外观能判断出控件能做什么。
✓ 正向例子
iOS 的计算器:圆形按钮有凸起的立体感和阴影,明显暗示"可按"。数字键和功能键用颜色区分——橙色的是操作键、灰色的是功能键、深色的是数字键。用户不假思索就知道该按哪里。
✗ 反向例子
某 App 将一段纯文本样式的句子中的某个词设为可点击链接,但没有任何下划线、颜色区分或视觉提示。用户只有碰巧将手指滑过那里或者误触时,才发现它是可交互的。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🔘 外观暗示操作方式
0
✗ 反面示例
🔗 不可见的交互元素
根据《用户服务协议》第3.2条规定,您在使用本服务时应当遵守相关法律法规,并确保您提供的信息真实有效。如有疑问请联系客服。
没有任何视觉提示这些词可以点击——用户只有碰巧点到了才知道
4.3
渐进披露信息
4.3
渐进披露信息
Progressive Disclosure — 按需展示,不一次性倒出所有信息
初学者需要简洁,高级用户需要强大。渐进式信息披露的设计哲学是:先展示最常用的功能和信息,把高级功能藏在"更多""高级""展开"之后。这不是隐藏功能,而是尊重用户当前的注意力。
✓ 正向例子
Adobe Photoshop 的工具栏:默认只显示每个工具组中最常用的工具(如画笔)。长按或右键点击图标才展开更多变体(铅笔、颜色替换工具、混合器画笔)。初学者不会被 60+ 个工具吓到,高级用户知道去哪里找。
✗ 反向例子
某 App 的新手引导:第一次打开 App,一口气弹出 8 个引导页,每页介绍一个功能。用户还没开始使用就被灌输了所有信息。等真正需要用到第 5 个功能时(可能是一周后),早忘了当时的引导内容。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📂 渐进披露信息
🎨 基础设置
颜色模式、字体大小、语言
⚙️ 高级设置
快捷键自定义、API密钥、网络代理
🔬 开发者选项
调试模式、性能追踪、实验性功能
常用功能前置,高级功能折叠 → 初学者不被吓到,专家能找到需要的
✗ 反面示例
🌊 一次性倾倒所有信息
●○○○○○○○
一口气灌输8页引导,等真正用到第5页的功能(一周后)早忘光了
4.4
视觉设计原则
4.4
视觉设计原则
Visual Interface Design — 视觉不只是"好看",更是沟通工具
Cooper 团队总结了视觉界面设计的关键原则:使用网格系统建立秩序感;对齐创建视觉连接;用对比传达重要程度;用留白建立内容区块的呼吸感;色彩应传达意义而非仅为装饰。好的视觉设计让界面的信息结构和操作逻辑一目了然。
✓ 正向例子
Apple 官网产品页:极致的留白、精确的网格对齐、克制的色彩(黑白灰为主,产品图是唯一的视觉焦点)、清晰的文字层级(产品名最大,价格次之,技术规格最小)。用户的眼睛被精准引导,不需思考就知道该看哪里。
✗ 反向例子
某企业后台管理系统:10 种以上颜色混用(红色警告、绿色成功、蓝色链接、黄色高亮、橙色标签……),模块对齐混乱(有的居中对齐、有的左对齐、有的距左边距不一致),字体大小从 10px 到 28px 随机出现。视觉噪音淹没了信息本身。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📐 精确的网格与对齐
为创造者而生
专业级工具,极致性能
性能
设计
协作
了解更多 →
✗ 反面示例
🎪 混乱的视觉
为创造者而生
专业级工具,极致性能
性能
设计
协作
了解更多 →
4.5
清晰信息架构
4.5
清晰信息架构
Information Architecture — 如果用户找不到,就等于不存在
信息架构是数字产品的骨骼。导航结构、分类体系、标签系统、搜索逻辑——这些决定了用户能否高效地找到他们想要的东西。好的信息架构反映了用户的心智模型(他们如何分类和命名事物),而非公司内部的组织结构图。
✓ 正向例子
Amazon 的导航:按照用户购物心智分类——"电子产品""服装""家居厨房""图书"——而非按照供应商或内部采购部门分类。面包屑导航清晰显示当前位置,筛选器动态更新可选范围,用户始终知道"我在哪里"和"如何回去"。
✗ 反向例子
某大学官网:导航结构完全映射学校内部行政架构——"校长办公室""教务处""学生工作部""后勤保障部""发展规划处"。学生想查一个补考时间,需要先理解"补考属于教务处管辖,但如果是体育课则在体育部网站"。信息架构暴露了内部组织,而非服务用户。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🗂️ 按用户心智导航
📱 电子产品
👗 服装鞋包
🏠 家居厨房
📚 图书音像
按用户购物心智分类,面包屑导航清晰显示"我在哪里"和"如何回去"
✗ 反面示例
🏛️ 按组织架构导航
🏫 校长办公室
📋 教务处 → 考试管理 → 补考安排
👥 学生工作部
🏗️ 后勤保障部
📊 发展规划处
4.6
精心编排体验
4.6
精心编排体验
Orchestration — 好的交互像音乐,有节奏、有引导、有高潮
界面不仅是静态的布局,更是动态的体验流。像指挥家编排交响乐一样编排用户的体验流程:什么时候该引导、什么时候该放手、什么时候该庆祝。动作和过渡不是装饰,它们是理解系统状态变化的关键线索。
✓ 正向例子
Apple Watch 的"健身圆环闭环":一天的站立、运动、锻炼目标用三个彩色圆环表示。随着你一天的活动,圆环逐渐填满。闭环的瞬间有一个精心设计的动画和触觉反馈——这一刻是刻意编排的高潮体验,让用户每天都有动力完成目标。
✗ 反向例子
某任务管理 App 完成任务后没有任何视觉回馈——勾选框打勾后,任务变成灰色并沉到底部。没有动画、没有鼓励、没有进展感。用户完成 10 个任务和完成 0 个任务在视觉体验上几乎没有差别。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🎯 有编排的体验
今日目标
已达成 72%
已达成 72%
进度圆环逐渐填满 → 闭环瞬间有庆祝动画 → 每天都有动力完成
✗ 反面示例
📋 无编排的完成
✅ 任务1
✅ 任务2
✅ 任务3
☐ 任务4
☐ 任务5
完成任务后无动画、无鼓励、无进展感。完成10个和0个在视觉上几乎一样
4.7
用户体验只有一个——形式和行为的设计必须相互和谐
4.7
用户体验只有一个——形式和行为的设计必须相互和谐
One UX — Visual Form and Behavioral Design Must Be in Harmony — 视觉与交互是不可分割的整体
一个产品只有一个用户体验。当视觉形式(看起来如何)和行为设计(用起来如何)不一致时,用户会感到困惑和不安。一个看起来现代但交互笨拙的界面,不比一個看似普通的界面更好——也许更糟,因为视觉提高了期望但交互没能兑现。形式与行为的协调是体验设计的核心命题。
✓ 正向例子
Apple AirPods——视觉形式(简洁优雅的充电盒、无按钮的耳机本体)和行为设计(打开盒盖自动连接、取出即用、放回即充电)完美融合。看起来就应该这样用,用起来也正印证了视觉传达的感觉。形式和生活在说同一个故事。
✗ 反向例子
某智能家居 App 的视觉设计非常前卫——渐变、动效、精致的微交互——但加载一个灯光控制需要 5 秒,而且开关状态经常与实际不同步。华丽的视觉提高了用户对体验的期待,但糟糕的技术实现让这种期待变成了加倍的失望和挫败感。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🎧 形式与行为完美和谐
🎧
AirPods Pro
已连接 ✓
📦 打开盒盖 → 自动连接 ✓
👂 取出耳机 → 自动切换 ✓
🔋 放回充电盒 → 自动充电 ✓
视觉说"简洁优雅",交互说"无缝自然"——同一个故事
✗ 反面示例
💔 华丽的视觉,破碎的交互
🏠 智能家居 App
精美渐变 · 流畅动效 · 精致微交互
💡 客厅灯
⚠ 状态不同步(App显示"开"但灯实际已关)
⏱ 操作延迟5秒(加载动画一直在转)
视觉提高了期望 → 交互没能兑现 → 加倍失望
第五篇
设计系统与规范
5.1
确保一致性
5.1
确保一致性
Consistency — 同样的概念,同样的表达
一致性不只是视觉统一,更是行为和概念的一致。同样的操作在同一 App 的不同位置应该用同样的方式完成。内部一致性(App 内部一致)和外部一致性(遵循平台惯例)都很重要。不一致迫使用户每次都要重新学习。
✓ 正向例子
macOS 系统级的一致性:几乎所有 App 的"偏好设置"都在菜单栏最左侧 App 名称下的"偏好设置…"中,快捷键统一为 ⌘,。用户学会一次,终生受用。删除键、复制粘贴、窗口关闭行为在系统层面高度一致。
✗ 反向例子
某大型 SaaS 产品中,"删除"操作在不同的模块中有 3 种表现——在 A 模块是红色按钮直接删除,在 B 模块是先勾选再点"批量操作→删除",在 C 模块是左滑出现删除选项。用户在每个模块都要重新学习"删除"怎么做。
交互演示 — 点击展开查看正反对比
✓ 正面示范
✅ 一致的删除操作
文件A.pdf
文件B.pdf
文件C.pdf
三个模块中,删除的图标、位置、行为完全一致 → 学会一次,终身受用
✗ 反面示例
🚫 不一致的删除操作
模块A
模块B ← 左滑删除
模块C 勾选后批量删除
同一个"删除"有三种表现,用户在每个模块都要重新学习如何删除
5.2
谨慎使用隐喻
5.2
谨慎使用隐喻
Metaphors — 隐喻是拐杖,不是目标
视觉隐喻(如把删除图标做成垃圾桶)能帮助新手快速理解,但过度依赖物理世界的隐喻会限制数字世界的可能性。当隐喻不再有帮助时,果断放弃它。好的设计从隐喻入门,但最终超越隐喻。
✓ 正向例子
早期 iBooks 的书架隐喻——在木纹书架上展示书封——帮助用户理解"这是一个书库"。但随着用户习惯养成,Apple Books 逐渐去掉了书架纹理,改用更高效的列表和网格视图,不再束缚于物理隐喻。
✗ 反向例子
某笔记 App 坚持"完全模拟纸质笔记本"——翻页动画耗时 1.5 秒、必须按"封面"才能进入、不支持搜索。为了忠于隐喻而牺牲了数字媒介的核心优势(搜索、链接、无限空间),本末倒置。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📱 超越隐喻的界面
✗ 反面示例
📕 过度依赖物理隐喻
5.3
匹配姿态设计
5.3
匹配姿态设计
Posture — 不同使用场景需要不同的设计姿态
Cooper 将应用分为三种姿态:独占型(Sovereign)——用户长时间沉浸使用(如 IDE、设计工具);短暂型(Transient)——用户快速进出(如计算器、天气);后台型(Daemonic)——不需要用户直接交互(如杀毒软件、同步服务)。每种姿态对应的界面密度、信息架构、交互模式完全不同。
✓ 正向例子
VS Code(独占姿态):全屏工作区、多标签页、侧边栏、命令面板、丰富的快捷键。用户每天在其中花费数小时,所以界面可以更复杂、学习曲线可以更陡——只要长期效率够高。而天气 App(短暂姿态):一瞥即知,单屏展示核心信息,无需复杂导航。
✗ 反向例子
某电梯调度面板上的设置界面(短暂姿态场景)被设计成需要多层菜单导航,像操作一台服务器一样复杂。用户只想从 1 楼到 15 楼,却在触摸屏上翻了三层菜单才找到楼层选择。短暂姿态的产品不能有独占型的学习成本。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🌤️ 短暂型 vs 💻 独占型 姿态对比
短暂型
☀️ 28°
晴 上海
晴 上海
一瞥即知,
无导航
无导航
独占型
代码区
终端
全屏沉浸,
丰富快捷键
丰富快捷键
✗ 反面示例
🏢 电梯面板(短暂场景)做成独占型
用户只想从1楼到15楼,却在触摸屏上翻了三层菜单——短暂姿态的产品不能有独占型的学习成本
5.4
适配输入方式
5.4
适配输入方式
Input Modalities — 每种输入方式有不同的设计约束
鼠标精确但慢(适合精确点击和右键菜单),手指快但不精确(适合大触摸目标和手势),键盘最快但需要记忆(适合快捷键和命令行),语音解放双手但不适合隐私场景。好的设计为当前输入方式优化,移除非该输入方式下的交互假设(如移动端没有 hover 状态)。
✓ 正向例子
iOS 的"滑动返回"手势:从屏幕左边缘向右滑动即可返回上一页。这个手势完美利用了触摸屏的特点(模糊、快捷),让拇指在自然握持姿势下就能完成最频繁的导航操作,无需点击左上角的返回按钮。
✗ 反向例子
某响应式网站将桌面端的 hover 下拉菜单原封不动搬到移动端。用户手指点一下菜单项,菜单闪现后立即跟随链接跳转——因为 touch 事件同时触发了 hover(展开子菜单)和 click(跳转链接)。没有为触摸输入方式重新设计交互。
交互演示 — 点击展开查看正反对比
✓ 正面示范
👆 触摸优先设计
📷
夏日风景
摄于2026年6月 · 3张
大触摸目标(44px+)、充足的间距、无hover依赖
✗ 反面示例
🖱️ 桌面端交互搬到移动端
hover菜单直接搬到触摸屏——手指点一下,菜单闪现后直接跳转,因为touch同时触发了hover+click
5.5
尊重平台惯例
5.5
尊重平台惯例
Platform Conventions — 不要重新发明用户已经学会的东西
每个平台(iOS、Android、Windows、macOS、Web)都有一套用户已经内化的交互惯例。打破这些惯例会制造困惑。除非你有极强的理由证明你的方案比平台标准好得多,否则请遵循平台惯例。
✓ 正向例子
Apple 的 Human Interface Guidelines 和 Google 的 Material Design 都规定了标准控件的外观和行为。遵循这些规范的 App(如 Things 3 在 iOS 上、Gmail 在 Android 上)让用户上手即用,因为下拉刷新、左滑删除、长按多选等手势都是平台层面的"语言"。
✗ 反向例子
某 Android App 的设计师是 iOS 忠实用户,强制在 Android 端使用 iOS 风格的底部 Tab 栏图标、iOS 风格的返回箭头、iOS 风格的日期选择器滚轮。Android 用户困惑于"为什么这个 App 处处跟系统不一样"。
交互演示 — 点击展开查看正反对比
✓ 正面示范
📱 遵循平台规范
通知设置›
隐私›
关于›
使用系统原生风格的控件、导航、手势 → 用户上手即用
✗ 反面示例
🔄 跨平台风格混乱
🍎 iOS风格滚轮
🤖 Android MD按钮
🌐 Web风格下拉
Android App上混用iOS风格的控件 → 用户困惑"为什么这个App处处跟系统不一样"
5.6
善用设计模式
5.6
善用设计模式
Design Patterns — 不要重新发明轮子,用已被验证的解决方案
交互设计中有大量被反复验证有效的设计模式:向导式表单、分面搜索、拖拽上传、无限滚动、骨架屏……使用这些模式可以降低用户的学习成本(他们已在其他地方学会),也可降低设计的出错概率(这些模式已被打磨多年)。
✓ 正向例子
几乎所有电商 App 都使用"卡片 + 网格 + 筛选栏"的商品列表模式,以及"购物车图标在右上角"的模式。用户在淘宝学会的浏览和购买方式,可以直接迁移到京东、拼多多——这就是设计模式的力量。
✗ 反向例子
某创新电商 App 将购物车设计为"左滑商品加入口袋,右滑查看口袋"——自创了一套完全不同于任何主流电商的交互模式。用户需要阅读 3 页引导才能开始购物,转化率极低,因为没人愿意在购物前先"学习"一个新系统。
交互演示 — 点击展开查看正反对比
✓ 正面示范
🛒 标准电商设计模式
🖼️
商品名称
¥99.00
🖼️
商品名称
¥129.00
卡片+网格+购物车图标在右上角 → 用户在淘宝学会的模式可迁移到任何电商
✗ 反面示例
🎪 自创交互模式
📖 操作指南(3页):
1️⃣ 左滑商品 → 加入"口袋"
2️⃣ 右滑商品 → 查看"口袋"
3️⃣ 上滑"口袋" → 去结算
商品A ← → 商品B ← → 商品C
自创了一套完全不同于主流电商的交互 → 需要阅读3页引导,转化率极低
"设计师的目标不是创造让人惊叹的界面,而是创造让用户感觉不到其存在的界面——当技术消失,目标显现,这才是真正的设计成功。"
—— Alan Cooper,《About Face》作者,"Visual Basic 之父"