B端产品中工作流的交互设计

B端产品中工作流的交互设计

在开展交互设计之前我想说一说很多新手设计师都会踩的一个坑：做设计之前没有充分了解需求。需求的沟通是交互设计师非常重要的一个能力（千万不要以为交互设计师就是画画原型图，我做项目时也是最反感项目经理什么需求都不说清楚就让画原型图）。

需求和谁沟通？如果能接触到客户与客户沟通当然最好，当然更多时候我们是与项目经理或产品经理沟通，我们必须有透过现象看到本质的能力。需求沟通的话题太大在这里就不再赘述，后续有时间再单独聊一聊如何沟通需求。

我将以下面三个方面来阐述一下工作流中的交互设计该怎么做：

1.需求的确定与梳理。正如前面所说任何设计一定是建立在明确的需求之上的；

2.流程的梳理及信息架构的产出。流程的设计是交互设计中非常重要的部分，好的流

程能够让用户更容易完成任务。这也是我本次分享着重要讲的部分；

3.原型的产出。简单讲述一下原型设计中要注意的问题。

一、需求的确定与梳理

在需求沟通的阶段有的客户（用户）相对专业能够很明确的阐述自己需要的功能，但是大多数客户（用户）只是能大概的讲一下自己需要什么东西。至于具体细节他是不清楚的，这个时候我们需要根据需求自己去整理通过与客户（用户）的沟

通尽可能的去了解用户的使用场景，先设计一套方案然后和客户（用户）反复沟通直至确定最终的需求。

这里如果有条件的情况下尽量去做一个简单的用户调研，因为这样会了解更多的用户使用场景进而挖掘出用户的潜在需求。

通过沟通我们了解并最终确定了到客户的需求。

客户最开始提出的需求是这样的：

我们经过沟通交流进一步挖掘了一些潜在的需求，现在的需求是这样的：

刚开始客户的需求是申请人发起报销申请，然后经过部门经理、分管副总、总经理、财务的审批，在审批中发现问题，可以驳回，如果审批通过，财务进行打款，整个流程形成闭环。

我们在了解到需求后结合自己的分析提出了几个问题：

1.审批中被驳回的申请需要怎么处理；

2.如果申请人在提交申请后发现问题能否进行修改；

3.部门经理、分管副总、财务以及总经理是否也需要报销申请。

在和客户沟通后最终需求为：申请人发起申请、然后经过部门经理、分管副总、总经理、财务审批，审批通过后财务进行打款。被驳回的申请，申请人在修改后可以再次提交。如果申请人在提交申请后发现问题可以先进行撤回然后再修改并提交。部门经理、分管副总、财务、总经理有审批和发起申请两种权限，毕竟他们也需要进行报销。

经过沟通与梳理需求基本敲定了，当然这只是一个大的框架还有许多细节没有考虑进去，这就是我们后面进行流程设计的时候需要做的事情了

二、梳理信息架构及流程设计

经过前面的需求沟通与梳理现在我们已经对需要设计的财务报销系统有了一个大概的框架，接下来我们需要站在交互的角度去考虑并设计流程。前面为了让大家直观的了解需求我已经绘制了一个简单的流程了，现在我们需要在此基础上细化。

这个阶段比较重要，因为这个阶段的设计基本决定了我们的系统可用性和易用性，关乎用户体验，所以要花大量时间在这个阶段思考、打磨。

首先从需求出发梳理出一个大概的流程，前面谈需求的时候已经梳理过了，这里再贴出来：

这里有两个流程图，并不是说有两套流程，流程都是一样的，只不过是角色不同，后面再说。先看看我们梳理出的流程，功能点比较清晰，看上去似乎没有什么问题，那么我们需要更深入的去思考了，站在用户体验的角度去思考，这个时候我们就要带入一些使用场景了。

我们举两个比较通用的场景：

1.如果操作途中出现了异常情况（网络异常、服务器异常）；

2.用户在使用途中因个人行为被迫中断操作（尝试挖掘用户新的需求点）。

第一点的异常情况现在的流程中我们并没有考虑到，那这里我们就要去思考了，异常情况有哪些，其实异常情况有很多这里我们只考虑几种常见的情况：网络异常；服务器异常。

（1）网络异常

如果用户在提交申请的过程中网络出现异常该怎么处理。我们在输入了很多表单内容上传了一堆附件之后在提交的时候网络出现异常了。如果不对这个环节进行设计的话，用户辛苦输入半天的内容直接没有了，回头还得再次输入，这是一件很崩溃的事情。这个时候我们需要一些策略，对用户输入的内容进行缓存，即使用户碰到网络异常再返回的时候内容仍然在，这个体验就很赞了。

有的同学可能会觉得这个是技术层面的问题应该是开发去考虑的事情，这就大错特错了。除了少数有经验的开发会去考虑这个问题，大多数开发是不会考虑的或者说他们更多只会按照需求清单进行开发，你没提他可能也不会问。而恰恰这些地方就是体现一个系统易用性的重要细节。也是体现一个产品经理或者交互设计师设计能力的点。

（2）服务器异常

服务器异常同网络异常基本类似，最大区别是网络异常可能不在我们的控制范围之内而服务器异常却是我们不可推卸的责任。所以在这个时候我们除了要解决用户内容缓存问题还需要安抚用户的情绪，提出一个好的解决方案，比如告诉用户

尝试刷新页面，或者判断是不是用户操作导致的问题并进行提示引导，而不是直接丢给用户一个404页面。

第二点用户在使用途中因个人行为被迫中断操作

这个其实是从用户使用场景出发去挖掘用户潜在的需求点。比如说用户正在录入报销内容，中途突然有重要电话过来了，或者临时有重要任务需要处理，而这个时候用户录入了很多内容了他并不想放弃已经输入的内容，这个时候该怎么办？

如果不去做这个环节的设计会不会影响系统的可用性，当然不会，我们的核心流程是没有问题的。

那会不会影响用户的情绪呢？

可能会，为什么是可能，因为一部分用户可能不在乎或者没有这个意识。那如果我们在这里设计一个草稿箱是不是就能解决用户这一痛点了呢，这对于提升用户体验很有帮助。

这些用户潜在的需求点，只能通过带入用户场景，切实站在用户易用性的角度去考虑问题你才能寻求突破。

再来说说角色问题

角色是工作流中最根本的一个环节，不同角色权限不同，流程也会有些差别。