单元四 · 流程⑤ · 流程线框

用户流程

用户流程（User Flow），就是把"用户想办成的一件事"，变成一条"从哪进、每步做什么、到哪结束"的可走路径。它是设计里最容易漏掉的一层，却正是"好看 ≠ 好用"的分水岭。

好看 ≠ 好用：设计要按用户任务走

很多 App 每页都画得漂亮，但用户真上手却找不到下一步、点错、卡住。根子在哪里？设计是按页面做的——每个画板都精致；而不是按用户任务做的——用户完成一件事要经过哪些步。设计师盯着"每页好不好看"，用户盯着"我的事办成没有"，视角错位，所以好看不等于好用。

用户流程，就是把"用户任务"变成"可操作路径"的那层设计。它的定义是：用户为完成一个任务所走的步骤序列。它回答的不是"有哪些页面"，而是"用户要办成这件事，从哪进、每步做什么、到哪结束"。

用户流程 = 用户为完成一个任务所走的步骤序列，回答"从哪进、每步做什么、到哪结束"，而非"有哪些页面"。

流程的四大要素

微信"收到消息→回复"是一条教科书级流程，完整路径如下：

收到通知（起点：想回消息）
 ↓
打开微信（动作）
 ↓
读消息（动作）
 ↓
点输入框（动作）
 ↓
打字（动作）
 ↓
发送（决策/动作）
 ↓
看到"已发送"反馈（终点：任务完成）

从"收到通知"这个起点开始，每一步都是一个步骤，最后一步是终点——用户得到反馈，知道自己成功了。这条流程里，用户全程几乎不用想——微信把每一步都做得无需思考，这就是好流程的样子。

一条用户流程能拆成四样东西：

• 起点：用户的动机——为什么想用这个 App（"微信响了，我想回消息"）。
• 步骤：每一步的动作或决策——点哪、输入什么、在哪做选择。
• 终点：任务完成——办成、得到反馈（"消息发出去了"）。
• 异常/中断路径：走偏的路——点错、中途退出、找不到、遇到报错。这些岔路也是流程的一部分，好设计要兜住。

流程四要素 = 起点（动机）· 步骤（动作/决策）· 终点（任务完成）· 异常/中断路径。

用户流程 ≠ 页面跳转图

核心误区先排掉："流程 = 页面跳转图"是错的。 页面跳转图从页面出发，画"页面 A → 页面 B → 页面 C"；用户流程从用户任务出发，画"用户想办的事 → 每一步动作/决策 → 办成"。页面跳转图是设计者的视角（我有这些页，它们怎么连），用户流程是用户的视角（我要办的事，我该走哪）。先有用户流程，页面跳转才顺理成章。

典型区别：同一个页面可以出现在多条不同任务里——"设置"页，改密码要进、清缓存要进、换头像也要进。页面跳转图会画成"设置 → 各种子页"；而流程会分别画"改密码 → 进设置 → …"和"换头像 → 进设置 → …"两条不同的任务路径。流程以任务为单元，页面只是路上的站点。

页面跳转图从"页面"出发看"页面怎么连"；用户流程从"任务"出发看"用户怎么走"——先任务，后页面。

好流程 = 主路顺畅 + 岔路兜底

微信"发一条朋友圈"的完整路径：

我 → 发现 → 朋友圈（起点：想分享此刻）
 ↓
点右上角"相机"图标（动作）
 ↓
选照片 / 拍照片（动作）
 ↓
输入文字（动作）
 ↓
点"发表"（决策/动作）
 ↓
看到动态出现在自己时间线（终点：任务完成）

微信把起点做得很浅——"发朋友圈"入口在朋友圈页右上角，不必回首页；把终点做得很实——发出后立刻能在自己时间线看到，用户确定"发成了"。异常路径也兜好了：没选照片也能发文字、没写文字也能发纯图、中途退出草稿还在——每一个岔路，微信都接住了。一条流程好不好，就看三点：起点浅不浅、终点实不实、岔路兜不兜。

