B 端产品中，工作流设计几乎是无法回避的核心命题。无论是复杂的审批链条，还是简单的任务流转，其本质都是文档、信息与任务依据既定规则，在不同执行者之间传递与执行的过程。然而，许多设计师在面对工作流时，容易陷入“重原型、轻逻辑”的误区，往往在未完全吃透需求的情况下便急于绘制界面，导致后续开发反复返工。

交互设计的价值，不仅仅在于页面的美观，更在于通过逻辑梳理降低用户的认知成本，确保业务闭环的顺畅。基于财务报销这一典型场景，我们可以从需求梳理、流程架构、原型落地三个维度，探讨如何构建高可用性的工作流交互方案。



一、需求梳理：从“表面诉求”到“潜在场景”

需求沟通是交互设计的基石。在实际项目中，客户或业务方往往只能描述大致功能，难以穷尽细节。例如，最初的报销需求可能仅被描述为：“申请人提交，各级领导审批，财务打款，驳回则结束。”

若仅据此设计，系统将极其脆弱。设计师需要通过追问与场景模拟，挖掘潜在需求。例如：
1. 驳回后的路径： 申请被驳回后，是直接作废，还是允许修改后重新提交？
2. 提交后的修正： 申请人提交后发现填错，在审批完成前是否允许撤回？
3. 角色的双重性： 部门经理、总经理既是审批人，也是潜在的申请人，他们自己报销时流程如何走？

经过深入沟通，需求应从单向线性流程进化为具备闭环能力的模型：支持驳回修改再提交、支持提交后撤回、明确各级领导兼具申请与审批双重权限。只有将这些隐性需求显性化，设计框架才具备落地的可行性。

二、流程架构：异常处理与权限逻辑

当基本需求明确后，交互设计的核心转向流程架构的细化。这一步直接决定了系统的易用性与健壮性。除了正常的“快乐路径”，设计师必须重点考量异常场景与角色权限。

1. 异常场景的兜底设计
很多设计稿只关注流程通畅，却忽略了现实中的不确定性。
* 网络与服务异常： 用户在填写大量表单并上传附件后，若提交时遭遇网络波动或服务器错误，直接报错会导致数据丢失，体验极差。交互上应设计本地缓存机制，确保用户刷新或返回后，已填内容依然保留。对于服务器异常，不应只展示冷冰冰的 404 页面，而应提供友好的引导，如“尝试刷新”或“联系管理员”，安抚用户情绪。
* 操作中断保护： 用户可能在填写过程中因突发事务被迫中断。若系统不支持暂存，用户只能放弃已填内容。增加“草稿箱”功能，虽非核心业务闭环，却能极大提升用户体验，解决“输入了一半不想丢”的痛点。

2. 角色与权限的精细化
工作流中，角色是权限控制的基石。在报销系统中，看似简单的“员工、领导、财务”三角关系，实则蕴含复杂逻辑。
* 权限互斥与兼容： 领导角色通常拥有“审批”与“申请”双重权限。设计时需明确，当领导作为申请人时，其流程节点与普通员工一致；当作为审批人时，则进入审批视图。
* 财务的特殊性： 财务角色通常拥有审核权（核对发票真实性），但未必拥有业务审批权。在流程设计上，需明确财务节点是并行审核还是串行审批，避免权限混淆导致流程卡死。

通过梳理这些信息架构，明确各角色对应的页面功能与数据权限，才能为后续设计打下坚实基础。



三、原型落地：逻辑的可视化呈现

原型是连接设计、开发与测试的桥梁。在信息架构清晰的前提下，原型绘制不再是简单的页面堆砌，而是逻辑的可视化验证。



建议在绘制高保真原型前，先通过草图梳理页面跳转与状态变化。原型中必须涵盖所有流程分支，包括正常提交、驳回修改、撤回重试、异常提示等状态。特别是在权限控制上，需通过标注明确不同角色看到的界面差异。例如，同一张报销单，申请人看到的是“编辑/撤回”按钮，审批人看到的是“同意/拒绝”按钮，财务看到的是“核验/打款”选项。

此外，原型设计是一个动态修正的过程。在绘制过程中，可能会发现信息架构中的遗漏，此时应同步更新文档，确保设计与逻辑的一致性。

结语

B 端工作流的交互设计，本质上是对业务逻辑的翻译与优化。它要求设计师跳出“画图”的思维定势，深入理解业务场景，预判异常流程，并妥善处理复杂的权限关系。一个优秀的工作流设计，不仅能让用户顺畅完成任务，更能在异常发生时提供安全感与引导。这并非行业标准的教条，而是基于实践的经验总结，旨在为复杂系统的设计提供一份可参考的思路。