Alan Cooper · Robert Reimann · David Cronin · Christopher Noessel

《About Face 4》
交互设计精髓

目标导向设计的经典之作。30 个核心观点按五大类重新编排——从方法论到认知心理学，从交互原则到视觉设计，再到系统规范，形成一条完整的知识脉络。

—— 交互设计领域公认的"圣经"，四个版本持续影响全球设计师

第一篇

设计思维与方法论

目标导向设计

Goal-Directed Design — 从用户目标出发，而非从技术功能出发

不要问"这个功能怎么做"，要先问"用户想达成什么目标"。目标是稳定的，而任务和技术手段是多变的。设计的重点是理解用户真正的目标，然后倒推设计解决方案，而非在现有技术框架内填功能。

✓ 正向例子

iPhone 早期的闹钟应用：用户目标是"按时起床"，设计师没有堆砌复杂的排班、循环规则、标签分类系统，而是用一个滚轮让用户在 3 秒内设好闹钟。滑动即设置，无需确认按钮。

✗ 反向例子

某企业考勤系统：员工目标是"快速打卡"。但系统要求先选择"考勤类型"（上班/下班/加班开始/加班结束/外出/归来），再确认定位，再输入备注，最后输入密码。为打卡这一简单目标堆砌了 5 步操作。

用户研究为先

Research Before Design — 没有用户研究的设计只是猜测

不要假设你了解用户。通过民族志观察、情境访谈、用户日记等方法去理解用户真实的行为、动机和环境。利益相关者说什么不等于用户做什么，用户自己说的也不等于他们实际做的。

✓ 正向例子

Cooper 团队在为一款医疗影像系统做设计前，花数周时间在医院放射科实地观察医生的工作流程——发现医生在诊断时需要在 3 个不同系统间反复切换，这是任何访谈中医生都不会主动提及的痛点。

✗ 反向例子

一个创业团队想当然地认为"老年人需要超大字体的手机"，未经调研就推出了字体大到每屏只能显示 3 行的手机。实际研究发现，老年人更关心的是防诈骗、一键联系家人，而非单纯的字体放大。

建立人物模型

Personas — 用具体的人物画像替代模糊的"用户"概念

"用户想要……"是最危险的句式之一。真实用户千差万别。人物模型（Persona）是将用户研究数据合成为具体、可信的人物原型——有名字、照片、目标、痛点、行为模式。每个设计决策都要能回答"这对我们的首要人物模型有什么好处？"

✓ 正向例子

某银行 App 设计团队定义了"小琳——28 岁的职场新人，对理财焦虑但渴望学习，通勤时间 45 分钟，习惯在地铁上用左手单手操作手机"。这个具体画像指导了单手操作优化和理财教育内容的信息架构。

✗ 反向例子

产品需求文档里写"我们的用户是所有 18-55 岁的智能手机用户"。这个模糊定义无法指导任何具体设计决策——18 岁大学生和 55 岁退休人员的需求、行为、环境完全不同。

基于场景设计

Scenario-Based Design — 用叙事定义理想体验

不要从界面控件开始设计，先从"理想用户体验故事"开始。写一段叙述，描述人物模型在理想世界中如何达成目标。这个叙事会揭示出真正的功能需求和交互细节，而不是让你在功能清单上勾选。

✓ 正向例子

设计打车 App 时先写出场景："小雨走出公司大门，打开 App，地图已自动定位。她看到附近有几辆车，预估 3 分钟到达。她点击'回家'快捷按钮，系统自动匹配。她不需要输入任何地址。"从场景倒推出自动定位、常用地址、预估时间等核心功能。

✗ 反向例子

产品经理直接给出一份功能清单——"要有地图选点、地址搜索、历史记录、收藏地址、路线预览……"工程师按清单实现后，用户发现叫车需要 7 个步骤，因为设计者从未从使用场景出发串联这些功能。

可用性贯穿全程

Usability Testing — 设计过程全程验证，而非最后才测试

不要等到开发完成才做可用性测试。从纸面原型开始就要测试——越早发现问题，修复成本越低。可用性测试不是证明设计正确，而是发现设计的问题。5 个用户就足以发现 85% 的可用性问题。重要的是观察用户做什么，而非听他们说什么。

✓ 正向例子

IDEO 和 Cooper 的工作方式：在设计早期阶段使用纸质原型或低保真可点击原型进行"快速迭代测试"——找 5 个目标用户，观察他们完成任务的过程，记录他们在哪里卡住，当天修改原型，第二天再测。3 轮迭代通常能发现并解决绝大多数关键问题。

