B端产品中工作流的交互设计
B端产品的设计中经常会出现工作流的身影，有的流程复杂有的流程简单。无论是简单还是复杂，它的概念都是一样的。工作流的概念定义的很复杂，更多是从技术层面出发，通俗点说就是根据一系列过程规则，将文档、信息、任务在不同的执行者之间进行传递与执行。
在开展交互设计之前我想说一说很多新手设计师都会踩的一个坑：做设计之前没有充分了解需求。需求的沟通是交互设计师非常重要的一个能力（千万不要以为交互设计师就是画画原型图，我做项目时也是最反感项目经理什么需求都不说清楚就让画原型图）。
需求和谁沟通？如果能接触到客户与客户沟通当然最好，当然更多时候我们是与项目经理或产品经理沟通，我们必须有透过现象看到本质的能力。需求沟通的话题太大在这里就不再赘述，后续有时间再单独聊一聊如何沟通需求。
我将以下面三个方面来阐述一下工作流中的交互设计该怎么做：
- 需求的确定与梳理。正如前面所说任何设计一定是建立在明确的需求之上的；
- 流程的梳理及信息架构的产出。流程的设计是交互设计中非常重要的部分，好的流程能够让用户更容易完成任务。这也是我本次分享着重要讲的部分；
- 原型的产出。简单讲述一下原型设计中要注意的问题。
一、需求的确定与梳理
在需求沟通的阶段有的客户（用户）相对专业能够很明确的阐述自己需要的功能，但是大多数客户（用户）只是能大概的讲一下自己需要什么东西。至于具体细节他是不清楚的，这个时候我们需要根据需求自己去整理通过与客户（用户）的沟通尽可能的去了解用户的使用场景，先设计一套方案然后和客户（用户）反复沟通直至确定最终的需求。
这里如果有条件的情况下尽量去做一个简单的用户调研，因为这样会了解更多的用户使用场景进而挖掘出用户的潜在需求。
通过沟通我们了解并最终确定了到客户的需求。
客户最开始提出的需求是这样的：
我们经过沟通交流进一步挖掘了一些潜在的需求，现在的需求是这样的：
刚开始客户的需求是申请人发起报销申请，然后经过部门经理、分管副总、总经理、财务的审批，在审批中发现问题，可以驳回，如果审批通过，财务进行打款，整个流程形成闭环。
我们在了解到需求后结合自己的分析提出了几个问题：
- 审批中被驳回的申请需要怎么处理；
- 如果申请人在提交申请后发现问题能否进行修改；
- 部门经理、分管副总、财务以及总经理是否也需要报销申请。
在和客户沟通后最终需求为：申请人发起申请、然后经过部门经理、分管副总、总经理、财务审批，审批通过后财务进行打款。被驳回的申请，申请人在修改后可以再次提交。如果申请人在提交申请后发现问题可以先进行撤回然后再修改并提交。部门经理、分管副总、财务、总经理有审批和发起申请两种权限，毕竟他们也需要进行报销。
经过沟通与梳理需求基本敲定了，当然这只是一个大的框架还有许多细节没有考虑进去，这就是我们后面进行流程设计的时候需要做的事情了
二、梳理信息架构及流程设计
经过前面的需求沟通与梳理现在我们已经对需要设计的财务报销系统有了一个大概的框架，接下来我们需要站在交互的角度去考虑并设计流程。前面为了让大家直观的了解需求我已经绘制了一个简单的流程了，现在我们需要在此基础上细化。
这个阶段比较重要，因为这个阶段的设计基本决定了我们的系统可用性和易用性，关乎用户体验，所以要花大量时间在这个阶段思考、打磨。
首先从需求出发梳理出一个大概的流程，前面谈需求的时候已经梳理过了，这里再贴出来：
这里有两个流程图，并不是说有两套流程，流程都是一样的，只不过是角色不同，后面再说。先看看我们梳理出的流程，功能点比较清晰，看上去似乎没有什么问题，那么我们需要更深入的去思考了，站在用户体验的角度去思考，这个时候我们就要带入一些使用场景了。
我们举两个比较通用的场景：
- 如果操作途中出现了异常情况（网络异常、服务器异常）；
- 用户在使用途中因个人行为被迫中断操作（尝试挖掘用户新的需求点）。
第一点的异常情况现在的流程中我们并没有考虑到，那这里我们就要去思考了，异常情况有哪些，其实异常情况有很多这里我们只考虑几种常见的情况：网络异常；服务器异常。
（1）网络异常
如果用户在提交申请的过程中网络出现异常该怎么处理。我们在输入了很多表单内容上传了一堆附件之后在提交的时候网络出现异常了。如果不对这个环节进行设计的话，用户辛苦输入半天的内容直接没有了，回头还得再次输入，这是一件很崩溃的事情。这个时候我们需要一些策略，对用户输入的内容进行缓存，即使用户碰到网络异常再返回的时候内容仍然在，这个体验就很赞了。
有的同学可能会觉得这个是技术层面的问题应该是开发去考虑的事情，这就大错特错了。除了少数有经验的开发会去考虑这个问题，大多数开发是不会考虑的或者说他们更多只会按照需求清单进行开发，你没提他可能也不会问。而恰恰这些地方就是体现一个系统易用性的重要细节。也是体现一个产品经理或者交互设计师设计能力的点。
（2）服务器异常
服务器异常同网络异常基本类似，最大区别是网络异常可能不在我们的控制范围之内而服务器异常却是我们不可推卸的责任。所以在这个时候我们除了要解决用户内容缓存问题还需要安抚用户的情绪，提出一个好的解决方案，比如告诉用户尝试刷新页面，或者判断是不是用户操作导致的问题并进行提示引导，而不是直接丢给用户一个404页面。
第二点用户在使用途中因个人行为被迫中断操作
这个其实是从用户使用场景出发去挖掘用户潜在的需求点。比如说用户正在录入报销内容，中途突然有重要电话过来了，或者临时有重要任务需要处理，而这个时候用户录入了很多内容了他并不想放弃已经输入的内容，这个时候该怎么办？
如果不去做这个环节的设计会不会影响系统的可用性，当然不会，我们的核心流程是没有问题的。
那会不会影响用户的情绪呢？
可能会，为什么是可能，因为一部分用户可能不在乎或者没有这个意识。那如果我们在这里设计一个草稿箱是不是就能解决用户这一痛点了呢，这对于提升用户体验很有帮助。
这些用户潜在的需求点，只能通过带入用户场景，切实站在用户易用性的角度去考虑问题你才能寻求突破。
再来说说角色问题
角色是工作流中最根本的一个环节，不同角色权限不同，流程也会有些差别。
前面提到过，这个报销系统主要分为三个角色：员工、领导（部门经理、分管副总、总经理）、财务。
员工只有发起报销申请的权限，领导有发起报销和审批报销单的权限。这里把部门经理、分管副总、总经理都划为一个角色，因为他们的权限是一致的只不过在流程的节点上有先后关系，财务的权限比较特殊，从级别划分上他不具备审批权。但是要行使审核权，就是检查报销信息和发票信息是否正确、属实，但是在权限上他与领导角色是一致的这个是要特别注意的。
不同权限角色在流程设计上也会不同，所以设计流程时必须搞清楚角色权限问题。前面我们针对员工角色和领导角色分别设计了不同的流程，财务角色的流程和领导角色的流程是一致的。
这个报销系统的设计是最基础的工作流形式了，权限相对清晰，在实际工作中由于需求和应用场景不同，往往会很复杂。在设计的时候需要明确把角色权限控制的规则告知开发。
通过进一步的考虑分析，现在流程设计这个环节基本就完成了（不一定全面，任何设计都要结合实际的需求和业务场景）。
接下来是梳理信息架构了，有了流程和角色的设计，产出信息架构相对来说就比较简单了，这里需要注意的是信息架构需要考虑的更细，有哪些角色不同角色分别对应什么页面，页面有哪些功能点都需要列出来
三、原型的产出
原型同样是一个很重要的环节，因为它是连接上下游、可视化的呈现系统设计的一个重要载体，并且是设计、开发、测试工作的重要依据。所以原型的设计不能马虎，必须面面俱到，把前面设计的流程和角色权限的规则体现出来，同时还要注意细节和流程的完整。
在前面梳理信息架构的时候实际上页面的设计在我们脑海中已经有了一个雏形，原型的绘制只不过是时间问题。当然这里也不排除在绘制原型的过程中发现一些信息架构设计上的问题，可能需要同步整理修改。我个人习惯在绘制原型前简单的画一个草稿，这样有利于梳理思路，发现问题时修改成本也会比较低。
转自：B端产品中工作流的交互设计