我们的UED设计流程及方法 2

所以，最后我们的第一版用户体验设计流程就是这样的：

这样的流程解决了我们之前的哪些问题呢？

首先，原型能够成为客户和项目经理之间的沟通媒介，极大地降低沟通成本；其次，美工获得了解放，从被动画图，转为通过原型真正的参与到了产品设计的流程中来；然后，程序员能通过原型知道自己要做出来的东西究竟是什么样的；最后，再通过提交完整的前端代码，把传统程序员的前端短板一并解决了，这个流程就似乎已经非常完美了。

那么实际情况呢？首先需要承认的是，这确实是一个飞跃。我们自己的网站项目都得以顺利的实现，不再有delay的情况，而客户的反馈也非常良好。但是当我们想以外包服务的方式将用户体验服务提供给客户的时候，就出现了问题。
首先的问题是，外包形式的用户体验服务，我们的服务对象从最终用户变成了外包服务购买者，这使得和有效用户进行沟通的成本上升了，在需求调研的时候，感觉难以对最终用户进行定位。
其次是，我们发现低保真原型和高保真原型极有可能变成内部的闭门造车活动，拿出一个完善的原型往往持续很长的时间，而客户的产品经理或者项目经理没有在设计途中参与进来，所以当拿出最终的高保真原型的时候，我们自己的设计师就变成了客户的产品经理。
最后的问题是，我们交付给程序员的前端代码太多，导致这样的朴素的心理问题出现：我是程序员，如果我拿到一份不是我写的代码，我就有很强的畏惧心理，不愿意去看。这样，实际的开发过程中，有很多前端的问题会压到我们团队头上，因为任何一个前端功能的开发，客户的程序员都可以说，前端代码不是我写的，我不会。

好吧，问题当然是不会结束，但我们还是选择解决问题。

关于难以对最终用户进行定位，我们在做需求分析的时候加入角色分析环节来帮助我们完成这个任务。在《设计沟通十器》这本书中，罗列了角色分析文档所需的各个要素，我们选择其中最重要的，用户基本信息、动机、场景、对应需要实现的产品功能来完成角色分析文档。这份文档帮助我们建立起了最终的用户模型，因此我们在做原型设计时，就有了最终用户的标准参照物。

其次，我们在设计原型时，尽量和客户一起设计，也即是用很高的迭代频率和客户交流，甚至时常驻点在客户那里进行设计，让客户随时了解到我们的原型长成什么样了。

然后，在原型设计阶段加入了可行性分析这一环节，提前将程序员拉入设计。和把客户拉入设计一样重要，需要程序员在早期就介入到对设计的评估，包括对后端数据以及前端逻辑实现难度的确认。这个环节确保在后期开发的时候，程序员能有所准备，杜绝了推卸责任的现象。

最后，我们拆分了前端代码开发部分，将前端开发工作改为提供两份文档，一份是视觉规范文档。这份文档详细的提供了视觉界面设计的规范，比如字体规范、是否自适应宽度，各种配色组合等等。另外一份就是开发指南，包括在可行性评估中得出的有难度的前端部分的示例代码，和相关的接口文档。这两份文档主要在于鼓励程序员真正介入前端开发。有问题也不要紧，我们会按项目的实际情况，为客户提供不同时间的现场技术支持。

这样，就得到了目前我们使用的流程：

那么，这样的流程实施的效果怎么样呢？我们来实际看一个例子。这个例子是给四方科技的一款网络优化平台提供用户体验设计服务。

首先是对产品进行商业目标需求调研，在了解到这款产品的基本商业目标定位后，我们便开始了用户角色分析。我们首先把产品的最终用户分为两类，一类是管理层，他们最大的愿望是，一眼掌握自己企业的网络使用情况，想知道自己为什么发封email都会这么慢。当他们一眼发现自己企业网络出现异常后，接着他们需要把优化网络的任务下派给一个下级，这个下级可能就是人事部经理或一个网管。他们的最大愿望是，确保公司网络的正常运行，完成老板下达的任务。