用户不是机器，随时会点错、会退出、会找不到。真正的流程不只是画一条顺畅的主路，还要画清三条岔路：

• 退不回：想返回上一步，有没有明显的返回？（发消息前想改字，能不能退回去改？）
• 走不通：点了没反应、报错、加载失败，怎么办？（弱网时发送失败，怎么提示、怎么重试？）
• 中途反悔：填到一半想退出，会不会丢内容？（打了一大段字误触返回，字还在吗？）

把异常路径画出来，才知道主路之外有多少需要兜底的设计。一条"主路顺畅 + 岔路兜底"的流程，才是好流程。

好流程三看 = 起点浅 · 终点实 · 岔路兜。

流程不是画一次就定型

流程不是画完就完的静态图，要不断验证优化。一是验证：用户真的会按你画的走吗？看着流程以为顺，真正用起来用户可能卡在某一站——要拿真实用户测试（让朋友真去发一条朋友圈，看哪里卡住）。二是砍步骤：每多一步，就多一次放弃的可能；优化流程，就是不断缩短任务路径、排除卡点。

什么时候要重新画流程？任务变了——用户要办的事本身变了（不只是换页面布局），就要重画，因为流程跟着任务走、不跟着页面走；用户行为变了——数据发现用户老在某一站卡住、老走另一条岔路，就说明这条流程该优化了。流程是跟任务、跟真实使用数据一起演进的，不是画一次就定型。

流程线 = 任务演化线：任务一变即重画 · 数据一卡即优化，不是画一次就定型。

深度

流程 vs 导航（18）：流程是一条任务路径（用户办一件事走的步），导航是页面间的组织结构（页面怎么连成一棵树）。两者相关但不同：导航定好了"页面怎么组织"，流程决定"用户办一件事时具体走哪几条路"。

相关知识点：本课的"页面怎么组织"见 16 信息架构；本课的"导航形态"见 18 导航模式；每条流程里的"用户心理"见 21 用户心理。

泛化"从任务出发"的设计思维：把"按页面设计"换成"按任务设计"能迁移到很多场景——写说明文档时先想"读者要办成什么"，而不是"有哪些章节"；做汇报动线时先想"听众听完要做什么决定"，而不是"放几页 PPT"。用户流程教你的是：先定义"要办成的事"，再组织"怎么一步步到"。

误区

误解	正解
流程 = 页面跳转图	错。页面跳转图从"页面"出发看"页面怎么连"；流程从"用户任务"出发看"用户怎么走"；先任务，后页面。
流程只画一次就定型	错。流程要不断验证优化：真实用户测试、砍掉多余步骤、排除卡点。
流程只画顺畅主路就够了	错。异常/中断路径（退不回、走不通、中途反悔）也是流程的一部分，好设计要兜住。
流程就是导航	错。流程是一条任务路径；导航是页面间组织结构，相关但不同。
流程越复杂越完善	错。好流程是短而顺的：起点浅、终点实、岔路兜，而不是步骤越多越好。

练习

即时题 Q：有设计师说"用户流程就是画一张页面跳转图，把每个页面连起来就行"。请用"流程从用户任务出发"的原理反驳它，并说明：同样是"设置"页面，为什么"改密码"和"换头像"应该画成两条不同的流程，而不是一张"设置 → 子页"的跳转图。

模块题 Q：设计一个"外卖点餐"App 里"下单"这个任务的用户流程：

1. 写出这个任务的起点（用户动机）、步骤（至少 4 步的每个动作/决策）、终点（任务完成）。
2. 用箭头式的步骤序列，把这条主流程画出来。
3. 列出至少 2 条异常/中断路径（如购物车为空、地址没填、支付失败、中途退出），并说明每条该怎么兜底。
4. 说明：如果"下单"流程要优化，你会力争砍掉哪一步？为什么砍掉它能让用户更愿意下单？

