第一章
用户体验并不是指一件产品本身是如何工作的，用户体验是指"产品如何与外界发生联系并发挥作用"，也就是人们如何"接触"和"使用"它。
产品人创建一个产品的过程更像是在"开发"：逐步建立和完善产品的特性和功能，直到它们所组成的那个东西在市场上是可行的。
用户体验设计通常要解决的是应用环境的综合问题。
为体验而设计：使用第一。
科技产品都会带给人：他们总是责备自己。他们认为自己一定做错了什么。他们觉得自己很愚蠢。网站没有按照用户所期望的那样动作，这不能算他们的错。但是用户仍然觉得自己很笨。
无论用户体验对网站的成功具有多么重大的战略意义，在大多数网站发展的过程中，仅仅是"去理解人们所想和所需"这样一件简单的事，都从来没有得到过重视。
随着功能的不断膨胀，网站变得越来越复杂、越来越笨重、越来越难以使用，最后就失去了对初次访问者应有的吸引力。同时，企业仍然很少去关心用户真正喜欢什么，很少去发现价值、或真正可以使用的东西。
如果你的用户得到一次不好的体验，他们将不再回来。如果用户在网站上体验尚好，但是，在你的竞争对手那儿感觉更好，那么他们下次将访问竞争对手的网站，而不是你的。
企业关注财务盈收的情况，希望知道投资所得到的回报（return on investment），或投资回报率（ROI）。
一个最常用的投资收益的度量标准是转化率。
通过跟踪有百分之多少的用户被你"转化"到了下一个步骤，就能衡量你的网站在达到"商业目的"方面的效率有多高。
转化率对于电子商务网站来讲尤为重要。浏览电子商务网站的人数远远多于从它那里购买产品的人数。一次优质的用户体验是将这些"偶然浏览者"转化成"实际购买人"的关键因素。
在任何一个用户有可能掏腰包的网站上，都可以用转化率来衡量你的成果。
任何在用户体验上所做的努力，目的都是为了提高效率。这基本上是以两种主要形式体现出来的："帮助人们工作得更快"和"减少他们犯错的几率"。
科技产品没有按照人们期望的那样工作。这让他们觉得自己很笨——即使他们最终完成了自己想做的事情。
创建吸引人的、高效的用户体验的方法称为"以用户为中心的设计（user-centered design）"。在开发产品的每一个步骤中，都要把用户列入考虑范围。 ——UCD
用户体验对你很重要，其中一个最大的理由是：它对你的用户很重要。如果你没有给他们一积极的体验，他们不会使用你的产品。
第二章
表现层，一系列的网页，由图片和文字组成。
框架层，按扭、控件、照片和文本区域的位置。
结构层，用来设计用户如何到达某个页面，并且在他们做完事情之后能去什么地方。
范围层，结构层确定网站各种特性和功能最合适的组合方式，而这些特性和功能就构成了网站范围层。
战略层，不仅仅包括了经营者想从网站得到什么，还包括了用想从网站得到什么。
随着层面的上升，我们要做的决策就一点一点地变得具体，并涉及越来越精细的细节。
当我们做出的决定没有和上下层面保持一致的时候，项目常常会偏离正常轨道，完成日期延迟，而在开发团队试图把各个不匹配的要素勉强拼凑在一起的同时，费用也开始飞速上涨。
并不是说每一个"较低层面"上的决策都必须在设计"较高层面"之前做出。事物都有两个方面，在"较高层面"中的决定有时会促成对"较低层面"决策的一次重新评估（甚至是第一次评估）。
应该在计划好你的项目，让任何一个层面中的工作都不能在其下层面的工作完成之前结束。
从中间把五个层面分开。在左边，这些要素仅用于描述功能型的平台类产品。在右边，我们把这些要素用于描述信息型的媒介类产品。
在功能型产品这边，我们主要关注的是任务——去思考人们如何完成这个过程。
在信息型产品这边，我们的关注点是信息——网站应该提供提供哪些信息，这些信息对用户的意义是什么。
战略层：
- 无论是在功能型产品还是信息型产品，战略层所关注的内容都是一样的。来自企业外部的用户需求。
- 与用户需求相对应，是我们自己对网站的期望目标。这些就是产品目标。
范围层：
- 进入范围层后，在功能型产品一侧它就转变成创建功能规格。
- 信息型产品一侧，范围是以内容需求的形式出现。
结构层：
- 在功能型产品一侧，结构层将从范围转变成交互设计。
- 在信息型产品一侧，结构层则是信息架构。
框架层：
- 框架层被分成了三个部分。不管是功能型产品还是信息型产品，我们必须要完成信息设计。
- 对于功能型产品，框架层还包括了界面设计。
- 对于信息型产品，这种界面就是导航设计。
表现层：为最终产品创建感知体验。
还有两个额外因素，它们将会对最终的用户体验产生影响：1.内容，2.技术
第三章 战略层
产品目标：我们要通过这个产品得到什么？
用户需求：我们的用户要通过这个产品得到什么？
关键词是：明确
基本上，企业网站的存在是为了满足两种意图当中的一个：替公司省赚钱或替公司省钱。
对于任何一个网站，它需要明确描述的基础目标之一就是品牌识别。
品牌识别——可以是概念系统，也可以是情绪反应。在用户产品交互的同时，企业的品牌形象就不可避免地在用户的脑海中形成了。
成功标准：即一些可追踪的指标，在产品上线以后用来显示它是否满足了我们自己的目标和用户的需求。
对于依赖广告收入的网站，印象数——你的网站上每一个广告的每天被展示的数量——是绝不可忽视的重要指标。
网站的用户体验不能为你带来新用户——你必须依靠口碑或是市场营销来吸引潜在用户。然而用户体验能极大地影响访问者的二次访问几率。
我们很容易落入这样的陷阱，即认为我们正在为理想化的用户设计产品，理想化的用户就是"某些与我们完全一样的人"。但事实上我们并不是为自己设计：而是为其他人设计如果想要这些"其他人"喜欢并使用我们创建的东西，那么就必须要了解"他们是谁"以及"他们的需求是什么"。
用户细分，将用户分成更小的群组，每一群用户都是由具有某些共同关键特征的用户所组成。
消费心态档案是用来描述用户对于这个世界，尤其是与你的产品有关的某个事物的观点和看法的心理分析方法。
创建网站或任何一个技术型产品时，有另一组非常重要的属性也需要考虑：用户对技术和网页本身的想法。
创建细分群只是一种用于"揭示用户最终需求的手段"。
用户研究：
- 像问卷调查和焦点小组这种市场调研方法是获取用户的基本信息的宝贵来源。当你能明确地表达出你试图从用户身上获得什么信息时，这些方法才能产生效果。
- 现场调查是指一整套完整、有效且全面的方法，用于了解在日常生活情境中的用户行为。
- 任务分析是认为每一个用户与产品的交互行为都发生在执行某一任务的环境中。
- 用户测试是请用户来帮忙测试你的产品。
- 可用性的最终目标，都是寻找令产品更容易使用的途径，用户需要可用的产品。这的确是所有用户最普遍的需求。
人物角色——有时也叫做用户模型或用户简介——可以让你的用户变得更加真实。人物角色是能代表整个真实用户需求的虚构人物。通过赋予一张人物的面孔和名字，你将用户调查及用户细分过程中得到的分散资料重新关联起来，人物角色可以帮助你确保在整个设计过程期间把用户始终放在心里。
决策层是一群资深的决策者，他们管理那些会影响产品决策的部门。决策层可能就会包括市场销售部门的代表、客服部门还有产品经理。取决于企业在做决策制定时的正式流程。
在拟定决策时有一群人经常被忽略，那就是普通员工——这些人负责让企业每天正常动作。这些人通常比他们的经理更知道"什么行得通"和"什么不可行"——特别是在用户需求方面。
产品目标和用户需求经常被定义在一个正式的战略文档或愿景文档中。不仅仅是列出目标清单——它提供不同目标之间的关系分析，并且说明这些目标要如何融入更大的企业环境中去。
撰写战略文档时，文档并不是越多越好。让文档简洁明了并切中要点。
不让你阅读战略文档是很糟糕的。
战略应该是设计用户体验的流程中的起点，但那不意味在项目开始之前你的战略需要完全确定下来。战略也应该是可以演变和改进的。
第四章 范围层
定义项目范围在做这两件事：这是一个有价值的过程，同时能产生有价值的产品。
过程的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。
产品的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的全部工作，它也提供了一门用于讨论这件事情的共同语言。
用文档来定义产品需求？
- 这样你才知道你正在建设什么
- 这样你才知道你不需要建设什么
如果你不能有意识地管理你的要求，你将陷入可怕的"范围蠕变"，每一个额外的要求看上并没有增加太多的工作量，但是当它们汇集到一起的时候，你的整个项目就会失去控制地膨胀，结束时间遥遥无期，而费用预算正不可避免地朝着最终的分崩离析飞奔而去。
功能需求规格——哪些应该被当成软件产品的"功能"以及相应的组合。特性，在软件开发中，范围层确定的是全部的功能需求或功能规格。
内容需求常常伴随着功能的需求。真正的内容常常是通过一个内容管理系统（Content Management System,CMS）来进行管理的。
一个内容管理系统可以实现自动化流程，能展示和交付内容给用户。
需求的详略程度常常取决于该项目的具体范围。最用之不竭的需求总是来自用户本身。
定义需求过程中得到的需求将分成三个主要类别。
- 有时候人们口中说出来的、所期望的特性其实并不是他们想要的。
- 有时候人们口中说出来的、所期望的特性其实产东是他们想要的。通过与用户探讨这些建议，你有时候可以得出能真正解决问题的、完全不同的需求。
- 人们不知道他们是否需要的特性。当你让人们讨论新需求和战略目标时，他们有时会突然想起某个伟大的构思，而根本忘记了那个正在维护中的产品。
讽刺意味的是，那些很少去想象产品新方向的人，恰恰是参与创建和设计产品最深入的人。
我们也期望从竞争对手处得到一些启示。任何一个在做同一件事的企业基本上在试图满足同样的用户需求，同时也在试图完成相似的产品目标。
即使不是产品的直接竞争对手也能提供丰富的潜在需求。
文档不能解决问题，但定义可以。我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。功能规格说明只需要包含在设计或开发过程中出现有可能混淆的功能宣言。
几条规则适用于撰写任何类型的功能规格说明：
- 乐观。描述这个系统将要做什么事情去"防止"不好的情况发生，而不是描述这个系统"不应该"做什么不好的事情。
- 具体。尽可能详细地解释清楚状况。
- 避免主观的语气。
FAQ（Frequently Asked Questions，常见问题），一个系列简短的问题和回答。一个FAQ给予用户的真正价值，在于它可以随时提供用户普遍需要的信息。内容设计者总是用其他一些问题的答案替代了能真正满足FAQ需求的答案。
内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节、PDF或音频文件等相对独立元素的大小等。
尽可能早地确定某个人来负责每一个内容元素也是非常重要的。内容是一件艰苦的工作。
如果在做内容规划的时候，你认为它们只需要发布一次，之后再也不用更新的话，那么随着时间的推移，这个网站就越来越难以满足用户的需求。
你应该定义每一个内容特性的"更新频率"。更新频率应该来自于你产品的战略目标：希望用户多长时间来访问一次？希望多长时间更新一次信息？对于你的用户而言较为理想的更新频率也许对你的企业来说不切合实际。但你必须要确定一个频率，它是介于你的用户期望值和有效资源之间一个合理的中间值。
项目范围是建立在战略层的基础上的，因此我们应该去评估这些需求是否能满足我们的战略目标（无论是网站目标还是用户需求），另外还要额外确定第三种范围：实现这些需求的可行性有多大？
有些特性可能会因为技术上的局限而无法实现。
如果是因为时间有限，那你可以把这个特性放到下一个版本或项目里程中。如果是资源有限，则技术或企业的变化有时能减少资源的负担。
很少有功能是独立存在的。有些特性要和其他的一起权衡，才能得到一个连续的、统一的产品。
任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除出去。如果你发现自己正在反复审视战略目标，那么你极有可能是大早地进入了需求定义阶段。
由于管理层经学分不清特性和战略，某些特性总是会占据上风。因此需求的定义过程就变成了与这些管理层进行谈判的过程。
------------------------------------------------
使用Word2007发布，如图片未显示或提示有附件但无附件下载地址的，请移步至独立博客查看完整文章！
文章修改及增加内容仅在独立博客中更改！
我的独立博客：壊小子 - http://www.zyblog.net/
本文链接：http://www.zyblog.net/post-81.html
欢迎转载，转载请注明本文来源。
来源：https://www.cnblogs.com/charleszhang/archive/2012/07/30/2614533.html