Jesse James Garrett的《用户体验要素：以用户为中心的产品设计》（The Elements of User Experience: User-Centered Design for the Web and Beyond，Second Edition）大概是UX入门的必读作品了，前阵子在整理资料的时候顺手把这张图汉化了：

这张图就是出自这本书，也是这本书内容的主要纲领，纲领都做了，顺带看一下原文也是情理之中。书本身的内容比我想象中要简明，在我最初了解 UX 的时候，我一直觉得这是一件不言自明的事情，在看过这本书之后，才发现领域的不同带来的鸿沟竟是如此巨大：对于一把椅子来说，其功能性与用户体验是密不可分的，没有良好的体验的椅子，其功能性几乎无从谈起，而对于互联网产品而言，功能与体验的相关性就没那么强（尤其在功能大量同质化的今天，产品体验反而成为了成败的关键）。

现在 UX 或者 UCD 已经成为一个流行词汇，就像前两年（乃至现在仍在）流行的“互联网思维”，老板们开始试着重视这些东西是因为它们确实能带来更高的效益。虽然四处都在招 UX Designer，但我更倾向于另一种说法，UX 是无法“被设计”的，用户所有的体验，都应当是顺理成章理所当然清晰明了的，我们只能顺着这些“理”，围绕目标用户的基本特质去设计我们的产品。

书里试图将“作为信息系统的网站”和“作为软件界面的网站”融合起来，其实作为中国互联网的年轻一代或者大多数，很少有经历过单纯“作为信息系统的网站”的时代，我接触互联网的时候，中国互联网已经有了三大门户，各种工具不一而足。我一直以为只要目标明确、手段清晰、技巧得当，最终产品总不会太糟糕，因而在我看来，这本书可能其实是在讲产品经理在做的事——开发产品的流程（难怪豆瓣用户都喜欢把这本书丢进产品经理的书单里）。

为何用户体验要贯穿产品开发的始终，在本书中所提到的第一个层面，战略层，其所指与网站的功能或内容都毫不相干，然而却在潜移默化中影响着最终的功能形态和内容构成。诚如书最后所言，产品的开发过程应该更类似于马拉松，而不是一个一个阶段的短跑冲刺。如果产品最终的流程如丝般顺滑，用户在任何一个角落都可以轻松找到自己想要的内容而欢欣鼓舞，那么这个产品的基础，也就是其战略目标，一定是清晰的。而就算瞎猫碰上死耗子，漫无目的的产品仍旧产出了良好的体验，要么你可能需要回头修改你的战略，要么就很有可能有更大的潜藏的问题（比如用户喜欢，你却得不到盈利？）

用户体验要素的分层

这张图是上面那张图的纲领形态，五个层面对应五层所需的行动。虽然作者将产品开发流程分为5个层面的行动，但这5个层面并非彼此割裂孤立的，向上反馈是必要且重要的，及时修正上一层面操作中所出现的问题，可以为将来的发展铺垫得更好。

战略层

研究思考产品为何而生，于人于己的意义何在？品牌形象如何融入？用户细分及用户研究，并撰写战略文档都是此阶段要做的事情。

公司开发一个产品，肯定是为了赚钱或者省钱，个人开发某个产品也许只是为了自己爽，而赚钱或省钱的方式各有千秋，每个人G点也不同，所以产品目标应该是基于双方（开发者及使用者）需求提出的，找到需求点，提出问题及解决方案。

而这也就势必牵涉到对用户的分析，目标用户群体是怎样的，他们的年龄段，对互联网的使用习惯，生活习惯，人生三观，以及针对产品的一些特殊需求等等，通过不同的手段将用户分成不同类别。然后就是对这些用户群体的研究，可以是通过他人已经完成的研究成果，也可以自己去做。我不太喜欢调查问卷（因为我自己本身就是一个习惯性问卷作弊者…），实际的操作记录及用户测试相对更加可靠，最终根据测试和调研结果，虚构若干个“使用者”，将具有代表性的需求分配给这些“使用者”，这样产品出产会更加顺利。

