书本的知识是系统的，更有利于我们掌握知识。工作中遇到问题，别忘了去书中找找答案。

《用户体验要素——以用户为中心的产品设计》一书首先将用户体验的开发流程分为了5个部分，他们分别是1.战略层、2.范围层、3.结构层、4.框架层以及5.表现层，

要按照由1-5的顺序来建设用户体验设计。但是每一个层面不是独自分离的，要让每一个层面的工作在下一个层面可以结束之前完成。

在每一个层面，我们都根据竞争对手所做的事情、业界最佳的实践成果来做决定。今天先介绍一下前两个层次。

战略层

在这一层面要回答两个基本问题：我们的用户通过这个产品得到什么？

                                                   我们要通过这个产品得到什么?

关键词：明确|成功标准|用户需求|团队角色和流程

（1） 明确

当我们越清楚地表达我们想要什么，以及确切的知道其他人想要从我们这里得到什么时，我们就越能精确的满足双方（用户和公司利益）的需求。

每一个我们做出的决定，都应该建立在我们确切地了解了它的影响力的基础之上。明确的定义“成功的条件”——而不是定义“通向成功的路径”——才能保证我们不会在这个阶段跑得太快。不要急于想我要把产品做成什么样子，而要先了解清楚我设计的这个产品的竞争情况，潜在优势等的因素。

（2） 成功标准

建立一些可追踪的指标，在产品上线以后用来显示它是否满足了我们自己的目标和用户需求。比如要为公司带来100万元的利益，其实这也是实现老板交给自己的任务。

（3） 用户需求

A、 用户细分

定义产品使用者的不同角色可以帮助你区别并分析各种需求。

要么选择针对单一用户群设计而排除其他用户群，要么为执行相同任务的不同用户群提供不同的方式。无论我们选择哪一种，这个决策将会影响日后与用户体验相关的每一个选择。例如快看漫画APP就是针对喜爱漫画的年轻人，而微信则是针对大多数年龄段的人群。

B、 可用性用户研究

包括使用各种研究工具，例如问卷调查法用户访谈法等

C、 创建人物角色

在创建的非常好的人物角色的描述中，每个方面都能够追溯到对用户所说的话的引用，或者观察到的用户行为。

（4） 团队角色和流程

拟定决策时除了资深决策者还应该让普通员工——（那些人负责让企业每天正常运转）参与。没有人比那些每天跟客户交谈的人更明白客户遇到的困难是什么的了。

撰写战略文档时，文档并不是越多越好，你没有必要把每一个数据来源和相关的的意见都写出来以表达你的观点，让文档简洁明了并切中要点，当看到大摞的文档，任何人都不愿意去仔细阅读，并且每次设计流程都是时间紧迫。

战略应该是设计用户体验的流程中的起点，但那不意味着在项目开始之前你的战略需要完全确定下来。

范围层

带着“我们想要什么”、“我们的用户想要什么”的明确认识，我们才能弄清楚如何去满足这些战略目标。当你把用户需求和产品的目标转变成产品应该提供给用户什么样的内容和功能时，战略就变成了范围。

关键词：用文档来定义需求|定义需求|功能规格说明|内容需求

（1） 用文档来定义需求

详细的记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候将到达这个目标

把责任分配清晰，可以大大提高协作的的效率

许多功能听上去都相当的诱人，但是他们对于项目的战略目标并不是必需的，此外，所有的项目在开始如火如荼的进行时，关于功能的各种各样的可能性都会浮现出来。当这些想法出现的时候用一个文档来记录它们，可以为你提供一个评估这些想法的架构，帮助你了解它们是如何（或是否）满足当初所承诺要做的那些事。

了解你“不需要做什么”也就意味着知道哪些是你“不需要马上去做”的东西。把这些杰出的想法收集起来，找到一个适宜的方式，让它们符合你的长期规划，这才是真正价值所在。确定具体、系统的发展要求，并将任何不符合这些要求的想法作为潜在的未来功能囤积起来，只有通过这种更慎重的途径，你才能真真管理整个设计过程。

（2） 定义需求

最用之不竭的需求源泉总是来自用户本身

需求的三个类别：

A、 最显而易见的是人们讲述的他们想要的东西

B、非常清晰的想法，会通过各种途径体现在最终产品上。

有时候人们口中说出来的，所期望的特性其实并不是他们想要的，通过与用户探讨这些建议，你有时候可以得出能真正解决的问题、完全不同的需求。如果用户说他想要一个钻头，则可能是因为他要一个孔，打孔可能是因为要挂相框，那我就可以据此来设计不需要孔的相框。

C、人们不知道它们是否需要的需求

汇集企业各个部门的成员或不同类型的用户代表来进行头脑风暴会议，是一种打开设计者思路、让他们考虑以前从未想到的可能性的，非常有效的工具。

从竞争对手处得到一些启示，即使不是产品的直接竞争对手也能提供丰富的潜在需求。

（3） 功能规格说明

功能规格说明不需要包含产品的每一个细节——只需要包含在设计过程中出现有可能混淆的功能定义。同时功能规格说明也不需要展望产品未来的理想化状——只需要记录在创建这个产品时已经确定下来的决议。

撰写功能规格说明的规则

乐观：描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。

这个系统不允许用户购买没有风筝线的风筝                                                 ×

如果用户想买一个没有线的风筝的话，这个系统应该引导用户到风筝线页面  √

具体：尽可能详细地解释清楚状况

    最受欢迎的视频要重点标注                                                                     ×

什么叫最受欢迎？     用什么形式来重点标注？

点击量/最多收藏？

上一周被播放最多的食品要显示在列表的最前端                                       √

避免主观的语气

l  这个网站的风格应该是时尚的

l  这个网站应该符合邮递员Tom所期望的时尚

l  网站的外观应该符合企业的品牌指南文档

我们可以量化的定义一些功能，通过这样的手段来避免主观性。例如高级别的执行能力可以由至少要支持1000个用户同时使用。

（4） 内容需求

一个FAQ（常见问题）基于用户的真正价值，在于它可以随时提供用户普遍需要的信息。

内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节等。这些大小的估计不一定要非常精确——大致相近即可。

尽可能早的确定每个人来负责一个内容元素也是非常重要的。

定义每一个内容特性的“更新频率”更新频率应该来自你产品的战略目标：从你的网站目标来看，你希望用户多长时间访问一次？从你的用户需求来看，他们希望多长时间更新一次信息？

确定的更新频率是介于你的用户期望值和有效资源之间的一个合理的中间值。

对于已有大量内容的项目而言，很多关于内容的信息都记录在一个内容清单中，这样团队中的每个人才能确切知道它们涉及用户体验需要做哪些工作。

如果你发现自己在反复审视战略目标，那么你极有可能是太早的进入了需求定义阶段。关注战略目标，而不是各种实现这些目标的手段。