用户体验要素
目录
第一章 用户体验要素为何如此重要
生活中的遭遇
什么是用户体验
从产品设计到用户体验
为体验而设计：使用第一
用户体验和网站
用户体验就是商机
在乎你的用户
第二章 认识这些要素
五个层面
表现层
框架层
结构层
范围层
战略层
自下而上的建设
基本的双重性
用户体验的要素
表现层
框架层
结构层
范围层
战略层
应用这些元素
第三章 战略层
产品目标和用户需求
战略层定义
产品目标
用户需求
团队角色和流程
第四章 范围层
功能规则和内容需求
范围层定义
功能和内容
定义需求
功能规格说明
内容需求
确定需求优先级
第五章 结构层
交互设计与信息架构
结构层定义
交互设计
概念模型
信息架构
团队角色和流程
第六章 框架层
界面设计、导航设计和信息设计
框架层定义
习惯比比喻
界面设计
导航设计
信息设计
线框图
第七章 表现层
感知设计
表现层定义
合理设计感知
忠于眼睛
对比和一致性
内部和外部的一致性
配色方案和排版
设计成品和风格指南
第八章 要素的应用
提出正确的问题
马拉松和长跑
第一章、用户体验要素为何如此重要
1.1生活中的遭遇
1.2从产品设计到用户体验设计
正确的产品形态不是由“功能”所决定的，而是应该有用户自身的心理感受和行为所决定的。
用户体验的前提是产品具有使用价值，一把椅子能做坐人才能称为产品。产品越复杂，确定如何向用户提供良好的使用体验就越困难。
用户在使用一个产品时，它都是一个“自助型”应用，我们应该尽可能的帮助用户理解产品，避免用户产生挫败感从而对产品失去信心。如果用户弄不明白你的产品时怎样工作的，你所提供的“世上最强的功能”也将毫无用户。
特性和功能总是最重要的，但是用户体验对于用户忠诚度有着更大的影响。
任何在用户体验上做的努力都是为了提高效率。“帮助人们工作得更快”和"减少他们犯错的几率"。
1.3在乎你的用户
“以用户为中心的设计”：在产品开发的每个步骤中，都要将用户列入考虑范围（需求分析、产品设计、需求文档、开发/设计、测试/Bug修复）。这保证了你所做的决定、妥协都不是随意得到的。
第二章、认识这些要素
2.1五个层面
确保用户在你的产品上的所以体验不会发生在你“明确、有意识的意图”之外（逻辑严谨、考虑产品的初始、常态、边界、错误等多种情况）。考虑用户有可能采取的每一个行动的每一种可能，并试图去理解用户在这个过程的的期望值。
表现层：满足用户的感官需要
框架层：
①界面设计(页面布局和界面各类控件；)/导航设计(全局/局部/友好/辅助导航/SiteMap)
②信息设计
结构层：
①交互设计(可能的用户行为+系统如何配合相应这些行为)
②信息架构(如何将信息表达给用户)
范围层：
①需求范围/集合
②功能规格(内容清单+功能规格说明、需求优先级排序)
战略层：
①产品目标(我们想通过产品得到什么)
②用户需求(用户想通过产品得到什么)
在大多数情况下，你所能够提供给用户的体验状态主要是有技术来决定的。
2.2自下而上的假设
这种连锁效应意味着在较高层面中选择一个界限之外的选项将需要重新考虑较低层面中所做的决策（产品目标、用户需求不确认时，后续修改影响全局--控制修改范围）。
第三章、战略层
3.1战略层定义
成功的用户体验，其基础是一个呗明确表达的“战略”。知道企业与用户双方对于产品的期许和目标，有助有促进用户体验各方面战略的确立和制定。
产品目标：我们想要通过这个产品得到什么？
用户需求：我们的用户想得到什么？
这里的关键词是明确：当我们能够将自己想要什么表达得越清楚，以及确切的知道其他人（用户）想要从我们这里得到什么，我们就能越精确的满足双方的需求。
3.2产品目标
我们每做的一个决定，都应该建立在我们确切的了解了它们的影响力的基础上。
3.3品牌识别
将品牌形象具体而确切的写进目标，将会提高呈现积极产品形象的机会
3.4成功标准
3.5用户需求
理想化的用户-要对用户需求寻根问底，就必须要定义谁是我们的用户。
①用户细分
用户细分将全部的用户划分为较小的、有共同需求的小组，以此来帮助我们更好的了解用户的需求。
②可用性和用户研究
一些常用的研究方法——问卷调查、用户访谈、焦点小组、数据分析、用户反馈、行业资讯、用户测试
③创建人物角色
收集用户数据是非常有价值的，但是通常你会忽略那些数字背后所代表的真正人物，通过创建人物角色（用户模型）会让你的用户变得更真实。通过赋予一张人物的面孔和名字将用户调查和用户细分过程中的分散数据重新关联起来，人物角色可以确保你在产品设计整个过程中把用户放在心里。
④团队角色和流程
在拟定策略时，应该尽可能的让更多地人参与进来（客服人员在平时更多的能够接触用户），用户真正的反馈很少能够传递到产品开发团队中（建立用户反馈渠道）
产品目标和用户需求通常被定义在战略文档或愿景文档中。这些文档应该尽可能的简洁明了并切中要点。
战略文档不应该是由几个资深员工能够分享，在项目进行期间应该让所有参与者都能了解。
战略也应该是可以演变和改进的，当战略被系统的修改与校正时，这些工作就会贯穿正过程，应该让所有参与者都了解到改动，并做好相应的对策。
第四章、范围层
4.1范围层定义
当你把用户需求和产品目标转变成你应该提供给用户什么样的功能和内容时，战略就变成了范围。
用文档来定义需求（需求表、需求文档），这样你才知道你在建设什么（达成共识、信息传递、责任分解）、才知道你不需要建设什么（需求管理、范围定义、优先级、产品迭代）
4.2功能和需求
在范围层，我们从战略层的抽象问题“我们为什么开发这个产品”，转而面对一个新的问题“我们要开发的是什么”。——功能规格说明书
用时候人们口中说出来的、所期望的特性并不是他们想要的。听用户的反馈，但不要用户建议的方案简单实现。
当你把所有精力投入到为维持现有产品时，你常常会忘了哪些是真正的限制条件，哪些是为了简化产品做的选择（文档记录）。
假设你有一个用户决定购买了-但不知道是不是你的产品，你设计的产品如何让这个选择过程更容易呢？
竞品借鉴、竞品分析
场景：一个场景是一个简单的故事，描述了一个任务角色会如何完成这些用户需求。通过想象“我们的用户将会经历一个怎样的过程”，我们就可以帮助他找到这个过程潜在的需求。
4.3功能规格说明
文档不能解决问题，但定义可以，文档应该足够准确和清楚。
乐观：描述这个系统将要做什么去防止"不好的"事发生，而不是这个系统不应该做什么“不好的事”
具体：
避免主观的语气：容易产生误解、功能规格不下可验证的。
2017-2-25 23:59:07
