UED设计流程及方法.docx

UED设计流程及方法.docx

《UED设计流程及方法.docx》由会员分享，可在线阅读，更多相关《UED设计流程及方法.docx（9页珍藏版）》请在冰豆网上搜索。

UED设计流程及方法

UED设计流程及方法

“用户体验设计”无疑是这两年互联网行业最炙手可热的话题，而从我们成都UCD书友会火爆的现场来看，也的确如此。

那么“用户体验设计”为什么会如此火爆呢?

这需要从互联网的Web2.0革命说起。

　　这场革命，代表了互联网应用关注焦点的变迁，从以内容为王的门户型网站时代，转变为以用户为中心的互联网服务时代。

以用户为中心的互联网服务，自然就需要以用户为中心的设计。

但是要做到真正的以用户为中心的设计却并不简单。

　　这是什么意思呢?

我想用彩程的实际经历对这个问题做出解释。

和很多其它软件企业一样，彩程也是从一些中小型的企业网站、电子商务网站开发业务启程的。

当时我们开发一个电子商务类网站的流程是什么样的呢?

　　首先会由超级打杂老妖出马，跟客户沟通，套出用户的需求，然后由费西或是老妖自己，三下五除二的搞一个首页出来，拿去给用户确认，用户如果点头，那么ok，开始做首页的html切图，然后丢给程序员开始开发，同时，美工继续孤军深入，出各种特征内页，切html，交给程序员开发，如此循环往复。

而一旦整个项目开始进行，客户就很少再参与其中了。

　　于是，这个项目持续运行，直到某一天，程序员说：

“好了”，这样，老妖满怀希望的冲到客户那里，很想听到客户对网站认可，但实际的场景往往是：

　　客户抱怨说，这里我明明是想要个Flash广告，但是却只有一张图片;这个订单系统怎么不好用，为什么不参考淘宝来做呢?

我还想要个会员系统，每个会员有自己的个人页面。

　　这个时候，可怜的老妖只能作出两种选择，要么照单全收，ok，哪里有问题我给你改哪里，要么就是耍死皮，但是后面一种情况一般不会出现，因为老妖不愿因为得罪客户而丢掉奶粉钱。

所以，这个原本大家都认为很简单的网站项目就这样被delay下去了。

　　这样的情况出现的次数多了，让公司首脑小s同学很不满意，于是他开始召集大家思考，这是为什么呢?

让我们来看看之前我们的流程:

　　经过对这个流程的几个痛苦的日夜思索之后，我们发现了如下几个凄惨的现实：

　　1.用户其实并不知道他到底需要什么，就算用户知道，你也别想知道他究竟知道什么;

　　2.美工都以为自己只是画画的，而无需去考虑整个产品的设计思想，包括用户角色是什么，商业定位是什么，所以你说你想要个新闻栏目，ok，我照着163画一下就了事了;

　　3.程序员都是脑残，只关注用什么设计模式或是用什么框架，美工的设计图对他们来说不值一提，不就是一个for循环生成li标签而已嘛;

　　4.客户始终置身世外，他给钱了，只想你干好活，最后一手交钱一手交货罢了，但最关键的是，“货”这个东西，大家除了在最后一霎那能看到它的模样，其它大部分时间它都异常神秘。

　　很多时候，最大的问题往往在于我们不愿意去面对问题。

所以当我们能把问题找到，并敢于面对问题的时候，解决办法的出现就只是时间而已了。

这个解决办法，当时我们认为最优的，就是强化设计，最后发现，其实就是引入了“用户体验设计”。

　　从何入手呢?

我们都知道，一般的软件开发流程中，PM会根据用户需求出产品需求分析报告，然后美工介入，出一些视觉界面，然后程序员根据有限的设计图连蒙带猜的进行实际开发。

但在这样的模式下，产品会出现几次偏离。

　　PM只有几十页的文档，而这样的文档传递实际需求的效果极差，不能让用户确认需求，于是出现整个流程中的第一次产品与需求的偏离。

