真实用户不会按原型从第一屏一路走到成功。他会断网、切后台、拒绝权限、登录过期或从通知直接进入。流程设计要能接住这些岔路，而不是只画最顺的一条线。
真实用户不会按原型从第一屏一路走到成功。他会断网、切后台、拒绝权限、登录过期或从通知直接进入。流程设计要能接住这些岔路，而不是只画最顺的一条线。
01 用户不会沿着设计稿的直线走
原型通常展示最顺的一条路径：打开APP、登录、选择、提交、成功。真实使用却充满岔路：网络断了，验证码过期，权限被拒，用户切到微信查资料，系统在后台被回收，支付返回状态不确定。只设计“正常完成”，相当于把最容易出问题的部分留给开发临场决定。
APP用户流程应被看作状态与事件的组合，而不是几张页面之间的箭头。页面说明“用户看到什么”，流程还要说明“系统知道什么、发生什么变化、失败后从哪里继续”。
02 用四条轨道画流程，而不是只画页面
| 轨道 | 需要记录的内容 | 例子 |
|---|---|---|
| 用户动作 | 点击、输入、返回、切换、授权、取消 | 用户点击提交后切到短信查看验证码 |
| 界面反馈 | 加载、提示、可操作状态、下一步 | 按钮进入处理中，显示可返回但不要重复提交 |
| 系统状态 | 本地草稿、服务端记录、登录态、支付态 | 订单已创建，但支付结果待确认 |
| 外部事件 | 网络、权限、第三方、系统中断、深链 | 相机权限被拒；第三方支付回调延迟 |
四条轨道能暴露“页面看起来有反馈，但系统其实没有保存”“用户返回后不知道该回哪一步”等问题。它也让产品、设计和开发在同一张图上确认边界。
03 每个关键步骤至少检查八种状态
| 状态 | 设计问题 |
|---|---|
| 初始 | 用户为什么来到这里？默认值从哪里来？ |
| 空 | 没有数据是正常、尚未创建，还是加载失败？ |
| 加载 | 是否可以取消或离开？需要骨架、进度还是后台任务？ |
| 成功 | 成功的证据是什么？下一步是否明确？ |
| 失败 | 失败发生在哪一层？用户能否修复或重试？ |
| 离线/弱网 | 哪些内容仍可查看？操作是排队、禁止还是保存草稿？ |
| 权限不足 | 是设备权限、账号权限、角色权限还是状态限制？ |
| 中断恢复 | 应用重启、登录失效或支付返回后，从哪里继续？ |
不是每个页面都要展示八套视觉稿，但关键流程必须有状态规格。对于简单状态，可以在组件说明中记录；涉及资金、身份、健康或数据提交的流程，应单独画出恢复路径。
04 先设计中断，再设计“返回”
移动端的中断不是异常，而是日常。用户会接电话、切换应用、锁屏、复制资料，系统也可能回收进程。恢复时如果总把用户送回首页，前面填写的内容和信任一起丢失。
- 短表单可以本地保留未提交内容；敏感信息要评估加密、失效时间和设备共享风险。
- 多步骤任务记录已确认步骤与草稿版本，恢复时明确“已为你保留到第3步”。
- 登录失效时，完成重新登录后返回原任务，而不是统一跳首页。
- 第三方支付、地图或身份认证返回时，先查询真实状态，再决定进入成功、待确认还是重试。
- 深链进入子页面时，若前置条件不足，补齐后应回到目标，而不是让链接失效。
- 系统返回键与页面内返回必须有一致规则；离开会丢失数据时才提示确认。
05 登录与授权应该出现在“需要它”的时刻
一打开APP就要求手机号、定位、相册、相机和通知，会把价值尚未建立的用户赶走。流程设计应区分浏览所需、任务所需和可选权限。
| 请求 | 更合适的触发时机 | 拒绝后的路径 |
|---|---|---|
| 登录/注册 | 保存、同步、交易或查看个人数据前 | 允许继续浏览，解释登录后获得什么 |
| 相机 | 用户主动选择拍摄或扫码时 | 提供从相册选择或手工输入 |
| 定位 | 用户选择附近服务或需要配送地址时 | 允许手工选择城市和地址 |
| 通知 | 用户完成一次有价值任务后，说明提醒内容 | 在设置中保留开启入口，不反复打扰 |
| 通讯录 | 明确的邀请或匹配场景中 | 支持复制链接或手工输入 |
权限文案不要只说“为了提供更好服务”。应说明具体用途、是否持续使用，以及不授权还能怎么完成任务。
06 一个订单流程，至少不止“提交成功”
- 用户确认商品与地址，系统检查库存、价格和配送范围。
- 创建订单后获得唯一订单状态；即使支付未完成，用户也能在订单列表找到它。
- 跳转支付前防止重复点击，并保存返回目标。
- 从支付渠道返回后先显示“正在确认”，由服务端结果决定成功或失败。
- 若状态暂时未知，允许用户离开并在订单页继续查询，不要求重复支付。
- 库存变化、优惠失效、地址不支持等失败分别给出可修复动作。
- 成功后说明订单号、后续节点和通知方式，而不只是放一张庆祝插画。
07 把流程规格交给开发，而不是只交原型链接
| 规格项 | 示例 |
|---|---|
| 入口 | 首页、消息、分享链接、系统通知、历史任务 |
| 前置条件 | 登录、角色、设备权限、网络、资料完整度 |
| 关键数据 | 哪些在本地，哪些已提交服务端，何时生成ID |
| 状态与事件 | 加载、成功、失败、超时、取消、外部回调 |
| 返回规则 | 系统返回、页面返回、关闭、深链和重新进入 |
| 错误恢复 | 重试、修改、保存草稿、联系客服、转人工 |
| 监测点 | 流程开始、步骤完成、错误类型、放弃与最终成功 |
08 上线前，至少跑完这些“打断测试”
- 提交时断网，再恢复网络；确认不会重复创建。
- 填写一半杀掉进程，重新打开；确认草稿与步骤位置。
- 验证码发送后切后台超过有效期；确认错误与重新获取。
- 拒绝设备权限，再从系统设置开启；确认页面能感知变化。
- 支付后未返回APP，直接从桌面重新进入；确认订单状态。
- 通过旧通知或分享链接进入已失效对象；确认说明和替代入口。
- 账号在另一设备被停用或角色变化；确认当前页面及时收回能力。
常见问题
流程图应该由产品还是设计负责？
产品通常负责业务规则与成功条件，设计负责用户动作、界面反馈和恢复体验，开发补充系统状态与技术约束。复杂流程最好共同维护一份，而不是各画一套。
每个异常状态都要单独出高保真稿吗？
不需要。高风险、强业务差异和新组件需要完整设计；可复用的加载、空状态、网络错误可以引用组件规范，但文字、触发条件和动作仍要写清。
流程越短是不是体验越好？
不一定。减少无意义步骤是好事，但把确认、解释或风险提示全部删掉，会增加错误成本。评价流程要看任务完成、理解、恢复与信任，而不是只数页面。
09 让用户从任何岔路都能回到任务
完整的APP流程不是一条漂亮的成功路径，而是一张可恢复的状态网络。用户可以中断、犯错、拒绝授权或暂时离线；系统仍能告诉他发生了什么、数据是否保存、下一步怎么继续。
链接复制成功