✗ 反向例子

某团队在产品上线前一周才请用户来测试。测试中发现了核心导航结构的问题——用户找不到主要功能入口。但此时修改需要重构前端路由和数据库关联，团队最终以"来不及改了"为由上线了一个用户找不到功能的产品。

第二篇

用户认知与心理学

贴近心智模型

Implementation Model vs Mental Model — 让界面贴近用户心智，而非暴露系统内部结构

实现模型是软件内部如何运作（数据库表、API 调用链、类继承关系）。心智模型是用户脑中如何理解事物运作。好的设计让"表现模型"尽可能贴近用户的心智模型，而不是暴露实现细节。

✓ 正向例子

Mac 的"废纸篓"：用户的心智模型是"文件扔进垃圾桶即可丢弃"，不需要理解 inode、block、文件系统引用计数。拖入即删除，清空即释放空间——完全匹配物理世界心智。

✗ 反向例子

某企业内部系统的消息通知设置：用户看到"Webhook 回调地址""消息队列优先级""重试策略：指数退避"等选项。这是把后端实现模型直接暴露给非技术用户，造成了巨大的认知负担。

识别优于回忆

Recognition over Recall — 让用户"认出来"而非"想出来"

人类识别能力远强于回忆能力。你能从 100 张面孔中认出朋友，却很难凭记忆画出朋友的精确五官。界面应该让用户看到选项后"认出来"，而不是强迫用户记住并"想出来"。下拉菜单优于空白的命令行。

✓ 正向例子

淘宝搜索框的下拉建议：你输入"蓝"，下拉列表显示"蓝牙耳机""蓝衬衫""蓝牙音箱"等历史搜索和相关推荐。你不需要回忆起完整的关键词，看到了就能认出来并点击。

✗ 反向例子

某命令行工具要求用户输入完整的 ISO 国家代码（如"CN""US""JP"）才能继续。没有下拉菜单，没有模糊搜索，没有列表参考。用户必须准确回忆出代码字符串，否则程序就报错退出。

满意即可原则

Satisficing — 用户不会追求最优解，找到"足够好的"就会停

Herbert Simon 提出的"满意即可"（Satisficing = Satisfy + Suffice）概念：真实用户不会穷尽所有选项找最优解——他们在找到第一个可接受的方案时就停止了。设计应帮助用户快速找到"足够好的"方案，而非迫使他们比较一切。

✓ 正向例子

大众点评的"附近美食"：你不会一家家比较全城 5000 家餐馆。你会看排名前 10、评分 4.5 以上的，选第一家看起来不错的。平台用排序、评分、距离帮你快速"满意即可"，而非让你做穷举决策。

✗ 反向例子

某 B2B 采购平台将全部供应商以无排序的表格列出（3000+ 行），要求用户自行比较所有参数后选择。没有推荐、没有筛选、没有排序。将"满意即可"的消费决策强行变成了"穷尽比较"的分析任务。

保护用户心流

Flow State — 让用户沉浸在任务中，不被系统打断

Mihaly Csikszentmihalyi 的心流理论：当人沉浸在某事中时，效率和满足感都达到峰值。软件应该保护和促进用户的心流——消除不必要的打断、自动保存进度、预加载内容。每弹出一次"确认吗？""有新版本！"都是对心流的破坏。

✓ 正向例子

Notion 的编辑体验：你输入时页面自动保存（无保存按钮），侧边栏可以随时收起以扩大编辑空间，Markdown 快捷输入让你手不离键盘。没有自动弹窗，没有"确认离开？"——一切都默默地保护你的写作心流。

✗ 反向例子

某写作软件在用户打字时每隔 20 分钟弹出"有新版本可用，是否立即更新？"的模态对话框，还附带"稍后提醒""跳过此版本""了解更多"三个选项。用户刚进入写作状态就被打断，被迫做出一个不相关的技术决策。

希克定律

Hick's Law — 选择越多，决策越慢

用户面对 N 个选项时，决策时间与 log₂(N+1) 成正比。这不是说只能有 2 个选项，而是说不要把所有可能性同时摊在用户面前。用分类、搜索、推荐来减少每个时刻的选择数量。

✓ 正向例子

Airbnb 的搜索流程：先选目的地（减少范围）→ 再选日期（再减少）→ 再选人数（再减少）。每一步只呈现与该步骤相关的选择。最终搜索结果页面用地图、价格滑块、设施筛选进一步缩小范围，绝不会一次展示几万条房源。

