WEB2.0时代的UE设计过程 .

 

WEB2.0的时代灿烂辉煌，这场信息技术的浪潮改变了互联网的应用模式。如今，基础网络设施的发展和无线网络技术的崛起，让电商，SNS，微博，移动应用，云技术等领域有了大展身手的舞台，新技术、新产品、新创意层出不穷。

用户在互联网上可以选择的产品越来越多了，但是，产品的平均生命周期却大大的缩短了。这是因为：其一，应用做的好的一些大鳄公司开始转变思路，开放自己的平台，让更多合作伙伴接入进来，以此降低第三方应用研发的门槛和成本；其二，好产品更多体现在开创式的新点子，而其往往在初始阶段不需要投入太多的资金和人力，也为一些互联网创业者提供了机会。当互联网上的产品数量剧增后，这无疑增加了用户的学习成本，一些体验做的差的，内容做的单薄的产品，很快就失去了用户的信任。有人说：现在用户在选择互联网产品时不再羞涩，直接用鼠标就决定了。

其实，从广义上来看，不管是互联网产品还是行业应用软件产品，没有良好的用户体验作为支撑，迟早都将面临惨淡的收场。从当下很多IT企业开始注重培养和引进交互体验设计师就能看出，业界越来越看重用户体验的设计，往往在酝酿新产品之前就会将用户体验设计引入进来，早早的去筹划和投入。

那么什么是用户体验？谈到用户体验不得不提到的一个人，AJAX之父Jesse James Garrett。他早在本世纪初就开创性的诠释了以用户为中心的设计方法(UCD) ，并提出了著名的五层体验要素模型。他强调在进行系统设计时，提供优质的用户体验是一种重要的、可持续的竞争优势，往往决定产品的市场走向。

随着Garrett的五层模型影响力逐步扩大，越来越多的人开始学习和发扬这套思想，目前已经成为全面引领业界的最重要UE设计理论基础。下面的图即是著名的用户体验要素模

型：

在Garrett的基础上，我做了进一步的解释，以用户为中心的APP设计和5层要素为基础，将每个层次的行为与软件工程的过程结合起来，去探讨如何在模型的指导下，完成系统的UE设计。

如下图所示，我对应五个层次分别做了解释，结合软件工程的知识逐步进行分解，并逐一识别了每个层次的核心工作成果。

从战略层、范围层、结构层、框架层到表现层，是抽象趋于具体的过程，是从概念到模型，从模型到实例的过程；反过来说，从表现层到战略层是一种联动的效应，上层的变动必定是依据下一层的某些变化而产生的。

每个层次都有一些特定的元素和特征属性。战略层核心内容是用户需求和产品目标；范围层是功能规格和内容需求；结构层是交互设计和信息架构，这也五层中相对关键的一层；框架层核心内容是界面设计、导航设计和信息设计；表现层核心内容是视觉设计。

 

Ø  战略层（Strategy）-构建业务模型

战略层意义在于：弄清楚投资者和用户分别想从系统得到些什么。

要弄清楚用户和经营者的需要，作为产品的设计者首先是要准确的获得这些需求，例如获得经营者对产品提出的系统目标、业务目标、价值目标和成功标准等。一些复杂、大型跨内部或外部组织机构的产品还需要弄清楚干系人的组织结构、业务流程、规章制度、岗位职责等。如果是面向互联网用户的产品还需要做详细的用户调研，有时候还需要建立用户模型，做用户细分。

当然，这么做的目标都是为了准确的勾画产品的业务模型。

业务模型是什么？有人说是用例的集合，有人认为是业务流程图，或者也许是一些特定模版的文档和图形组成的。

其实，我认为不必要如此纠结于形式，一个有经验的业务分析专家往往都是从一张纸和一只笔开始工作的。他们把业务从一个基本点开始梳理起，直至画出整个系统的“业务形状”。

我定义的“业务形状”一般由角色，行为，行为间的关系和边界构成，类似于用例和流程的结合图，如下图所示。

在完成了初步的业务梳理后，大家可以针对这些抽象的手工图纸展开头脑风暴并修改完善。有时候，最好在这些纸上简单的写上一两句描述，有助于你在向其他人介绍时，能像讲述一个故事一样，让听众更容易接受和理解。

为了便于传递和保存，把纸上的雏形整理变成可交互的成果，这就基本上完成业务建模了。

推荐几种很常用的业务模型表现形式：

1、 visio+word

微软Office家族中的visio可以很方便的画出流程图，业务生态图等，配上一定格式的文字说明就可以了。

优点是可读性好，学习成本低，很容易作为沟通的介质；缺点是维护起来麻烦，费时费事，而且标准往往不好统一。

2、UML语言

