主题
03 - 交互设计原则（Interaction Design Principles）
"好的设计是显而易见的，伟大的设计是透明的。" —— Joe Sparano
目录
尼尔森十大可用性原则
尼尔森十大可用性原则（Nielsen's 10 Usability Heuristics）由可用性工程专家雅各布·尼尔森（Jakob Nielsen）于 1994 年提出，至今仍然是交互设计领域最重要的指导原则。
┌─────────────────────────────────────────────────────┐
│ 尼尔森十大可用性原则 │
├──────┬──────────────────────────────────────────────┤
│ 01 │ 系统状态可见性 │
│ 02 │ 系统与现实世界的匹配 │
│ 03 │ 用户控制与自由 │
│ 04 │ 一致性和标准化 │
│ 05 │ 错误预防 │
│ 06 │ 识别而非记忆 │
│ 07 │ 使用的灵活性和效率 │
│ 08 │ 美学和简约设计 │
│ 09 │ 帮助用户识别、诊断和恢复错误 │
│ 10 │ 帮助和文档 │
└──────┴──────────────────────────────────────────────┘1. 系统状态可见性（Visibility of System Status）
原则： 系统应始终在合理的时间内，通过适当的反馈，让用户了解当前发生的状态。
通俗理解： 用户做了任何操作，系统都要给出明确的回应——"我收到了""我正在处理""我完成了"。
好的设计： 不好的设计：
点击"发送"后 点击"发送"后
┌────────────────┐ ┌────────────────┐
│ │ │ │
│ 发送中... │ │ (什么都没发生) │
│ ████████░░ 80%│ │ │
│ │ │ 用户：??? │
│ 发送成功 ✓ │ │ 卡了？崩了？ │
│ │ │ 要不要再点一次？│
└────────────────┘ └────────────────┘实际产品案例：
| 产品 | 具体表现 |
|---|---|
| 微信 | 发送消息后显示"已发送"对勾，对方已读显示蓝色勾 |
| 淘宝 | 下单后显示"支付成功"页面和订单编号 |
| 抖音 | 上传视频时显示进度条和百分比 |
| 网页加载 | 浏览器地址栏的加载动画 |
| 文件下载 | 显示下载速度、剩余时间、进度百分比 |
2. 系统与现实世界的匹配（Match Between System and the Real World）
原则： 系统应使用用户熟悉的语言、词汇和概念，而非系统术语。遵循现实世界的惯例，使信息以自然、逻辑的顺序呈现。
通俗理解： 说人话，不要说"机器话"。
好的设计： 不好的设计：
┌────────────────┐ ┌────────────────┐
│ 购物车 (3) │ │ SKU暂存区 (3) │
│ │ │ │
│ 删除这件商品？ │ │ 确认移除该 │
│ │ │ ItemObject？ │
│ [取消] [删除] │ │ │
│ │ │ [Cancel] │
│ │ │ [Confirm │
│ │ │ Deletion] │
└────────────────┘ └────────────────┘实际产品案例：
| 产品 | 具体表现 |
|---|---|
| iOS 计算器 | 界面模拟真实计算器的按键布局 |
| 微信 | 用"朋友圈"而非"动态广场"或"社交Feed" |
| 备忘录 App | 用回收站图标表示删除（模拟真实垃圾桶） |
| 电商 | 用"购物车"图标（模拟真实购物车） |
3. 用户控制与自由（User Control and Freedom）
原则： 用户经常会误操作，需要提供明确的"紧急出口"来退出不想要的状态，而无需经过复杂的流程。支持撤销和重做。
通俗理解： 给用户"后悔药"——撤销、返回、取消。
好的设计：
┌──────────────────────────────────┐
│ 邮件已删除 [撤销] │ <-- 提供撤销操作
└──────────────────────────────────┘
┌────────────────┐
│ ← 返回 │ <-- 随时可以返回上一步
│ │
│ 编辑个人资料 │
│ │
│ [取消] [保存] │ <-- 可以取消编辑
└────────────────┘实际产品案例：
| 产品 | 具体表现 |
|---|---|
| Gmail | 发送邮件后底部出现"撤销发送"提示，有几秒钟的撤回窗口 |
| 微信 | 消息 2 分钟内可撤回 |
| Figma | Ctrl+Z 无限撤销 |
| iOS | 摇一摇撤销输入 |
| 各类 App | 返回按钮、关闭按钮始终可用 |
4. 一致性和标准化（Consistency and Standards）
原则： 用户不应该为同一个操作在不同地方有不同的表述或表现而困惑。遵循平台约定。
通俗理解： 同样的东西，在产品的任何地方都应该看起来一样、用起来一样。
一致性示例：
好的设计（一致）： 不好的设计（不一致）：
所有页面的主按钮: 不同页面的主按钮:
╔══════════╗ ╔══════════╗
║ 确 认 ║ 蓝色/圆角 ║ 确 认 ║ 蓝色/圆角
╚══════════╝ ╚══════════╝
╔══════════╗ ┌──────────┐
║ 提 交 ║ 蓝色/圆角 │ 提 交 │ 绿色/直角
╚══════════╝ └──────────┘
╔══════════╗ ( 保 存 )
║ 保 存 ║ 蓝色/圆角 红色/椭圆
╚══════════╝实际产品案例：
| 产品 | 具体表现 |
|---|---|
| iOS | 全系统统一的返回手势（从左边缘右滑） |
| 微信 | 所有聊天页面的操作方式一致 |
| Ant Design | 企业级设计系统，确保 B 端产品组件统一 |
| Material Design | Google 的统一设计语言 |
5. 错误预防（Error Prevention）
原则： 比起好的错误提示信息，更好的方法是通过精心设计来防止错误发生。消除容易出错的条件，或在用户提交操作前提供确认选项。
通俗理解： 与其告诉用户"你错了"，不如一开始就不让他犯错。
错误预防示例：
1. 删除确认 2. 输入格式提示
┌──────────────────┐ ┌────────────────────┐
│ 确定删除这篇 │ │ 手机号： │
│ 文章吗？ │ │ ┌────────────────┐│
│ │ │ │ 138 1234 5678 ││
│ 删除后无法恢复 │ │ └────────────────┘│
│ │ │ ✓ 格式正确 │
│ [取消] [确认删除]│ │ │
└──────────────────┘ │ 邮箱： │
│ ┌────────────────┐│
3. 禁用不可用按钮 │ │ abc@def ││
┌──────────────────┐ │ └────────────────┘│
│ 请填写所有必填项 │ │ ✗ 请输入完整邮箱 │
│ │ └────────────────────┘
│ 姓名: [已填写] │
│ 手机: [未填写] │
│ │
│ ┌──────────┐ │ <-- 手机未填写时
│ │ 提交(灰) │ │ 按钮不可点击
│ └──────────┘ │
└──────────────────┘实际产品案例：
| 产品 | 具体表现 |
|---|---|
| 电商 | 库存不足时"加入购物车"按钮变灰不可点击 |
| 表单 | 输入手机号自动格式化（138 1234 5678） |
| 日历 | 不可选的日期（过去的日期）显示为灰色 |
| 搜索 | 搜索联想词，减少拼写错误 |
6. 识别而非记忆（Recognition Rather Than Recall）
原则： 通过使对象、操作和选项可见，最小化用户的记忆负担。用户不必记住从一个界面到另一个界面的信息。
通俗理解： 让用户"看到就知道"，不要让用户"想半天才想起来"。
好的设计（识别）： 不好的设计（记忆）：
最近搜索： 请输入搜索关键词：
┌──────┐ ┌──────┐ ┌────────────────┐
│ 连衣裙│ │ 手机 │ │ │
└──────┘ └──────┘ └────────────────┘
┌──────┐ ┌──────┐ (没有任何提示,
│ 耳机 │ │ 书包 │ 用户需要回忆
└──────┘ └──────┘ 自己之前搜过什么)
最近浏览的商品：
┌────┐ ┌────┐ ┌────┐
│img1│ │img2│ │img3│
└────┘ └────┘ └────┘实际产品案例：
| 产品 | 具体表现 |
|---|---|
| 浏览器 | 地址栏显示历史记录和书签建议 |
| 搜索引擎 | 搜索历史和搜索联想 |
| 电商 | "最近浏览""猜你喜欢" |
| 文档工具 | 最近打开的文件列表 |
7. 使用的灵活性和效率（Flexibility and Efficiency of Use）
原则： 提供加速器（快捷方式）让有经验的用户能够加速操作，同时不影响新手用户的使用。
通俗理解： 新手有新手的用法，老手有老手的捷径。
新手模式： 老手模式：
鼠标操作菜单 键盘快捷键
┌─────────────┐ Ctrl+C 复制
│ 编辑 │ Ctrl+V 粘贴
│ ├─ 复制 │ Ctrl+Z 撤销
│ ├─ 粘贴 │ Ctrl+S 保存
│ ├─ 撤销 │
│ └─ 保存 │ 手势操作
└─────────────┘ 左滑删除
下拉刷新
双击点赞实际产品案例：
| 产品 | 具体表现 |
|---|---|
| Figma | 丰富的快捷键系统 |
| 微信 | 双击消息表示"强调"/"拍一拍" |
| 抖音 | 双击屏幕快速点赞 |
| Gmail | 键盘快捷键操作邮件 |
8. 美学和简约设计（Aesthetic and Minimalist Design）
原则： 界面不应包含无关或很少需要的信息。每增加一个信息单元都会降低其他信息的相对可见性。
通俗理解： 少即是多。界面上只放真正需要的东西。
简约设计： 过度设计：
┌────────────────┐ ┌────────────────┐
│ │ │ ★ 热卖 NEW!!! │
│ 商品名称 │ │ 商品名称 │
│ ¥99 │ │ ¥99 原价¥199 │
│ │ │ 已售10000+ │
│ [加入购物车] │ │ ♥ 收藏数 5000 │
│ │ │ 评分 4.8/5.0 │
│ │ │ [加入购物车] │
│ │ │ [立即购买] │
│ │ │ [分享给好友] │
│ │ │ [加入对比] │
└────────────────┘ │ 限时优惠倒计时 │
│ 02:30:15 │
聚焦核心信息 └────────────────┘
用户一目了然 信息过载
用户不知道看哪里实际产品案例：
| 产品 | 具体表现 |
|---|---|
| Apple 官网 | 大量留白，每页聚焦一个卖点 |
| Google 首页 | 极简设计，只有搜索框 |
| 微信 | 功能克制，界面简洁 |
9. 帮助用户识别、诊断和恢复错误（Help Users Recognize, Diagnose, and Recover from Errors）
原则： 错误信息应以通俗易懂的语言表达（不要用错误代码），精确指出问题所在，并建设性地提供解决方案。
通俗理解： 告诉用户哪里错了、为什么错了、怎么改。
好的错误提示： 不好的错误提示：
┌────────────────────┐ ┌────────────────────┐
│ │ │ │
│ 密码输入错误 │ │ Error Code: 401 │
│ │ │ │
│ 密码需要包含： │ │ Authentication │
│ · 至少 8 个字符 │ │ Failed. │
│ · 至少 1 个大写 │ │ │
│ · 至少 1 个数字 │ │ [OK] │
│ │ │ │
│ [重新输入] │ └────────────────────┘
│ │
└────────────────────┘ 用户：这是什么意思？
我该怎么办？
告诉用户具体哪里错了
以及如何修正实际产品案例：
| 产品 | 具体表现 |
|---|---|
| 注册表单 | "该手机号已注册，是否直接登录？" |
| 支付失败 | "余额不足，请更换支付方式或充值" |
| 404 页面 | "页面不存在，为您推荐以下内容..." |
10. 帮助和文档（Help and Documentation）
原则： 即使系统不需要文档就能使用是最好的，但仍需提供帮助和文档。这些信息应该易于搜索，以用户的任务为导向，列出具体步骤，且不应太大。
通俗理解： 最好不需要说明书，但要准备好说明书。
实际产品案例：
| 产品 | 具体表现 |
|---|---|
| 各类 App | 首次使用时的引导页/Coach marks |
| Figma | 内置帮助中心和快捷键提示 |
| 支付宝 | 智能客服+帮助中心 |
| Notion | 丰富的模板库和帮助文档 |
费茨定律（Fitts' Law）
简单解释
费茨定律是人机交互领域最基本的定律之一，由心理学家 Paul Fitts 于 1954 年提出：
移动到目标所需的时间取决于目标的距离和大小。 目标越远、越小，点击所需时间越长；目标越近、越大，点击越容易。
费茨定律示意图：
距离（D）
<─────────────────>
● ┌──┐
手指/鼠标 │目│ 小目标 = 难点击
当前位置 │标│
└──┘
● ┌──────────────┐
手指 │ 大 目 标 │ 大目标 = 易点击
└──────────────┘
公式：T = a + b * log2(D/W + 1)
T = 移动时间
D = 到目标的距离
W = 目标的宽度（大小）
a, b = 常数应用场景
1. 按钮大小设计
手机端按钮最小可触碰区域：
推荐: 44pt x 44pt (iOS) / 48dp x 48dp (Android)
┌────────────────────┐ ┌──┐
│ 提交订单 │ │提│
│ (大按钮好点击) │ │交│ <-- 太小，容易误触
└────────────────────┘ └──┘
推荐 不推荐2. 重要操作的放置位置
手机端拇指热区（右手持机）：
┌─────────────────┐
│ 难触达区域 │
│ │
│ 适中区域 │
│ │
│ ████████████ │ <-- 拇指最容易触达
│ ████████████ │ 把重要操作放这里
│ ████████████ │
└─────────────────┘
所以底部 Tab 栏设计在最下方是有道理的！3. 边缘和角落的优势
在桌面端，屏幕边缘和角落有"无限宽度"效果：
┌──────────────────────────────────┐
│ [文件] [X] <─┤── 角落按钮无限大
│ │ 鼠标怎么移都不会超出
│ │
│ │
│ │
│ │
│ ┌────────────────────────────┐ │
│ │ [开始] │<──┤── 底边按钮也有优势
└─┴────────────────────────────┴───┘席克定律（Hick's Law）
简单解释
席克定律由心理学家 William Edmund Hick 和 Ray Hyman 提出：
用户做出决策所需的时间随选项数量的增加而增加。 选项越多，用户做决定的时间越长，甚至可能放弃选择。
席克定律示意图：
选项数量 决策时间
───────── ─────────
2 快
5 中等
10 慢
20+ 可能放弃
决策时间
^
│ ╱
│ ╱
│ ╱
│ ╱
│ ╱
└──────────────> 选项数量
公式：T = b * log2(n + 1)
T = 决策时间
n = 选项数量
b = 常数应用场景
1. 导航菜单项控制
好的设计：5 个清晰的分类 不好的设计：太多选项
┌──────────────────────┐ ┌──────────────────────┐
│首页│分类│发现│购物车│我的│ │首页│分类│发现│购物车│ │
└──────────────────────┘ │消息│收藏│签到│任务│ │
│设置│帮助│活动│会员│我的│
用户快速做出选择 └──────────────────────┘
用户：到底点哪个？2. 表单选项精简
好的设计： 不好的设计：
渐进式披露 一次全部展示
Step 1: 选择类型 所有选项一次列出
┌──────────────┐ ┌──────────────┐
│ ○ 个人用户 │ │ ○ 选项 1 │
│ ○ 企业用户 │ │ ○ 选项 2 │
└──────────────┘ │ ○ 选项 3 │
先选这一步 │ ○ 选项 4 │
│ │ ○ 选项 5 │
v │ ○ 选项 6 │
Step 2: 再看下一步 │ ○ 选项 7 │
┌──────────────┐ │ ○ ...... │
│ ○ 男性 │ │ ○ 选项 15 │
│ ○ 女性 │ └──────────────┘
│ ○ 不愿透露 │ 用户看到就想关掉
└──────────────┘3. 减少用户决策负担的策略
| 策略 | 说明 | 示例 |
|---|---|---|
| 分类归组 | 将多个选项分组 | 电商分类：先选大类，再选小类 |
| 默认值 | 提供合理的默认选择 | 配送方式默认选"快递" |
| 推荐/高亮 | 突出最佳选项 | "最受欢迎""推荐方案" |
| 渐进式披露 | 分步骤展示 | 多步表单，每步少量选项 |
| 搜索功能 | 大量选项时提供搜索 | 城市选择支持搜索 |
格式塔原则在 UI 中的应用
格式塔（Gestalt）心理学研究人类如何感知和组织视觉信息。以下是几个最常用于 UI 设计的格式塔原则：
1. 接近性原则（Proximity）
原则： 相互靠近的元素被感知为一组。
接近性示例：
有分组感： 没有分组感：
姓名 [ ] 姓名 [ ]
手机 [ ]
手机 [ ]
省份 [ ]
城市 [ ] 省份 [ ]
街道 [ ]
城市 [ ]
^ ^
个人信息 地址信息 街道 [ ]
通过间距自然分组 所有字段等间距
看不出分组关系2. 相似性原则（Similarity）
原则： 外观相似的元素被感知为同一组或同一类型。
相似性示例：
╔══════╗ ╔══════╗ ╔══════╗ <-- 蓝色填充按钮 = 主操作
║ 保存 ║ ║ 提交 ║ ║ 确认 ║
╚══════╝ ╚══════╝ ╚══════╝
┌──────┐ ┌──────┐ ┌──────┐ <-- 灰色描边按钮 = 次要操作
│ 取消 │ │ 返回 │ │ 重置 │
└──────┘ └──────┘ └──────┘
用户自然理解：填充按钮是主要操作，描边按钮是次要操作3. 闭合性原则（Closure）
原则： 人的大脑倾向于将不完整的形状补全为完整的形状。
闭合性示例：
信息流底部的"半露出"卡片：
┌──────────────────────┐
│ 完整的内容卡片 1 │
│ 标题和描述文字... │
└──────────────────────┘
┌──────────────────────┐
│ 完整的内容卡片 2 │
│ 标题和描述文字... │
└──────────────────────┘
┌──────────────────────┐
│ 内容卡片 3 (只露出 │ <-- 半露出的卡片
├──┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┤ 暗示用户"下面还有内容，可以继续滑动"
(屏幕底部)4. 连续性原则（Continuity）
原则： 人倾向于沿着平滑连续的路径感知元素。
连续性示例——步骤条：
● ──── ● ──── ○ ──── ○
填写 确认 支付 完成
信息 订单
用户自然理解这是一个从左到右的连续流程格式塔原则汇总表
| 原则 | 核心含义 | UI 应用场景 |
|---|---|---|
| 接近性 | 靠近的元素被视为一组 | 表单分组、卡片布局、内容区域划分 |
| 相似性 | 相似的元素被视为同类 | 按钮样式区分主次、标签系统 |
| 闭合性 | 大脑自动补全不完整图形 | 列表暗示可滑动、轮播图半露 |
| 连续性 | 沿着路径感知连续关系 | 步骤条、时间轴、流程引导 |
| 共同命运 | 同时运动的元素被视为一组 | 批量选择后统一移动/删除 |
| 图形-背景 | 自动区分前景和背景 | 弹窗 + 背景模糊/遮罩 |
常见交互模式
1. Tab 切换
┌──────────────────────────────────┐
│ 推荐 │ 关注 │ 热门 │ 最新 │
│ ──── │ <-- 下划线/高亮表示当前选中
├──────────────────────────────────┤
│ │
│ 对应内容区域 │
│ │
│ · 点击切换 │
│ · 左右滑动切换 │
│ · 切换时可有过渡动画 │
│ │
└──────────────────────────────────┘
适用场景：同级内容分类展示
代表产品：微博（推荐/热门/同城）、B站（推荐/热门/追番）2. 抽屉导航（Drawer）
收起状态: 展开状态:
┌──────────────────┐ ┌────────┬─────────┐
│ ☰ 标题 │ │ │ │
├──────────────────┤ │ 首页 │ (暗色 │
│ │ │ 设置 │ 遮罩 │
│ 页面内容 │ => │ 关于 │ 背景) │
│ │ │ 帮助 │ │
│ │ │ │ │
│ │ │ 退出 │ │
└──────────────────┘ └────────┴─────────┘
适用场景：低频使用的导航项
代表产品：部分 Android App、Gmail（早期版本）3. 弹窗/对话框（Modal/Dialog）
背景（被遮罩覆盖）
┌──────────────────────────────┐
│ ░░░░░░░░░░░░░░░░░░░░░░░░░░ │
│ ░░░░░░░░░░░░░░░░░░░░░░░░░░ │
│ ░░░ ┌────────────────┐ ░░░ │
│ ░░░ │ 确认删除？ │ ░░░ │ <-- 弹窗
│ ░░░ │ │ ░░░ │
│ ░░░ │ 此操作不可恢复 │ ░░░ │
│ ░░░ │ │ ░░░ │
│ ░░░ │ [取消] [确认] │ ░░░ │
│ ░░░ └────────────────┘ ░░░ │
│ ░░░░░░░░░░░░░░░░░░░░░░░░░░ │
│ ░░░░░░░░░░░░░░░░░░░░░░░░░░ │
└──────────────────────────────┘
适用场景：需要用户确认的重要操作
注意事项：不要滥用，频繁弹窗会打断用户4. 下拉刷新（Pull to Refresh）
下拉过程：
正常状态 下拉中 释放刷新 刷新完成
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ item 1 │ │ │ │ │ │ new! │
│ item 2 │ │ ↓ 下拉 │ │ 刷新中 │ │ item 1 │
│ item 3 │ │ 刷新 │ │ ... │ │ item 2 │
│ item 4 │ │ item 1 │ │ item 1 │ │ item 3 │
│ item 5 │ │ item 2 │ │ item 2 │ │ item 4 │
└────────┘ └────────┘ └────────┘ └────────┘
适用场景：内容列表/信息流页面
代表产品：微博、朋友圈、新闻类 App5. 无限滚动（Infinite Scroll）
┌──────────────────┐
│ 内容 1 │
│ 内容 2 │
│ 内容 3 │
│ 内容 4 │
│ 内容 5 │ <-- 用户看到的内容
├──────────────────┤
│ 加载更多... │ <-- 滑到底部自动加载
│ ○ ○ ○ │
├──────────────────┤
│ 内容 6 │
│ 内容 7 │ <-- 新加载的内容
│ ... │
└──────────────────┘
适用场景：内容型/资讯型/社交型产品的信息流
代表产品：抖音、小红书、Instagram、微博
注意事项：需要提供"回到顶部"功能6. Toast 提示
┌──────────────────────────┐
│ │
│ 页面内容 │
│ │
│ ┌──────────────┐ │
│ │ 操作成功 ✓ │ │ <-- Toast 提示
│ └──────────────┘ │ 1-3 秒后自动消失
│ │ 不打断用户操作
│ │
│ │
└──────────────────────────┘
类型：
┌──────────────┐ 成功 Toast（绿色/勾）
│ ✓ 保存成功 │
└──────────────┘
┌──────────────┐ 错误 Toast（红色/叉）
│ ✗ 网络异常 │
└──────────────┘
┌──────────────┐ 提示 Toast（灰色/信息）
│ ℹ 已复制到剪贴板│
└──────────────┘
适用场景：轻量级的操作反馈
代表产品：几乎所有 App 都在使用交互模式选择指南
| 交互模式 | 最佳场景 | 不适合场景 |
|---|---|---|
| Tab 切换 | 同级内容分类 | 层级关系的内容 |
| 抽屉导航 | 低频操作入口 | 核心功能入口 |
| 弹窗/对话框 | 重要确认操作 | 频繁操作（会打断用户） |
| 下拉刷新 | 信息流更新 | 静态内容页面 |
| 无限滚动 | 浏览型内容 | 需要精确定位的内容 |
| Toast 提示 | 轻量反馈 | 需要用户处理的重要错误 |
移动端 vs Web 端交互差异
移动端和 Web 端由于设备特性不同，在交互设计上有显著差异。PM 需要了解这些差异，才能为不同平台设计合适的交互方案。
全面对比表
| 维度 | 移动端（iOS/Android） | Web 端（PC 浏览器） |
|---|---|---|
| 输入方式 | 触摸（点击、滑动、捏合、长按） | 鼠标（点击、悬停、右键）+ 键盘 |
| 屏幕尺寸 | 小屏（4.7-6.7 英寸） | 大屏（13-32 英寸） |
| 操作精度 | 低（手指触摸面积大） | 高（鼠标光标精确） |
| 导航模式 | 底部 Tab + 手势返回 | 顶部导航栏 + 侧边栏 |
| 内容展示 | 单列为主，纵向滚动 | 多列布局，充分利用宽屏 |
| 信息密度 | 低（受屏幕限制） | 高（大屏可展示更多信息） |
| 表单设计 | 分步填写，减少输入 | 可在一页展示完整表单 |
| 反馈方式 | 震动、声音、动画 | 悬停效果、工具提示 |
| 最小点击区域 | 44pt / 48dp | 无严格限制（但建议 32px+） |
| 手势操作 | 丰富（滑动/捏合/旋转/长按） | 有限（主要是滚动和拖拽） |
| 悬停状态 | 无 hover 状态 | 有 hover 状态（重要交互线索） |
| 页面跳转 | 栈式导航（push/pop） | 平铺式（标签页/新窗口） |
| 键盘 | 虚拟键盘（占用屏幕空间） | 物理键盘（不占屏幕） |
| 多任务 | 一次看一个 App | 多窗口并行 |
| 网络环境 | 不稳定（移动网络） | 相对稳定（有线/WiFi） |
关键差异详解
1. 点击 vs 触摸
Web 端有 Hover 状态： 移动端没有 Hover：
┌────────┐ 鼠标移入 没有"移入"的概念
│ 按 钮 │ ──> 变色/阴影 直接"点击"
└────────┘
│
v 点击
┌────────┐
│ 按 钮 │ ──> 执行操作
└────────┘
Web 设计可以利用 hover 传达信息（如预览、提示）
移动端需要用其他方式替代（如长按预览、引导提示）2. 布局差异
Web 端（多列布局）：
┌──────────────────────────────────────────┐
│ 导航栏 │
├────────┬────────────────────┬────────────┤
│ │ │ │
│ 侧边栏 │ 主内容区域 │ 侧边信息 │
│ │ │ │
│ │ │ │
└────────┴────────────────────┴────────────┘
移动端（单列布局）：
┌──────────────┐
│ 顶部导航栏 │
├──────────────┤
│ │
│ 主内容区域 │
│ (全宽) │
│ │
│ │
│ │
├──────────────┤
│ 底部 Tab 栏 │
└──────────────┘3. 表单设计差异
Web 端（一页展示）： 移动端（分步填写）：
┌──────────────────┐ Step 1/3
│ 姓名 [ ] │ ┌──────────────┐
│ 手机 [ ] │ │ 请输入姓名 │
│ 邮箱 [ ] │ │ │
│ 地址 [ ] │ │ [ ] │
│ 备注 [ ] │ │ │
│ │ │ [下一步] │
│ [提交] │ └──────────────┘
└──────────────────┘
Step 2/3
┌──────────────┐
│ 请输入手机号 │
│ │
│ [ ] │
│ │
│ [下一步] │
└──────────────┘本节小结
┌────────────────────────────────────────────────────┐
│ 本节核心要点 │
├────────────────────────────────────────────────────┤
│ │
│ 1. 尼尔森十大原则是交互设计的基石 │
│ 重点掌握：状态可见性、错误预防、 │
│ 一致性、用户控制与自由 │
│ │
│ 2. 费茨定律：目标要大且近 │
│ 重要按钮要够大、放在容易触达的位置 │
│ │
│ 3. 席克定律：选项要少且清晰 │
│ 用分组、默认值、渐进式披露减少决策负担 │
│ │
│ 4. 格式塔原则帮助设计清晰的视觉层级 │
│ 接近性和相似性是最常用的两个原则 │
│ │
│ 5. 熟悉常见交互模式的适用场景 │
│ 不要为了炫技而选择不合适的交互模式 │
│ │
│ 6. 移动端和 Web 端交互差异大 │
│ 不能直接照搬，需要针对性设计 │
│ │
└────────────────────────────────────────────────────┘练习任务
- 打开你常用的 3 个 App，逐条对照尼尔森十大原则，找出做得好和做得不好的地方
- 观察你手机中各 App 的按钮大小，是否符合费茨定律
- 找一个你觉得选项过多的页面，思考如何运用席克定律进行优化
- 对比同一个产品的 App 版和网页版（如淘宝），总结交互差异