✗ 反向例子

某企业软件的设置页面将所有 200+ 配置项平铺在一个超长页面中，没有分组、没有搜索、没有分类标签。用户为一个简单设置需要滚动查找数分钟。

菲茨定律

Fitts' Law — 目标越大越近，点击越快

点击一个目标所需的时间，与目标大小成反比，与距离成正比。重要、常用的按钮应该更大，放置在更容易到达的位置。屏幕边缘（macOS 菜单栏在顶部边缘）具有"无限高度"——鼠标撞到屏幕边界就停住了，实际上增大了可点击区域。

✓ 正向例子

macOS 将菜单栏放在屏幕顶部边缘——鼠标向上甩到顶自动停住，使菜单项拥有"无限高度"的可点击区域。Windows 的右键菜单在光标旁边弹出，最小化了移动距离。两者都是菲茨定律的经典应用。

✗ 反向例子

某网页播放器将"播放/暂停"按钮设计为 12×12 像素的小圆点，放在页面角落，距离用户通常的光标位置很远。而这个按钮是视频页面使用频率最高的控件。小尺寸 + 远距离 = 最差的可点击效率。

第三篇

核心交互原则

遵循设计原则

Design Principles — 原则是设计的"宪法"，不是建议

Cooper 提出了一组交互设计原则作为设计的"宪法"，包括：用户界面应该基于用户的心智模型、少就是多、让用户直接操纵、每个操作都要有反馈、让用户感觉掌控一切。这些原则不是"最好遵守"，而是设计的底层逻辑。

✓ 正向例子

Google 搜索首页——一个输入框、两个按钮。二十多年来，在无数的功能压力下，首页始终保持极简。因为设计师恪守"用户目标是搜索，不要任何干扰"这一原则。

✗ 反向例子

很多企业门户首页塞满了新闻公告、轮播图、快捷入口、待办事项、天气、股票、生日提醒……用户真正要的"找到并进入目标系统"这个核心任务被淹没在信息噪音中。

避免模态打断

Modeless Design — 不要让对话框打断用户的流程

模态（Modal）状态是指用户被困在一个"模式"中，必须先处理当前对话框才能回到主流程。虽然某些场景下模态是必要的（如确认支付），但绝大多数模态对话框都可以被非模态方案替代——它们打断用户心流，增加认知负荷，是"懒惰的设计"。

✓ 正向例子

Google Docs 的"分享"：点击分享按钮，弹出的是一个悬浮面板而非模态对话框。即使面板打开着，你仍然可以滚动文档、编辑文字、查看其他内容。它是一个"呼之即来，挥之即去"的工具，不是一道关卡。

✗ 反向例子

某 Windows 软件：用户想保存文件，弹出模态对话框要求先填写"文档标签""作者""部门""保密级别"四个必填字段。用户只是想保存一下继续工作，却被卡在了这个保存模式中。

直接操纵对象

Direct Manipulation — 让用户直接"触摸"对象而非通过代理操作

直接操纵是人类最自然的交互方式——用手指点、拖、捏。在数字界面中，这意味着用户应该能直接作用于视觉对象（拖拽排序、缩放图片、滑动删除），而不是通过菜单、对话框、属性面板遥控。

✓ 正向例子

iOS 照片编辑：裁剪时直接用双指捏合缩放、拖动调整构图区域。旋转时用双指旋转。用户感觉是"在操作照片本身"，而非操作一组抽象的数字参数。即时预览让每步调整都可见。

✗ 反向例子

某网页端图片编辑器：裁剪需要在侧边栏输入"左: ___px 上: ___px 宽: ___px 高: ___px"四个数值，然后点击"预览"查看效果。切断了直接操纵的闭环，把视觉任务变成了数学题。

即时操作反馈

Immediate & Meaningful Feedback — 每次操作都应有回应

用户每执行一个动作，系统都应给予反馈。按下按钮要有状态变化，提交表单要有结果通知，加载中要有进度指示。无声的界面是最让人不安的——用户会怀疑"到底成功了吗？""要不要再点一次？"

✓ 正向例子

Gmail 删除邮件时：邮件条目立即从列表中滑出消失，底部出现一个 Snackbar 提示"已删除"，并提供"撤销"按钮。用户同时获得了即时视觉反馈和操作结果确认。

✗ 反向例子