采用UML的UseCase等方式来展现业务模型，可以用一些专业的辅助工具来进行业务建模，例如IBM的Rose，MagicDrawUML等。采用UML语言最大的优点在于：一旦采用了统一的设计语言，则会减少团队沟通的成本，特别是降低了需求、设计、开发、测试过程之间的传递复杂度。当然，对于未使用过UML的团队来说，采用UML也会相应增加一些学习的成本；也需要考虑客户能否看懂UML所表达的意图。

3、表格

很多客户非常喜欢用表格的方式来承载需要说明的内容，他们认为表格是最能清晰表达意图的一种呈现方式。表格的最大好处是能清晰的说明每个细节，方便后续的分析和抽象工作。当然，采用表格也有一定的局限性，主要在于无法快速、直观地表达思想，交互上也因为内容繁多而会降低效率。

4、思维导图

一个好的沟通者会很善于用类似思维导图的方式来传递思想，因为思维导图可以很容易的展现思维脉络，清晰反映内容层级和重点。所以，采用思维导图来呈现业务模型也是一种很不错的选择。其缺点在于，虽然适合作为交流和沟通的媒介，但不太合适用于正式的交付和传递，这也与思维导图的内容形式不够丰富，约束力不强有关。

Ø  范围层（Scope）-搭建系统模型

范围层意义在于：用户的需求如何映射到系统上的APP，哪些功能和特性需要纳入设计，功能如何约束和实现。

在范围层，最重要的是搭建系统模型。其次是详细分析每个APP的内容和特性，并明确APP的设计细节。

在前面的章节探讨APP分析过程中，已经详细的说明了如何从BO展开分析，对BO的状态变化分析、行为分析、映射分析等识别系统的APP，构建系统模型。

下面着重说明如何去分析APP，我想从四个方面来详细介绍：

1、UseCase分析

在构建系统模型时，我们对BO的行为进行了识别，这些行为就是Use Case的来源。在分析过程中，我们往往会描绘如下的全局Use Case图：

然后，开始对Use Case进行逐个的描述，在描述时，我们会采用一些标准的格式，例如：

在进行Use Case时往往会碰到一个头疼的问题：如何确定用例的颗粒度？

有时候，特别是团队协作时，如果不事先统一用例颗粒度，则将出现非常混乱的局面。比如，有的设计师将注册、登录、添加购物车等作为一个最小单元的用例，但是有的设计师会把购物，退货，搜商品作为最小的用例单元，还有的设计师会把邮箱验证，重置表单内容作为最小的用例单元。这些根本就不在一个逻辑层级上的用例，被放到了同一个水平面，如果没有及时调整，则会让后面工序的团队成员困惑不已。

在前面提到了，我建议把较大的APP拆分为三个层次，即：APP层，Module层和Function层，这样拆分的原因是为了与系统层面的功能模块-页面-和页面里的操作（或者一个单独处理单元）逐一对应。所以，对于简单的APP，我们的用例就可以直接划分到Module层；一些复杂的应用，可以适当划分到Function层。

1、 优先级

在用例的基础上，我们需要结合产品或项目的实际目标，排列优先级。在进行优先梳理之前，要确定统一的级别标准。一般按照项目的大小略有不同，一般的项目3级就足够了，大型项目设定在5级以内。对应关系为：

优先级的梳理结果，如下例子所示：

特别是要明确所属包和所属对象，例如上述的UC-01001就是归属与产品Release 0.6.0包，需要在这个包中实现该用例。用例的责任人是王蒙，表示：一旦发生用例的变更，停止或测试问题，都应该由王蒙进行最终的解释和修改。

 

3、场景描述

一般Use Case描述清楚了，就能够把功能定义清楚。但是，开发和设计人员往往无法单纯通过几个用例图和用例描述就能清楚的理解用户需求。这时候，就要引入场景描述了。

场景（context），是将用例、业务流程和系统连成一个整体的说明。但并不是所有的用例都需要辅以场景描述，这取决于业务的复杂度及专业程度。

场景描述，应该紧扣业务场景和用例，一般以一个独立的业务情景（多个用例或一个用例）作为一个单元来描述。场景描述的主要目的是将用例间的关系能以一种更清晰的方式传达给其他干系人。

场景通常分作主场景和子场景。

例如，我们将在线购物作为一个主场景，而团购、普通购物是在线购物的子场景，而子场景涉及到浏览商品、搜商品、放入购物车、确认订单信息、支付、查看订单等用例。

场景描述可以采用如下图所示的卡片式方式来组织，简明扼要的表明用例间的关系即可。

上图中，S-01是场景编号，S-02-01和S-01-02是S-01的子场景；消费者是场景中的主要涉及角色；子场景中主要有用例和用例关系构成，需要说明的内容记录在卡片下方。

这种卡片式的场景描述优点是：简单、直观、易懂，易于交流和传递。

