检查原型是否完整，不能只看“从首页点到成功页”是否顺畅。原型分支覆盖要把每个会改变用户下一步的条件列出来，确认它有明确去向、恢复操作和信息保留规则。先走正常路径，再检查失败、取消、返回和权限变化；一条分支只有能从入口走到结果并继续任务，才算在原型中得到表达。
例如员工上传报销凭证时选错格式，正确的恢复不是回到一张空表，而是保留金额与事由，让他只替换凭证。可以用墨刀制作正常与异常分支的交互原型，把这些页面连接起来交给同事逐条评审。
一条分支要说清触发、去向和返回
这里的分支是用户任务中的不同结果，不是代码测试的分支覆盖率。“上传失败”四个字并不是完整分支，还应说明从哪一步失败、用户看到什么、之前填的内容是否保留，以及如何继续。
以一笔交通费报销为例，设定草稿金额 1,280 元，事由为“客户拜访交通费”。本例的业务规则是凭证只接受 JPG、PNG 和 PDF；这是一份待设计的报销规则，并非原型工具的上传格式限制。
| 编号 | 触发条件 | 应出现的结果 | 恢复时保留什么 |
|---|---|---|---|
| B-01 | 选择允许格式的凭证 | 显示文件名，可继续提交 | 金额、事由、凭证 |
| B-02 | 选择 HEIC 凭证 | 说明允许格式，可重新选择 | 金额、事由；不把无效凭证标成已上传 |
| B-03 | 打开替换凭证后取消 | 回到此前的草稿状态 | 原凭证及已填字段 |
| B-04 | 提交返回明确失败 | 解释失败并给出下一步 | 本次草稿及已上传凭证 |
| B-05 | 提交后结果尚不明确 | 显示处理中或查询结果入口 | 同一笔申请的上下文 |
| B-06 | 离开未保存的编辑页 | 明确继续编辑与放弃修改的选择 | 继续编辑时保留当前输入 |
不同结果需要不同处理。明确失败可以讨论重试；结果尚不明确时，直接催促用户再提交可能造成重复申请。原型需要表达这两个状态的区别，实际提交是否去重则由业务接口规则决定。
先划清这一轮任务的入口和终点
从“已填写金额与事由的报销草稿”开始，到“凭证修正后回到确认页”为止，足以验证错误恢复是否顺畅。不必同时覆盖审批、财务付款和个人账单，否则分支表容易变成整个系统的功能清单。
把参与者、初始数据、完成状态写在原型首页说明中：
- 参与者：正在提交本人交通费报销的员工，不包含审批人操作。
- 开始状态：1,280 元和“客户拜访交通费”已填写，等待添加凭证。
- 本轮任务：处理不符合格式要求的凭证，并继续核对报销信息。
- 完成状态：确认页显示同一金额、事由与新凭证，员工知道可以继续提交。
入口写清后，就能判断某个问题是不是本轮遗漏。审批人拒绝申请属于另一段流程；取消替换凭证却回到空白表单，才是当前任务内必须处理的缺口。
沿正常路径找真正会改变结果的节点
先连出“草稿—选择凭证—凭证已添加—确认”这条路径。然后逐个询问：这个动作是否可能被取消？输入是否可能无效？结果是否可能延迟？返回时是否会丢失内容？条件改变后，原页面是否仍能解释发生了什么？
不需要把每次悬停和每个装饰按钮都画成独立分支。只有当条件改变了任务结果、下一步动作或必须提供的信息时，才加入清单。例如鼠标经过附件图标通常不用单列，但“凭证未上传完成时能否继续提交”需要明确。
若状态过多，可以先用状态机图梳理事件与状态迁移，再回到原型检查用户能看到的页面。状态图回答允许发生什么，原型回答发生后用户如何理解和操作。
让错误恢复回到同一份报销草稿
为本例准备“凭证待添加”“凭证格式不支持”“凭证已替换”“报销确认”四个主要页面，并保留相同的草稿信息。不要在每张页面随意换金额、姓名或报销单号，否则评审者无法判断信息是被保留了，还是进入另一笔申请。
- 从草稿上的添加凭证操作进入选择结果，把本次演练连接到格式错误状态。
- 在错误位置写“请选择 JPG、PNG 或 PDF 凭证”，并提供重新选择入口；金额和事由仍显示在表单中。
- 连接“重新选择”到凭证已替换状态，显示文件名“交通费凭证.pdf”，允许移除或再次替换。
- 连接继续操作到确认页，同时展示 1,280 元、原事由和新文件名，让信息保留可以被逐项核对。
- 补上取消与返回：取消替换回到原草稿；从确认页返回编辑时，仍能看见刚才的凭证。
为这段路径写一句任务：“你已填好一笔交通费报销，请添加手中的凭证并继续核对。”评审者第一次选到不支持的文件后，观察他能否看懂原因、找到替换入口，并确认之前的信息没有丢失。不要先告诉他应该点哪个按钮。
用分支记录区分已连通和仍待决定
分支表不要只填“完成”。页面能跳转，不代表错误原因清楚；原因清楚，也不代表返回时保留了应保留的数据。可以按下面的字段记录每条分支：
- 分支编号与触发：B-02，选择不支持的 HEIC 凭证。
- 进入页面与去向：凭证待添加 → 格式不支持 → 凭证已替换 → 报销确认。
- 页面应说明：当前文件未被接受，允许哪些格式，在哪里重新选择。
- 保留与清除：保留金额、事由与此前有效凭证；不保留新选的无效文件。
- 返回规则：取消本次替换回原草稿，不清空整张表。
- 状态：已表达、部分缺失、待业务决定；附对应原型版本和负责人。
“部分缺失”要指出缺在哪里，比如“已连通错误页，但取消后的原凭证状态未明确”。这样的记录才可以变成修改任务。把相关规则写入原型交付标注，研发就不必从页面截图猜测保存和返回行为。
最容易被正常演示掩盖的三个缺口
返回正确页面，却回到错误状态
确认页的返回按钮跳回表单，看似没问题；但金额被重置、凭证丢失，用户仍无法继续。检查返回时应同时看页面、选中项、输入和滚动位置，不能只看页面名称。
空结果和请求失败共用同一提示
“没有找到凭证”与“凭证列表加载失败”不是同一个原因。前者应解释如何添加或调整查询，后者应提供恢复加载的动作。用相同空白插画掩盖差别，会让评审者判断错下一步。
按钮禁用，却没有说明还差什么
提交按钮变灰，不能单独解释“缺少凭证”“上传中”还是“没有提交权限”。把原因放在相关字段或操作附近，使员工无需猜测便能完成下一步。不要只靠颜色区分。
何时算把这段原型检查完整
另一位同事应能从约定入口出发，独立重走清单中的各条路径，理解每种结果，并核对返回后的信息。尚未决定的分支也应出现在清单中，有负责人和下一步，而不是藏在评论里。
如果时间有限，先用原型风险矩阵选出最值得检查的任务，再完成它的分支。先覆盖一次会让员工丢失整张报销单的错误恢复，比继续补十张只有正常数据的详情页更有决策价值。
