Se Connecter Maintenant 干过B端产品设计的人，大概率都被工作流折磨过。有的流程简单得像一条直线，点几下鼠标就结束了；有的则像一团乱麻，分支条件绕来绕去，看着就头皮发紧。但不管外表是繁是简，工作流的内核从来没有变过——它本质上是一套规则，规定文档、信息、任务怎么在不同的人、不同的角色之间流转、执行和传递。概念上，技术文档可以给出一堆严谨的定义，可一旦落到实际的产品里，我们真正关心的其实就一件事：怎么让用户走得更顺，不容易出错，少骂两句。
下面就拿一个财务报销系统来聊聊工作流里的交互设计。不扯虚的，只讲从接到需求到输出原型这一路上的真实思考。
说到这里，我想先聊一个新手设计师特别容易掉进去的坑——拿到需求就急着画图。交互设计远不止出原型图，前提是你对需求的理解到底有多深。我当年做项目的时候，最怕项目经理甩过来一句“需求文档写得挺清楚的，你照着画就行”，那种感觉就像让你去盲人摸象。真正该做的是，逮着谁就跟谁聊。能直接跟客户聊当然最好，但现实中更多时候只能跟项目经理、产品经理对话。这时候，你得有点“透过现象看本质”的本事，既听懂对方在说什么，更要听懂对方没说出来的话是什么。需求沟通这件事太大了，今天先不展开，以后有机会再单独聊。
回到报销系统，我把它拆成三个部分来揉碎了说：需求梳理、流程与信息架构、原型输出。
搞清楚到底要什么
需求沟通阶段，最理想的情况是客户逻辑清晰，能一二三四地讲清楚功能点。但十次里有八次，你遇到的客户只会给你一个大概轮廓：“我们想做一个报销系统，员工提交申请，领导审批，财务打钱。”至于细节，他没想过，可能也说不清楚。
这种时候，你不能等着别人来喂，得自己动手去梳理。先根据有限的描述，拼出一个初步方案，再拿回去跟客户反复磨。条件允许的话，哪怕做一个非常简单的用户调研，哪怕只是找几个目标用户聊一聊他们日常报销是怎么做的，都会让你更贴近真实的使用场景，挖出一些连用户自己都没意识到的潜在需求。
就拿这个报销系统来说，客户最初提出的需求很简单：员工发起报销，然后部门经理批，副总经理批，总经理批，最后财务批。审批有问题就驳回，通过了就付款，形成一个闭环。
够清晰吗？表面上够清晰。但结合我们自己的分析，马上就会冒出几个问题：被驳回的申请怎么办？申请人提交完发现填错了能改吗？那些经理、副总自己要不要报销？他们该有什么权限？
跟客户一深聊，需求就丰满起来了：被驳回的申请，允许申请人修改后重新提交；提交后发现问题，可以撤回修改；各级领导除了审批，自己也得能发起报销申请。这样，一个大框架才算真正立住。当然，细节还远没有穷尽，那些都是下一步做流程设计时要啃的硬骨头。
流程是骨架，得把肉填实在
需求和框架有了，接下来就要从交互的角度把流程具体化。这个阶段至关重要，它直接决定了系统到底好不好用、用起来顺不顺。我习惯先画一个最简版的流程图，让人一眼能看懂业务走向，然后在这个基础上反复琢磨、细化。
最初梳理出来的流程，功能点看着挺清楚，没什么问题。但推导到这一步，如果就此打住，设计也就流于表面了。你得把自己扔进用户的使用场景里，代入真实的操作瞬间，去捕捉那些“意外时刻”。
我举两个最常见的场景。
一是操作中遇到异常。可能是网络问题，也可能是服务器崩溃。很多新手设计师会忽略这个环节，觉得“这是技术该考虑的”。但恰恰是这些地方，最能体现交互设计的价值。
比如，员工吭哧吭哧填了一大堆表单，上传了十几张发票扫描件，点提交的那一刻，网络断了。如果没有做任何设计，页面一刷新，所有输入灰飞烟灭，那种崩溃感足以让用户下次再也不想用这个系统。这时候，一个简单的本地缓存策略就能救命。哪怕网络异常，返回后内容还在，体验上的这点差别，就是专业和业余的分界线。别指望开发会主动想到这个，大多数时候，开发按照需求清单来，你没提，他大概率不会做。
服务器异常也是同理。除了内容缓存，还得考虑用户情绪。干巴巴地扔给用户一个“404”或“服务器错误”页面，只会加剧焦虑。更好的做法是给出明确的提示和解决方案，比如“当前访问人数较多，请稍后刷新页面再试”，或者针对用户接下来可能的操作给出引导，而不是让用户感觉自己被困住了。
二是个人行为导致的操作中断。这也是从真实场景里挖出来的一个点。用户正在填报销单，突然来了个紧急电话，或者被领导叫去处理临时任务，屏幕上已经填到一半的内容怎么办？他肯定不想放弃，又没法一直守着页面。
从核心流程上看，这个设计缺失并不影响业务跑通，或者说，系统的可用性没有问题。但它会影响用户的情绪，更会在无形中降低用户对系统的信任感。如果我们在这里加一个“草稿箱”功能，是不是就能完美解决这个痛点？用户可以随时存草稿，随时回来接着填，那种安心感，对提升整体体验的帮助是实打实的。这些潜在需求，只有把自己代入用户场景，站在易用性的角度去琢磨，才能触达。
再来说说角色。
工作流更本质的东西，是角色与权限。报销系统里，员工、领导（部门经理、副总、总经理）、财务，三个角色，权限泾渭分明。
员工只有发起报销的权限。领导角色，既有审批权，也有发起报销权。虽然部门经理、副总、总经理在审批节点上有先后，但他们的权限结构是一致的，可以归为一类角色。财务则比较特殊，他没有审批权，而是审核权，需要核对报销信息和发票的真实性、合规性。在权限设计上，要注意让他与领导角色的某些操作界面保持一致，避免割裂感。
权限不同，流程设计自然不同。这个报销系统的权限相对清晰，是工作流最基本的一种形态。但实际工作中，因为业务场景不同，权限控制往往要复杂得多，设计时必须把规则明确到每一个角色、每一个节点上。
经过这一轮思考和推演，流程设计才算基本完成。当然，不可能穷尽所有情况，但大脉络和关键细节抓住了。接着梳理信息架构就会顺很多——哪个角色对应哪些页面，页面里需要承载哪些功能点，一一列出来，清晰明了。
原型是语言，得画得精准
原型是连接上下游的桥梁，也是设计思想的可视化载体。开发、测试、设计评审，全都得靠它。所以原型稿不能粗心，必须事无巨细，把前面推演出来的流程规则、角色权限，都体现在页面和交互说明里。
其实，在梳理信息架构的时候，脑子里就已经对页面长什么样有了雏形，画原型更多是花时间把它落地。但画的过程中，也可能会发现一些信息架构阶段没考虑到的问题，这时候就得回头去调整，修改的成本也比后面开发阶段再改要低得多。
我个人的习惯是，在正式画原型之前，先用手绘草稿纸笔勾勒一下。这样做的好处是，思路能快速梳理一遍，试错成本极低，哪里不合理，橡皮一擦就能重来。
以上，算是我自己对工作流里交互设计的一点理解和心得。它不是什么行业标准，只是个人实践中的一些总结。如果对你有帮助，那最好；如果有不同看法，也欢迎一起交流。设计这件事，越辩越明。