除了卡片场景描述法，还可以通过其他的形式进行场景描述，比如，用word文档、PPT等，只要能将业务场景说明清楚，表明用例之间、用例和系统间的关联关系即可。

 

4、内容需求

内容需求是信息架构设计的基础，在用例分析过程中，信息架构工程师就要开始收集和整理所有相关的内容需求，以BO为基础进行分析，包括已经存在信息内容，需要重新捕获、整理和加入到目标系统的新信息内容，内容形式，是否包括元数据需求等。

比如，采用下面的表格来整理内容需求：

Ø  结构层（Structure）-完善系统模型

结构层意义在于：通过交互设计和信息架构设计，完善和验证系统模型，使系统模型满足功能需求、交互体验需要和信息需求。

1、交互设计（InteractionDesign）

交互设计的目标是提升软件产品的可用性，在软件产品与使用者之间建立更融洽的关系，通过友好的使用体验让用户感到愉悦。

一般交互设计可以分解到三个不同的层次：

Ø  外部与系统间的交互

Ø  外部与APP间的交互

Ø  外部与数据的交互

在交互设计过程中，可以采用视觉词典（Visual Vocabulary），作为一个为规范信息架构文档而建立的开放符号系统，现在这个系统在全球各个企业中得到广泛的应用。

如下图所示，视觉词典元素集合：

交互设计有以下原则：

Ø  可视性：功能可视性越好，越方便用户发现和了解使用方法

Ø  反馈：返回与活动相关的信息，以便用户能够继续下一步操作

Ø  限制：在特定时刻显示用户操作，以防误操作

Ø  映射：准确表达控制及其效果之间的关系

Ø  一致性：保证同一系统的同一功能的表现及操作一致

Ø  启发性：充分准确的操作提示

Ø  伦理的：能体谅人，有帮助，不伤害、改善人的状况

Ø  有意图的：能帮助用户实现他们的目标和渴望

Ø  注重实效：帮助委托的组织实现它们的目标

Ø  优雅的：最简单的完整方案、拥有内部的一致性、合适的容纳和情感

 

交互设计的产物是线框图，通过线框设计能方便、直观的阐释了作者的交互设计思想。在小型项目团队中，不会单独设立交互设计师角色，往往是由业务分析人员或产品经理直接来完成这部分工作，因为，他们既懂得业务，知道用户的习惯和喜好，又有一定的交互设计能力。

然而，对于互联网项目，交互设计师其实是非常重要的角色，一般需要专职人员担任，并需要不断的去研究用户的操作习惯和喜好，不断的优化产品的交互设计。

 

 

Ø  框架层（Skeleton）-设计出高保真系统原型

框架层意义在于：通过原型设计和信息设计，设计高保真系统原型。这种高保真的原型与目标系统几乎是一样的，除了没有后台程序逻辑和真实数据的支撑。

设计出高保真的系统原型是非常有意义的：

其一、在进入开发阶段前，能够让用户和投资方实际了解目标系统的最终模样，并收集改进的意见；

其二，为开发者提供的非常确切、统一的开发目标；

其三，减少产品的需求变更，明确目标。

 

1、原型设计

原型设计包括了框架设计、交互呈现设计、页面布局设计、逻辑呈现设计等。

²  框架设计：系统要有一个良好的整体展现框架才能获得更好的体验。这个框架包括首页的框架，应用模版的框架，内容页的框架等等，这些框架承载了系统的所有信息内容。

²  交互呈现：交互呈现展现了用户与系统之间的所有交互相关元素，包括，友好提示，信息帮助，操作指引，错误纠正等等。

²  页面布局：在合适的框架下，还要设计良好的页面布局，比如页面是否采用960px栅格，自否需要自适应，二栏还是三栏设计，导航放在哪里等等。

²  逻辑呈现：页面中元素的放置也要展现正确的逻辑，重要的内容放在显眼的位置，相关的内容放在共同的区域，提示信息准确清晰等等。

目前，较为常用的原型设计工具包括：Axure和Dreamwaver。

 

2、信息设计

信息设计包括了：信息分类设计、信息元数据设计、导航设计、搜索设计、标签设计等。

 

Ø  表现层（Surface）-系统最终的界面表现

表现层意义在于：通过对色系、图标、字体、控件和样式的开发，组织成为最终的系统表现。

与交互设计一样，视觉设计也要遵从一定的规范，这些规范是代表了用户的需求，视觉一致性，以及专业经验体现。

在视觉设计完成后，

1、 前端工程师对视觉图片进行切图；

2、 程序员编写页面执行脚本；

3、 程序员编写后台应用代码；

4、 开发调试真实数据；

5、 程序员完成最后的图片渲染；

6、 初步可交付测试的版本宣告大功告成。

 

本文参考了：

《Elements of UserExperience: The User-Centered Design for The Web》

       ByJesse James Garrett