User Flow（用户流程）
User Flow 把用户目标展开成一条由入口、操作、系统状态、决策分支、失败恢复和成功结果组成的完整任务路径。
[!info] related notes
- 所属 MOC: ui-ux-moc
- 前置概念:
- 并列概念:
- 易混淆概念:
- 关系笔记:
User Flow（用户流程）
一句话定义
User Flow 是用户为了完成一个目标，在产品里经过的一连串操作、系统状态和决策分支。
它不是“有哪些页面”，而是：
用户从哪里进入，做了什么，系统如何回应，遇到分支或失败怎么办，最终怎样完成目标。
为什么要在页面之前设计 Flow
如果先画页面，很容易出现：
首页
详情页
设置页
弹窗但仍然不知道：
- 用户为什么从首页去详情；
- 点击以后发生什么；
- 信息不完整时去哪；
- 请求失败怎样恢复；
- 任务什么时候算完成。
所以更好的顺序是：
User Goal
↓
User Flow
↓
需要哪些状态和信息
↓
需要哪些页面 / Panel / Dialog页面是 Flow 的承载方式，不是 Flow 本身。
一个完整 User Flow 至少包含什么
Entry：入口
用户从哪里进入？
例如：
- 主工作台；
- 一次咨询结束后自动进入；
- 点击某条历史记录；
- 通知直接跳转。
不同入口可能意味着不同上下文，不能默认所有人都从首页开始。
Action：用户动作
用户做了什么？
例如：
- 点击；
- 输入；
- 选择；
- 拖动；
- 确认；
- 拒绝；
- 停止；
- 重试。
System Response：系统回应
每个关键动作都应该有系统回应：
点击区域
→ 区域高亮
→ 详情更新而不是只有“用户点了一个东西”。
Decision：决策分支
真实流程很少是一条直线。
例如：
信息是否足够？
├─ Yes → 生成当前摘要
└─ No → 继续向用户提问Failure / Recovery：失败与恢复
必须把失败路径也画进 Flow：
请求失败
├─ Retry
├─ 保留已有内容
└─ 返回上一稳定状态Success：成功状态
必须定义：什么时候算“用户目标已经完成”？
如果成功条件没有定义，产品很容易不断增加步骤和信息。
Happy Path 不够
初学者经常只画：
点击 → 成功 → 完成真实产品还应该考虑：
loading
empty
partial
permission denied
AI uncertain
validation failed
network error
cancelled
retry因此 User Flow 和 前端交互状态统一处理 是相连的：前者描述任务路径，后者帮助前端把请求生命周期映射成界面状态。
BodySense：身体状态地图的 User Flow
主路径
进入 BodySense 工作区
↓
身体记录加载
↓
显示有记录的身体区域
↓
用户点击左肩
↓
左肩高亮 + 显示当前摘要
↓
用户阅读
├─ 信息足够 → 结束本次查看
└─ 想补充 / 有疑问
↓
继续咨询
↓
AI 收集补充信息
↓
更新相关身体记录
↓
地图和详情同步变化这里已经能推导出很多前端需求：
- 区域必须可点击；
- 选中状态必须可见；
- 详情和当前区域必须同步；
- 从咨询回来以后数据要更新；
- 用户需要能继续咨询，而不是查看后无路可走。
Empty 分支
进入身体地图
↓
没有任何记录
↓
显示 Empty State
↓
告诉用户数据如何产生
↓
进入 / 回到咨询这时 Empty State 承担 onboarding；有记录以后，这段解释应消失。
AI 不确定分支
假设用户说“肩膀这边不舒服”，系统无法确定左右侧：
用户描述
↓
AI 发现区域不确定
↓
询问：左肩、右肩，还是双侧？
↓
用户确认
↓
再更新身体地图这比 AI 猜一个区域然后静默写入更好的原因，不是“UI 更复杂”，而是它减少了错误事实进入系统。
失败分支
点击左肩
↓
详情请求失败
↓
人体地图仍保留
↓
详情区显示错误 + Retry
↓
重试成功这里体现一个重要原则：
局部失败不应该无理由摧毁整个页面上下文。
Agent 产品中的 User Flow
传统软件往往更确定：
User Action → Known System Action → ResultAgent 产品会出现更多中间状态：
User Intent
↓
Agent starts work
↓
needs context?
├─ yes → ask user
└─ no
↓
uses tools / retrieves evidence
↓
needs approval?
├─ yes → wait for user
└─ no
↓
result
↓
user accepts / corrects / continues因此设计 Agent Flow 时要特别加入：
- ask user；
- tool execution；
- permission / approval；
- streaming / progress；
- uncertainty；
- interrupt；
- retry；
- correction；
- resume。
详细见 AI / Agent UX 设计。
实战中怎么写 User Flow
最小文本版
Goal:
用户想完成什么？
Entry:
从哪里进入？
Main Path:
A → B → C → Success
Decision:
在哪些地方会分支？
Failure:
哪里可能失败？
Recovery:
失败后用户怎么办？
Exit / Success:
什么状态算完成？更适合 Review 的状态版
[进入]
↓
[加载]
├─ fail → [错误] → retry ─┐
└─ success │
↓ │
[有数据?] ←─────────────────┘
├─ no → [Empty] → [开始咨询]
└─ yes
↓
[选择区域]
↓
[查看详情]
├─ done → [结束]
└─ continue → [继续咨询] → [更新记录]Flow Review 的问题
每次设计功能可以问：
- 入口是否只有一个？是否存在深链、通知等其他入口？
- 用户是否知道第一步做什么？
- 有没有没有意义的中间步骤？
- 是否要求用户重复输入系统已经知道的信息？
- 决策分支是否自然？
- Loading 时用户能做什么？
- 失败后能不能恢复？
- 用户能不能取消、返回或改正？
- AI 不确定时是猜测，还是把控制权交回用户？
- 成功以后有没有自然的下一步或明确结束？
User Flow 与状态机的区别
两者很接近，但关注点不同：
- User Flow 从用户任务看整个过程；
- 状态机从系统可达状态和转换规则看过程。
例如 User Flow 写：
用户发送问题 → AI 回答 → 用户继续追问工程状态机可能进一步拆成：
idle → submitting → streaming → completed
↘ error → retry
↘ cancelled产品设计先保证 Flow 合理，工程实现再把它收敛成明确状态和事件。
与信息架构的关系
信息架构 决定信息和入口如何组织；User Flow 决定用户怎样穿过这些信息完成任务。
最短记忆：
IA 设计空间，Flow 设计路径，Interaction 设计每一步怎么发生。
Digital Biome