美工在做视觉设计的时候，就可能按照他自己的想法天马行空，最后出现整个流程中的第二次产品与需求的偏离。

程序员在拿到美工有限的设计图后，大概想了想，觉得自己明白了，然后就开始写代码，但是由于没有完整的产品模型到程序结构的映射，最终导致第三次产品与需求的偏离。

这样带来的致命后果就是：

用户明明想要个美女，但是最终实际交付的却是个如花。

　　这样的流程最大的问题在于，缺少一个能够聚焦各方的核心，几十页的文档无法胜任，而原型却可以。

　　我们认为原型会很重要，于是我们首先引入了原型设计。

在这个设计过程中，我们使用Axure作为辅助工具，它的好处在于，能让任何一个PM很容易的上手，并能把需求书中几十页的文字落地为实际的界面。

　　在PM快速完成原型设计之后，PM会带着原型去和客户讨论，客户由于能有实际的使用感受，所以能够很快的分辨出设计与他需求之间的偏差，然后PM根据用户的反馈修正原型。

　　接着，美工上场了，注意，这个时候，美工不再是美工，他有了新的title—视觉设计师。

有什么新的要求呢?

他需要仔细的去评估原型，从设计师的角度出发，对原型提出意见。

接着，才是用PS将界面画出来，然后根据设计图制作另外一份原型—高保真原型。

　　高保真原型和之前的原型—也就是低保真原型–的差别在于，低保真原型着重完成信息元素的组织以及概念模型的搭建，目标定位在为产品搭框架，填充素材。

但是高保真原型会完成对框架的装修以及对素材的组织。

这样得到的高保真原型和实际交付的产物就几乎是100%趋近的了。

　　然后，产品经理会带着这份珍贵的礼物再次走访客户，根据客户的使用反馈做最后的原型调整，至此，整个原型设计阶段结束。

　　接下来，根据高保真原型，我们给出了整个原型的HTML代码，包括规范的CSS样式表以及JS接口，都由我们的前端工程师定义并实现。

　　最后，我们交到产品实施人员手里的就有两样东西，一是高保真原型，一是HTML框架代码。

我们希望高保真原型能真实反应用户需求，并且让实施者知道开发出来的东西是一个什么样子的。

其次，通过提交高质量的html代码，减少普通程序员的工作量，因为不可否认的是，如今复杂的前端技术不是一个普通的java程序员能短时间掌握得了的。

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

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

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

　　那么实际情况呢?

首先需要承认的是，这确实是一个飞跃。

我们自己的网站项目都得以顺利的实现，不再有delay的情况，而客户的反馈也非常良好。

但是当我们想以外包服务的方式将用户体验服务提供给客户的时候，就出现了问题。

　　首先的问题是，外包形式的用户体验服务，我们的服务对象从最终用户变成了外包服务购买者，这使得和有效用户进行沟通的成本上升了，在需求调研的时候，感觉难以对最终用户进行定位。

　　其次是，我们发现低保真原型和高保真原型极有可能变成内部的闭门造车活动，拿出一个完善的原型往往持续很长的时间，而客户的产品经理或者项目经理没有在设计途中参与进来，所以当拿出最终的高保真原型的时候，我们自己的设计师就变成了客户的产品经理。

　　最后的问题是，我们交付给程序员的前端代码太多，导致这样的朴素的心理问题出现：

我是程序员，如果我拿到一份不是我写的代码，我就有很强的畏惧心理，不愿意去看。

这样，实际的开发过程中，有很多前端的问题会压到我们团队头上，因为任何一个前端功能的开发，客户的程序员都可以说，前端代码不是我写的，我不会。

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

　　关于难以对最终用户进行定位，我们在做需求分析的时候加入角色分析环节来帮助我们完成这个任务。