某银行的转账页面：用户点击"确认转账"后，页面没有任何变化，按钮也没有禁用或显示加载状态。用户等了 5 秒没反应，再次点击——结果触发了重复转账。没有任何进度反馈或状态变化。

提供普遍撤销

Pervasive Undo — 让用户有"后悔药"可吃

人类会犯错，这是不可改变的事实。好的设计不责备用户，而是给用户一个安全网。每个可能产生后果的操作都应该可以撤销——不是用警告对话框阻止用户，而是让用户放心尝试，知道可以随时回头。

✓ 正向例子

macOS 的"存储为"对话框：你要覆盖一个同名文件时，系统不说"确认要覆盖吗？"，而是显示"替换"或"取消"——更关键的是，Finder 和 Time Machine 让文件级操作几乎处处可撤销。删错了？从废纸篓还原即可。

✗ 反向例子

某表单系统的"删除"按钮：点击即永久删除，无确认、无回收站、无撤销。用户误触后只能联系管理员从数据库恢复。这种设计把系统的技术限制变成了用户的焦虑。

预防优于补救

Error Prevention — 最好的错误消息是没有机会出现的错误消息

与其写一条友好的错误提示，不如把这个错误变成不可能发生的。用约束设计（输入框只接受数字、日期选择器而非文本输入、按钮在条件不满足时禁用）来主动消除出错的可能性。

✓ 正向例子

航班预订的日期选择：去程日期选择器自动将"返程日期"的最小值设为去程日期 + 1 天。用户无论如何操作都无法选择"返程早于去程"的日期组合——这个错误被设计从根本上消灭了。

✗ 反向例子

某注册表单的日期字段允许用户手动输入任意字符串，提交后弹出"您输入的日期格式不正确，请使用 YYYY-MM-DD 格式"的错误提示。设计者本可以用一个日期选择控件从源头消除这个问题。

消除附加工作

Eliminating Excise Tasks — 用户的时间应该花在目标上，而非工具上

附加工作（Excise）是用户为了实现目标而不得不做的、与目标本身无关的操作。比如：在多个窗口间切换、手动输入系统已知道的信息、等待加载时无事可做。好的设计不断追问"能否减少一步？能否预填？能否自动化？"

✓ 正向例子

1Password 浏览器插件：在登录页面检测到用户名和密码字段时，自动填充已保存的凭据。用户不用回忆密码、不用打开密码管理器、不用复制粘贴。填充、登录，一步完成。记住密码、自动填充密码这些附加任务被完全消除。

✗ 反向例子

某报销系统：员工报销一笔差旅费需要（1）手动输入日期（2）选择费用类型（3）输入金额（4）上传发票图片（5）输入发票号码（6）选择成本中心（7）填写事由说明。第 3、5、6 步的信息在发票图片和员工档案中已存在，却要求员工再次手动搬运。

第四篇

视觉与界面设计

清晰视觉层次

Visual Hierarchy — 让用户一眼看到最重要的东西

用户扫描屏幕而非阅读屏幕。通过大小、颜色、对比度、间距、位置的差异来建立清晰的视觉层次。重要的元素要突出，次要的要弱化。如果所有元素都在"喊叫"，用户什么都听不到。

✓ 正向例子

Stripe 的支付页面：标题"支付 $29.00"使用最大字号，卡号输入框位于视觉中心，支付按钮有强对比色。辅助信息（如隐私政策链接）使用小号灰色文字，清楚地退到背景中。

✗ 反向例子

某政府网站首页：所有模块同等大小、同等颜色、同等字体。新闻公告、办事入口、领导讲话、友情链接挤在一个页面中。用户的眼球没有落点，每次都要从头扫描才能找到目标。

善用示能性

Affordances — 控件的外观应暗示其操作方式

按钮应该看起来可以按，滑块应该看起来可以拖，输入框应该看起来可以输入。这是 James Gibson 和 Don Norman 的核心概念。在数字界面中，我们依赖的是"感知示能性"——即用户通过外观能判断出控件能做什么。

✓ 正向例子

iOS 的计算器：圆形按钮有凸起的立体感和阴影，明显暗示"可按"。数字键和功能键用颜色区分——橙色的是操作键、灰色的是功能键、深色的是数字键。用户不假思索就知道该按哪里。

✗ 反向例子

某 App 将一段纯文本样式的句子中的某个词设为可点击链接，但没有任何下划线、颜色区分或视觉提示。用户只有碰巧将手指滑过那里或者误触时，才发现它是可交互的。

渐进披露信息

Progressive Disclosure — 按需展示，不一次性倒出所有信息