迷你案例 画微信"回复消息"的流程：在 Penpot 新建一个 375×812 画板，或直接用纸笔。

1. 列出"收到消息→回复"这条任务的起点（收到通知）、步骤（打开→读→点输入框→打字→发送）、终点（看到"已发送"）。
2. 用箭头把这条主流程画成一条线，每个节点标注是"动作"还是"决策"。
3. 在主线下方另画一条异常路径：比如"弱网发送失败"——用户点了发送，转圈后失败，微信提示重试。这条岔路该怎么兜底？
4. 再想一步：如果微信要在"回复"流程里砍一步，比如把"打字"变成"语音转文字"，流程会怎么变？砍掉这一步对用户意味着什么？
5. 对比：如果把这条流程画成"页面跳转图"（聊天列表→聊天页→键盘→…），和你画的"任务流程线"有什么本质不同？

做完你会信服：用户流程不是"画页面怎么连"，而是从用户任务出发，把"完成一件事的路径"一步一步铺清楚。

答案 即时题：页面跳转图从"页面"出发，把"设置"画成"设置 → 子页"的树状连接；而流程从"任务"出发，"改密码"和"换头像"是两条不同的任务路径——它们动机不同、走的步骤不同、要兜的岔路也不同，画成两条流程才能分别看出"办成这件事"的深浅与卡点。先任务，后页面。

素材

• 用户流程经典概念：搜索 "User Flow" / "Task Flow"（从任务出发的流程，区分"页面跳转图"的关键）。
• 任务测试：搜索 "Task Test"（让真实用户走一遍任务，验证流程是否顺畅）；"Card Sorting"（卡片排序，找用户心智）。
• Apple HIG：以人为本的流程设计（官方，如何围绕用户任务组织交互）。
• Material Design 3：用户流程与导航（官方，任务路径与页面组织）。
• 相邻知识点：本课的"页面怎么组织"见 16 信息架构；"导航形态"见 18 导航模式；"每条流程里的用户心理"见 21 用户心理。

导航模式

导航模式是用户在整个 APP 里**"怎么走路"的那套结构**——底部 Tab、顶部导航、返回堆栈、侧边栏,决定用户从哪进、往哪走、怎么回头。产品功能都做出来了,用户却走不顺、回不去,根子往往就在导航结构。信息架构(16)决定"内容怎么摆",导航决定"用户怎么走";架构在前,导航在后。

导航是什么:用户怎么走路

用户进到 App 里会"迷路",通常不是功能不够,而是结构没搭好——不知道现在在哪、下一步能去哪、怎么回上一页。导航,就是控制用户在整个 APP 里移动方式的那套结构。它和上一课的信息架构(16)是两件事:信息架构决定"内容怎么组织"(分类、层级、命名),本课决定"用户怎么走"(走哪条路、怎么回)。先想清楚内容怎么摆,才谈得上用户怎么走到。

导航回答三件事:从哪进、往哪走、怎么回头。

五大导航模式

五大模式对号入座:

模式	长什么样	适合	微信例子
底部 Tab	屏幕最下方一排按钮	几个最高频入口全局可见、一键直达	聊天 / 通讯录 / 发现 / 我
顶部导航	屏幕顶部标签页或标题	同一屏内切换查看	某页顶部的"微信 / 联系人 / 发现"分段
返回堆栈	点进列表项 → 进详情 → 点"←"返回	有父子关系的层级	聊天列表 → 进入对话 → 返回列表
侧边栏	从侧边滑出一列菜单	收纳低频入口、不占主屏	发现页的分组入口
搜索	一条直达通道	内容太多、不想慢慢逛	全局搜索直达任意内容

App 里常用的导航,收敛成五种模式。每种解决一类"走法":底部 Tab 管最高频入口、顶部导航管同一屏内切换、返回堆栈管嵌套层级、侧边栏收纳低频入口、搜索直达任意内容。它们不是互斥的——一个成熟 App 往往是多种模式的组合。