在《设计沟通十器》这本书中，罗列了角色分析文档所需的各个要素，我们选择其中最重要的，用户基本信息、动机、场景、对应需要实现的产品功能来完成角色分析文档。

这份文档帮助我们建立起了最终的用户模型，因此我们在做原型设计时，就有了最终用户的标准参照物。

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

　　然后，在原型设计阶段加入了可行性分析这一环节，提前将程序员拉入设计。

和把客户拉入设计一样重要，需要程序员在早期就介入到对设计的评估，包括对后端数据以及前端逻辑实现难度的确认。

这个环节确保在后期开发的时候，程序员能有所准备，杜绝了推卸责任的现象。

　　最后，我们拆分了前端代码开发部分，将前端开发工作改为提供两份文档，一份是视觉规范文档。

这份文档详细的提供了视觉界面设计的规范，比如字体规范、是否自适应宽度，各种配色组合等等。

另外一份就是开发指南，包括在可行性评估中得出的有难度的前端部分的示例代码，和相关的接口文档。

这两份文档主要在于鼓励程序员真正介入前端开发。

有问题也不要紧，我们会按项目的实际情况，为客户提供不同时间的现场技术支持。

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

　　彩程UED流程图

　　那么，这样的流程实施的效果怎么样呢?

我们来实际看一个例子。

这个例子是给四方科技的一款网络优化平台提供用户体验设计服务。

　　首先是对产品进行商业目标需求调研，在了解到这款产品的基本商业目标定位后，我们便开始了用户角色分析。

我们首先把产品的最终用户分为两类，一类是管理层，他们最大的愿望是，一眼掌握自己企业的网络使用情况，想知道自己为什么发封email都会这么慢。

当他们一眼发现自己企业网络出现异常后，接着他们需要把优化网络的任务下派给一个下级，这个下级可能就是人事部经理或一个网管。

他们的最大愿望是，确保公司网络的正常运行，完成老板下达的任务。

　　角色分析

　　有了这样一份角色分析文档，接着我们的低保真原型设计就会围绕角色的动机和场景来进行。

下面我们来看看首页设计：

　　低保真原型

　　可以从这个流量监控的首页看出，如果我是老板，很容易掌握的几个信息是：

今天公司网络的整体流量情况，现在哪个员工的流量最高，是否正常。

有了这几个信息，我就大概知道我自己发邮件，之所以慢，是不是由于内部网络原因引起的。

如果是，这时候我就会抄起电话打给人事部经理或是网管，让他给我解决问题了。

　　人事部经理得到这个任务后，就会通过平台的流量实时监控页面，找出究竟是哪部分的流量出现了问题。

然后在上网控制页面，修改对应的网络策略即可。

　　围绕角色文档的低保真设计之后，我们的视觉设计师会基于低保真原型出视觉设计图，并将其作为素材制作高保真原型。

最终的高保真原型就是这样的：

　　高保真原型

　　高保真原型结束后，紧接着是两份文档的编写，一是这样的一份视觉规范文档，我们看到这份文档中包含了页面布局定义、字体的字号以及颜色、所有控件的颜色定义等。

　　接下来是一份开发指南文档，其中给出了一些复杂控件的前端代码实现参考，供程序员在实际开发时使用。

　　最后，我们在用户现场完成了4个工作日的现场技术支持服务，解决了一些html框架搭建，切图等前端技术问题。

　　这就是我们的用户体验设计流程以及方法。

它并不是完善的，甚至可能全盘错误，比如在如何为用户提供更好的前端开发的帮助方面，我们还在进行各种尝试。

没有不变的流程，只有不断探索。

　　最后，我想回归到“用户体验设计”本身。

用户体验设计的出现，只是代表传统软件行业在互联网时代开放、共享、自由的氛围中的一种进化需要，而它最终会和整个软件产品的研发流程融为一体，成为无论是从需求分析、到界面设计再到开发到运维的一部分，因为我们随时都需要将用户置入服务的核心，用我们的爱来浇注产品本身。