而对于开发者而言，开发产品的目的大抵是明确的（假装他是明确的，不明确的不要做了趁早洗洗睡吧），这里需要额外思考的是品牌形象的整合，与如何将一整套战略完整地传达给团队中的每一个人，毕竟就算制定了策略，最终的实施者却是实际开发的团队成员，倘若他们不知道策略如何，谈何实施。最后应该是成功标准，有了目标，就要有是否达成目标的标准，倘若不是转化率注册率之类的数字，访问量停留时间这样的指标也可以。

范围层

需求定义。

之前根据用户需求提出了产品目标，现在则是根据产品目标提产品需求：内容和功能上的。为了满足用户以及我们的种种需求，这个产品需要囊括哪些内容，需要建立哪些功能，这些功能又需要哪些内容，这些内容又需要哪些功能来支撑。所以其实我不太懂把功能和内容割裂思考的方式，它们本来就是水乳交融。

所有的需求都要写下来，并且尽量避免抽象（最受欢迎）、主观（高大上）或者略语（等等），这些需求应该是可以确定是否已经满足的，像“时尚时尚最时尚”这种表述，鬼知道什么产品能满足。内容需求则应该涉及到文字、图像、影音文件的相关数量及更新频率等等，并且根据使用者的不同区分出不同的内容需求。

最后确认这些需求的优先级，以及它们跟战略目标之间的关系，如果某个功能或内容需求无法满足战略目标，那就要思考是哪边的问题，并及时修正（删掉这个需求，或者修改战略）。

结构层

交互设计与信息架构。

这俩都是术语，也已经自成学科。对于交互设计来说，产品功能通过怎样的流程行进，如何能满足用户潜意识下的反应，通过隐喻或者其他方式让用户减少思考，令其能够凭直觉使用网站的功能，并通过各种方式减少用户犯错的机会，及其所造成的挫败感（及时纠错），大抵就是交互设计在做的事。这里包含了各种各样的模式，比如：当人们填写完查询表单并点击提交的时候，希望看到的是查询结果而非广告或注册窗口。

信息架构是网站内容的分类管理，这些内容的分类可以根据战略层的产品目标逐一细分需求得到，也可以通过范围层的内容需求进行分类整合，最好的做法是二者配合进行，最终令细分下来的内容符合内容需求，整合出的内容符合战略需求。一个适应性强的信息架构系统，是有极强的扩展和统合能力的，如果很好奇这部分内容的话，我觉得去给 wiki 做页面分类是个不错的选择…内容整合或细分的困难点就在于如何留下足够的弹性空间去容纳新的部分而不破坏原本整体的架构，以及根据新的需求重新定义分类或增加分类方式。这些所有的信息分类组合，都要建立在前面所描述的需求及目标之上，能够预知用户的期望并将其纳入设计。

在这个部分作者提到了网站架构图——记录网站页面或文件的群集、独立以及彼此之间的关系，在他的官网上有一份文档描述如何制作架构图，现在可能叫 User Interface Flow 的也有。名字和形态都不重要，这份图表的最重要目的是将之前所有抽象的工作转化成可操作的具体的事项，因为接下来，开发流程就要进入到一个完全具象化的世界里。

框架层

线框图来了。

让界面与用户的习惯一致，让对的东西出现在对的位置上，使用对的元素传达对的信息（突出该突出的，让按钮成为按钮）。让用户有能力在页面之间跳转——有意识的或者是无意识的，应该至少提供一种方法。把信息分类组合，提供给界面和功能。把这些内容全部组合在一起，使用线框图来呈现最终的结果。

表现层

把线框图与美学合二为一，传统的设计学终于登场。

使用多种感知方式，保证对比和一致性，做好配色和排版。如果需要的话，可能还要产出一份视觉 guideline，用于维护品牌一致性，并能够为后继者提供足够的参考资料。

用户体验要素的取舍

开头就说了这本书近乎于在讲产品开发的流程，但是谁都知道能够完整完成这套流程的团队凤毛麟角，那么是否就应该抛弃某些没有实质性产出的部分呢……？

答案当然是否。在产品的开发设计过程中，所遇到的问题和奇怪的意见，只要拿来和目标与需求比对，就基本都能够搞清楚是否采纳或者如何反驳。所以产品的目标与需求可以一步完成，需求与架构可以同步完善，甚至把线框也一起囊括，但总的来说，这些步骤所描述的具体内容都应该逐步完成，这样才能最大限度地避免各种潜在问题。