底部 Tab:全局主导航

微信底部四个 Tab 是四类最高频心智各占一个:聊天、通讯录、发现、我,全局可见、位置稳定,用户不抬眼就能点到。

底部 Tab 是主导航,把几个最高频入口钉在屏幕最下方,全局可见、一键直达。它有硬约束:通常 3~5 个、放最高频的入口、位置稳定不常变。数量少、可见、稳定,用户靠"位置记忆"就能盲点——不用看就知道第几个是"聊天"。放多了或放低频项,只会稀释用户对最高频入口的注意力。

底部 Tab 通常锁在 3~5 个,放最高频入口,位置稳定。

5±2 认知负荷:为什么 Tab 不能乱加

"导航越多越方便"是误区。人的工作记忆有限,一次能同时处理的"概念块"大约只有 5±2 个(心理学上通常说 7±2,设计上更保守取 5±2)。导航条目塞得越多,用户越记不住、越要"想一下"才找得到。底部 Tab 被锁在 3~5 个:既够放最高频入口,又不至于让用户握不住、记不住。超过 5 个,用户就要停下来看图标猜,导航的"可盲点"优势就没了。

人的工作记忆约 5±2 个概念块;底部 Tab 超过 5 个,位置记忆失效。

返回堆栈:层级导航"进一层退一层"

返回堆栈用于有父子关系的层级:列表 → 详情 → 再下一层。它的法则很简单——进一层记一层,返回就退一层,方向永远可预期。用户迷路时,第一个救命稻草就是"能回上一页"。微信的"聊天列表 → 进入对话 → 返回列表"就是典型:一堆对话,靠"进一层退一层"的堆栈,用户永远知道自己从哪来、能回哪去。

堆栈法则:进一层记一层,返回退一层,方向始终可预期。

怎么选:按"顶层还是层级"

微信是三者组合——底部四 Tab 管顶层、聊天返回堆栈管层级、发现页分组管密集入口:每种模式各管一类"走法"。发现页几十个入口(朋友圈、扫一扫、小程序)不平铺乱放,而是分成几组(社交 / 工具 / 服务),组名即导航,用户先选组、再选入口。

选哪种导航,看这个入口是顶层还是层级:

• 底部 Tab:给几个最高频、各自独立的大分类当顶层入口。判断——用户不离手、天天要进的,放 Tab;超过 5 个就说明顶层分类划太细,回去重划信息架构。
• 顶部导航:给"同一大块里的几个小视图"做切换,是"Tab 之下的下一层",别和底部 Tab 抢顶层。
• 返回堆栈:给有父子关系的层级用,方向永远可预期。
• 侧边栏:给低频、但需要有入口的项,收进抽屉不占主屏。
• 搜索:给内容太多、不想逛时用,一条直达通道。

判断口诀:顶层高频进 Tab,层级往返走堆栈,低频收纳进侧边栏,太多太急用搜索。

深度

原理:为什么"导航越多"反而更差? 底层是 Miller's Law——人的工作记忆是个"小篮子",一次能握住的"概念块"有限。放 3 个你能轻松记住位置、盲点;放到 8 个,篮子装不下,必须松开几个,于是得停下来一个个看图标猜。导航的价值在"走得顺、不用想",不在"路多"。

边界:什么时候导航会变?

• 顶层入口超 5 个:说明信息架构把顶层划太细,该回去重划(见 16),而不是往 Tab 里硬塞。
• 用户行为变:某功能从"偶尔用"变"天天用",要往 Tab 提;反之下沉到"发现页 / 侧边栏"。微信"视频号"逐步前置就是例子。
• 返回逻辑乱了:用户"回上一层"却回到陌生页面,说明堆栈没守好"进一层退一层"法则,要修,而不是加更多返回按钮。

