审批被退回时，首屏应先告诉用户退回原因和下一步，而不是只显示红色状态。以报销单为例，退回卡片写明“发票抬头与申请主体不一致”，提供“修改并重新提交”，同时保留金额、费用明细和附件。用交互原型制作与评审的方法串起这些状态，可以在评审时快速确认用户会不会迷路。
退回原因要和动作绑定
原因至少包括提出者、时间、对应字段和解决建议。泛泛的“资料有误”不能指导修正；如果问题在发票抬头，就让用户从原因跳到该字段。多个问题按处理顺序列出，修改后可逐项标记已处理，但不要让用户误以为勾选等于审批通过。
| 状态 | 用户看到的重点 | 主要动作 |
|---|---|---|
| 待审批 | 当前审批人和提交时间 | 查看详情、撤回（若规则允许） |
| 退回修改 | 原因、关联字段、退回人 | 编辑问题字段并保存 |
| 再次提交 | 本次修改摘要与影响范围 | 确认后提交，不重复创建单据 |
先定义本系统的退回、驳回和撤回。“退回”允许申请人在原单上修改并重提；“驳回”表示本次申请已经结束；“撤回”由申请人主动停止待审单。若产品采用其他含义，文案也要随规则调整，不能把三个名称当作可互换的红色标签。
报销单 BX-104 的申请金额为 680 元，审批人要求补充发票抬头。退回卡片应显示问题字段和备注，而不要求用户猜是金额、发票还是收款信息不合格。如果审批人同时要求修改两张附件，就把两项逐一列出，并让点击落到相应附件。
保留资料，标出可编辑范围
退回后不应清空全部表单。不可修改的编号、历史审批意见和已核验附件保持只读；需要补充的字段显示编辑态，并在字段旁解释为什么需要修改。若金额变化会触发新的审批路径，提交前明确提示，而不是在提交后才报错。
这次只修改发票时，680 元的金额不应自动清空；如果申请人把金额改为 980 元，则可能影响审批人或审批层级。确认区应提示“金额由 680 元改为 980 元，需重新送审”，并展示将走的路径。是否保留先前审批结论由业务规则决定，设计稿中要明确是哪一段失效，不能假设一律从头或一律继承。
附件替换也需要版本关系：旧附件留在历史记录中供有权限的人查看，新附件在当前表单中展示。不要让历史审批意见指向已经被覆盖掉的文件。当前单据编号保持不变，修订批次可以编号为第 2 次提交，让查询和沟通有稳定对象。
重提前给一次可核对的摘要
重新提交确认页列出本次改动、仍待补充的项目和将要通知的审批人。用户确认后再改变状态，网络异常时显示“提交结果未知”，提供查看记录和安全重试，避免连续点击生成两条申请。
一份简洁的确认摘要可以写成：“将重新提交 BX-104。发票 A 已替换；金额仍为 680 元；提交后由直属主管审批。”这比“确认操作？”更具体。GOV.UK 的摘要列表适合把字段和值配对呈现；每个修改入口还要能识别它针对哪个字段，避免多个相同的“修改”失去语境。
审批人在申请人编辑期间新增意见时，别直接覆盖申请人的表单。先说明已有新记录，保留本地输入，让用户看完再提交。若权限被撤销，则保留可复制的修改内容并解释联系对象，不留下永远转圈的按钮。
历史记录要能回答“谁在何时做了什么”
时间线按状态变化记录提交、退回、保存和再次提交。每项用明确动词开头，关联字段变更可展开查看。把评论与最终决定分开，避免一条聊天消息被误认为审批结论。
时间线可依次写“10:05 林主管退回：发票抬头不符”“10:18 申请人保存修改：替换发票 A”“10:23 申请人再次提交：第 2 次”。保存草稿不对审批人产生待办，重新提交才触发下一环节；两者在名称和图标上应能区分。历史展开后显示当时的内容快照，而不是把所有事件都链接到最新表单。
把 BX-104 的三次状态放在同一份 Pixso 文件中，审批人看原因是否明确，申请人走完修改与重提，研发核对字段和附件的保留关系。最终交付的是一条能继续办理的流程，而不是一张红色退回提示。