初学者需要简洁，高级用户需要强大。渐进式信息披露的设计哲学是：先展示最常用的功能和信息，把高级功能藏在"更多""高级""展开"之后。这不是隐藏功能，而是尊重用户当前的注意力。

✓ 正向例子

Adobe Photoshop 的工具栏：默认只显示每个工具组中最常用的工具（如画笔）。长按或右键点击图标才展开更多变体（铅笔、颜色替换工具、混合器画笔）。初学者不会被 60+ 个工具吓到，高级用户知道去哪里找。

✗ 反向例子

某 App 的新手引导：第一次打开 App，一口气弹出 8 个引导页，每页介绍一个功能。用户还没开始使用就被灌输了所有信息。等真正需要用到第 5 个功能时（可能是一周后），早忘了当时的引导内容。

视觉设计原则

Visual Interface Design — 视觉不只是"好看"，更是沟通工具

Cooper 团队总结了视觉界面设计的关键原则：使用网格系统建立秩序感；对齐创建视觉连接；用对比传达重要程度；用留白建立内容区块的呼吸感；色彩应传达意义而非仅为装饰。好的视觉设计让界面的信息结构和操作逻辑一目了然。

✓ 正向例子

Apple 官网产品页：极致的留白、精确的网格对齐、克制的色彩（黑白灰为主，产品图是唯一的视觉焦点）、清晰的文字层级（产品名最大，价格次之，技术规格最小）。用户的眼睛被精准引导，不需思考就知道该看哪里。

✗ 反向例子

某企业后台管理系统：10 种以上颜色混用（红色警告、绿色成功、蓝色链接、黄色高亮、橙色标签……），模块对齐混乱（有的居中对齐、有的左对齐、有的距左边距不一致），字体大小从 10px 到 28px 随机出现。视觉噪音淹没了信息本身。

清晰信息架构

Information Architecture — 如果用户找不到，就等于不存在

信息架构是数字产品的骨骼。导航结构、分类体系、标签系统、搜索逻辑——这些决定了用户能否高效地找到他们想要的东西。好的信息架构反映了用户的心智模型（他们如何分类和命名事物），而非公司内部的组织结构图。

✓ 正向例子

Amazon 的导航：按照用户购物心智分类——"电子产品""服装""家居厨房""图书"——而非按照供应商或内部采购部门分类。面包屑导航清晰显示当前位置，筛选器动态更新可选范围，用户始终知道"我在哪里"和"如何回去"。

✗ 反向例子

某大学官网：导航结构完全映射学校内部行政架构——"校长办公室""教务处""学生工作部""后勤保障部""发展规划处"。学生想查一个补考时间，需要先理解"补考属于教务处管辖，但如果是体育课则在体育部网站"。信息架构暴露了内部组织，而非服务用户。

精心编排体验

Orchestration — 好的交互像音乐，有节奏、有引导、有高潮

界面不仅是静态的布局，更是动态的体验流。像指挥家编排交响乐一样编排用户的体验流程：什么时候该引导、什么时候该放手、什么时候该庆祝。动作和过渡不是装饰，它们是理解系统状态变化的关键线索。

✓ 正向例子

Apple Watch 的"健身圆环闭环"：一天的站立、运动、锻炼目标用三个彩色圆环表示。随着你一天的活动，圆环逐渐填满。闭环的瞬间有一个精心设计的动画和触觉反馈——这一刻是刻意编排的高潮体验，让用户每天都有动力完成目标。

✗ 反向例子

某任务管理 App 完成任务后没有任何视觉回馈——勾选框打勾后，任务变成灰色并沉到底部。没有动画、没有鼓励、没有进展感。用户完成 10 个任务和完成 0 个任务在视觉体验上几乎没有差别。

第五篇

设计系统与规范

确保一致性

Consistency — 同样的概念，同样的表达

一致性不只是视觉统一，更是行为和概念的一致。同样的操作在同一 App 的不同位置应该用同样的方式完成。内部一致性（App 内部一致）和外部一致性（遵循平台惯例）都很重要。不一致迫使用户每次都要重新学习。

✓ 正向例子

macOS 系统级的一致性：几乎所有 App 的"偏好设置"都在菜单栏最左侧 App 名称下的"偏好设置…"中，快捷键统一为 ⌘,。用户学会一次，终生受用。删除键、复制粘贴、窗口关闭行为在系统层面高度一致。

✗ 反向例子