实例:微信导航结构(可合理推断)。底层四 Tab 是顶层横向导航;聊天 → 返回堆栈是层级纵向导航;发现页是分组导航。整体看,微信是"横向 Tab 管顶层 + 纵向堆栈管层级 + 分组管密集入口"的组合。说明:微信 iOS 实际入口与分组随版本微调,这里给出的是以"导航模式"思路推断的合理结构,用于学习"如何拆解导航",而非精确工匠数据。

误区

误解	正解
导航越多越方便	错。5±2 认知负荷,导航越多越记不住、越要"想";价值在"走得顺",不在"路多"。
底部 Tab 想加就加	错。Tab 有硬约束:通常 3~5 个、放最高频入口、位置稳定不常变。
导航 = 信息架构	错。信息架构(16)决定"内容怎么摆",导航决定"用户怎么走";架构在前,导航在后。
返回按钮越多越安全	错。返回靠堆栈"一层退一层"的可预期逻辑,不是按钮堆得多。
侧边栏能装下一切	错。侧边栏是低频入口的收纳抽屉,不能当"藏东西"的地方,否则用户根本不知道入口在哪。

练习

即时题 一个 App 底部放了 7 个 Tab:首页、分类、购物车、消息、我的、优惠券、客服。用户反映"老点错、找不到想要的"。请用"5±2 认知负荷"和"底部 Tab 规范"解释问题出在哪,并给出合理重构方案(说明哪些该留、哪些该挪去哪、为什么)。

模块题 为"个人记账 App"设计导航结构:

1. 用底部 Tab 设计顶层导航(3~5 个),说明每个放什么、为什么是最高频入口。
2. 设计"记一笔"的进入路径:应在一层内直达,还是一层层去?为什么(联系 16 的"浅层可达")?
3. 设计"账单列表 → 一笔明细 → 返回列表"的返回堆栈,说明为什么"一层退一层"让用户不迷路。
4. 说明硬塞进第 6、7 个 Tab,用户会遭遇什么(用 5±2 讲)。
5. 指出如果按"数据库表(收入 / 支出 / 转账 / 查询)"来分 Tab,为什么用户会晕。

迷你案例:给微信画一套"导航结构" 在 Penpot 新建 375×812 画板:

1. 画底部 Tab 区:四个 Tab(聊天 / 通讯录 / 发现 / 我),当前高亮一个。
2. 给"聊天"Tab 画返回堆栈:聊天列表 → 进入一个对话 → 左上角"←"返回列表,标出"进一层 / 退一层"。
3. 给"发现"Tab 画分组导航:把朋友圈、扫一扫、小程序等归成 2~3 组,组名即导航。
4. 加一个"闹着玩"版本:把 Tab 加到 8 个,亲眼看为什么超载。
5. 想一步:如果"小程序"变成人人天天用,它该从"发现页分组"挪到哪?(提示:往 Tab 提、给大入口。)

做完你会信服:导航不是"随便放几个按钮",而是决定用户走得顺不顺、会不会迷路的那套结构。

答案 即时题:7 个 Tab 超出 5±2 认知负荷极限,用户记不住位置、必须停下来看图标猜,所以"老点错"。重构:留最高频的 4~5 个(如首页 / 分类 / 购物车 / 我的),把低频的"优惠券""客服"挪进侧边栏或"我的"页,把"消息"并入"我的"或保留——按"是否天天用"判断,而非按功能重要度。

素材

• 👉 打开交互演示：导航模式 — 点底部 4 Tab 切换页面,加开关升到 8 个,亲手体会 5±2 超载后位置记忆失效。
• Apple HIG:Human Interface Guidelines > Navigation(官方,返回堆栈、层级导航、导航结构)。
• Material Design 3:Navigation(官方,底部导航、侧边栏等模式与规范)。
• 5±2 / Miller's Law:搜索 "Miller's Law 7±2" / "chunking"(心理学经典,认知负荷极限的来源)。
• 信息架构:本课"架构在前、导航在后"的架构层,见 16 信息架构;导航视觉落地的间距 / 对齐,见 09 对齐与亲密性。

---