某大型 SaaS 产品中，"删除"操作在不同的模块中有 3 种表现——在 A 模块是红色按钮直接删除，在 B 模块是先勾选再点"批量操作→删除"，在 C 模块是左滑出现删除选项。用户在每个模块都要重新学习"删除"怎么做。

谨慎使用隐喻

Metaphors — 隐喻是拐杖，不是目标

视觉隐喻（如把删除图标做成垃圾桶）能帮助新手快速理解，但过度依赖物理世界的隐喻会限制数字世界的可能性。当隐喻不再有帮助时，果断放弃它。好的设计从隐喻入门，但最终超越隐喻。

✓ 正向例子

早期 iBooks 的书架隐喻——在木纹书架上展示书封——帮助用户理解"这是一个书库"。但随着用户习惯养成，Apple Books 逐渐去掉了书架纹理，改用更高效的列表和网格视图，不再束缚于物理隐喻。

✗ 反向例子

某笔记 App 坚持"完全模拟纸质笔记本"——翻页动画耗时 1.5 秒、必须按"封面"才能进入、不支持搜索。为了忠于隐喻而牺牲了数字媒介的核心优势（搜索、链接、无限空间），本末倒置。

匹配姿态设计

Posture — 不同使用场景需要不同的设计姿态

Cooper 将应用分为三种姿态：独占型（Sovereign）——用户长时间沉浸使用（如 IDE、设计工具）；短暂型（Transient）——用户快速进出（如计算器、天气）；后台型（Daemonic）——不需要用户直接交互（如杀毒软件、同步服务）。每种姿态对应的界面密度、信息架构、交互模式完全不同。

✓ 正向例子

VS Code（独占姿态）：全屏工作区、多标签页、侧边栏、命令面板、丰富的快捷键。用户每天在其中花费数小时，所以界面可以更复杂、学习曲线可以更陡——只要长期效率够高。而天气 App（短暂姿态）：一瞥即知，单屏展示核心信息，无需复杂导航。

✗ 反向例子

某电梯调度面板上的设置界面（短暂姿态场景）被设计成需要多层菜单导航，像操作一台服务器一样复杂。用户只想从 1 楼到 15 楼，却在触摸屏上翻了三层菜单才找到楼层选择。短暂姿态的产品不能有独占型的学习成本。

适配输入方式

Input Modalities — 每种输入方式有不同的设计约束

鼠标精确但慢（适合精确点击和右键菜单），手指快但不精确（适合大触摸目标和手势），键盘最快但需要记忆（适合快捷键和命令行），语音解放双手但不适合隐私场景。好的设计为当前输入方式优化，移除非该输入方式下的交互假设（如移动端没有 hover 状态）。

✓ 正向例子

iOS 的"滑动返回"手势：从屏幕左边缘向右滑动即可返回上一页。这个手势完美利用了触摸屏的特点（模糊、快捷），让拇指在自然握持姿势下就能完成最频繁的导航操作，无需点击左上角的返回按钮。

✗ 反向例子

某响应式网站将桌面端的 hover 下拉菜单原封不动搬到移动端。用户手指点一下菜单项，菜单闪现后立即跟随链接跳转——因为 touch 事件同时触发了 hover（展开子菜单）和 click（跳转链接）。没有为触摸输入方式重新设计交互。

尊重平台惯例

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 处处跟系统不一样"。

善用设计模式

Design Patterns — 不要重新发明轮子，用已被验证的解决方案

交互设计中有大量被反复验证有效的设计模式：向导式表单、分面搜索、拖拽上传、无限滚动、骨架屏……使用这些模式可以降低用户的学习成本（他们已在其他地方学会），也可降低设计的出错概率（这些模式已被打磨多年）。

✓ 正向例子

几乎所有电商 App 都使用"卡片 + 网格 + 筛选栏"的商品列表模式，以及"购物车图标在右上角"的模式。用户在淘宝学会的浏览和购买方式，可以直接迁移到京东、拼多多——这就是设计模式的力量。

✗ 反向例子

某创新电商 App 将购物车设计为"左滑商品加入口袋，右滑查看口袋"——自创了一套完全不同于任何主流电商的交互模式。用户需要阅读 3 页引导才能开始购物，转化率极低，因为没人愿意在购物前先"学习"一个新系统。

"设计师的目标不是创造让人惊叹的界面，而是创造让用户感觉不到其存在的界面——当技术消失，目标显现，这才是真正的设计成功。"

—— Alan Cooper，《About Face》作者，"Visual Basic 之父"