【读书笔记】《用户体验要素》
写在前面的话，这本书从暑假实习的时候某姐姐介绍要看，到发现N多大牛力荐要看，到自己一直喊着要看，到现在磨磨蹭蹭才看了那么一半，才发现真的值得一读（你要深入细致的读），一读才发现根本停不下来，简直有种醍醐灌顶的感觉。以前自己各种乱糟糟的交互碎末渣们终于可以被解释、被理解了，终于慢慢理清头绪了。看书慢、喜欢边看边嚼是我的看书的特点，所以得慢慢啃，慢慢记，慢慢写心得。这个平台真好，以后可以当成云平台笔记本，随时随地查阅自己整理过的知识。O(∩_∩)O~
【战略层】——产品目标和用户需求。（明确企业想要什么，用户想要什么）
用户需求——用户细分
消费心态档案（psychographic profile）用来描述用户对于这个世界，尤其是与你产品有关的某个事物的观点和看法的心理分析方法。心理分析通常与人口统计特征息息相关：同样的年龄段、同一地点、和同一收入水平的人们往往有相似的观点。按人口统计特征归纳出来的同一个用户群体，其世界观和感兴趣的事物往往大不相同，通过消费心态档案来揭示用户需求，可以得出很多统计学特征无法获取的新见解。
细分用户群体的基本维度：用户的经验、专业程度的不同；
可用性和用户研究：
研究工具/方式：问卷调查、市场调研方法（用户访谈、焦点小组）（适合用户收集用户的普遍观点及感知）
用户测试、现场调查（适用于理解具体的用户行为及用户在和产品交互时的表现）
现场调查：一整套完整、有效且全面的方法，用于了解在日常生活情境中的用户行为。
任务分析是与现场调查密切相关的另一种研究方法，相当于轻量级的更低成本的现场观察方式。
任务分析的概念认为：每一个用户与产品的交互行为都发生在执行某一任务的环境中。
任务分析是一种仔细的分解用户完成任务的精确的步骤的方法。
用户测试，请用户帮忙测试你的产品。
可用性的最终目标：寻找令产品更容易使用的途径。
可用性测试：测试已完成的网站的易用性；让用户测试原型（纸质草图、低保真、模拟界面、高保真均可），大型项目在不同阶段使用不同原型来收集用户的意见，这个将贯穿到整个开发过程中；有些测试不需要原型，可以招募用户来参加能观察到用户如何看待产品的活动。
卡片排序法（card sorting）：用于探索用户如何分类或组织各种信息元素。
创建人物角色
人物角色（personas）/用户模型/用户简介：能代表整个真实用户需求的虚拟人物。
通过赋予一张人物的面孔和名字，能将用户调查和用户细分过程中得到的分散资料重新关联起来，从而保证设计过程中始终将用户放在心中。
人物角色要与用户研究了解的内容保持一致，但可以加一些虚构的具体细节使其栩栩如生。
【范围层】（功能规格，内容需求）
把用户需求和产品目标转变为产品应该提供给用户什么样的内容和功能时，战略就变成了范围。
用文档定义产品需求的原因：
知道正在建设什么
知道不需要建设什么
当前难以满足的需求可以，可以成为启动下一个版本的基础，这样就能形成一个不断循环的开发过程。
功能和内容：
从战略层的为什么要开发这个产品，转而面对“要开发的是什么？”这个问题。
FAQ（frequently askedquestions）：常见问题
有时一个需求可以满足多个战略目标，一个战略目标也常常关系到多个不同的需求。
范围层：被功能型产品、信息型产品分成两个部分
功能型产品：考虑功能需求规格，即哪些应该被当成软件产品的“功能”以及相应组合；
信息型产品：考虑内容，属于编辑和营销推广的领域。
定义需求
需求可分成三大类别：
人们口中讲述的他们的想法，最显而易见的，这中间有一部分非常清晰的好想法，会通过各种途径体现在最终产品上
有时候人们口中说出来的、所期望的的特效其实并不是他们想要的，通过与用户探讨建议，可以得到能真正解决问题的、完全不同的需求。
人们不知道他们是否需要的某些需求
场景：scenarios,把虚拟人物（人物角色）放到一个简短的故事中。一个场景是一个简短的故事，简短描述了一个人物角色会如何完成这些用户需求。
功能规格说明
几条撰写规则：
乐观。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统不应该做什么事情。Eg:这个系统不允许用户购买没有风筝线的风筝。可以描述为：如果用户要购买没有风筝线的风筝，系统应该引导用户到风筝线页面。
具体。尽可能详细的解释清楚状况，这是一个功能能否被实现的最佳途径。
Eg:最受欢迎的页面要重点标注；（问题，最受欢迎？如何重点标注？
改为：上一周被播放最多的视频要显示在列表的最前端。
避免主观的语气
【结构层】——为网站创建一个概念结构（交互设计、信息架构）
在传统的软件开发行业，涉及“为用户涉及结构化体验”的方法被称为交互设计。
在内容建设方面，主要是通过信息架构“information architecture”来构建用户体验。
交互设计和信息架构都强调一个重点：确定各个将要呈现给用户的元素的“模式”和“顺序”。
交互设计关注于影响用户执行和完成任务的元素；信息架构则关注如何将信息表达给用户的元素。
交互设计和信息架构要求去理解用户，理解用户的工作方式、行为和思考方式。
交互设计关注用户“可能的行为”，同时定义“系统如何配合与响应”这些用户行为。
使用产品时，机器和用户之间会产生某种类似舞蹈的步伐。用户移动，系统响应；接着用户再移动，系统再响应，这样舞步才能继续。成功的舞蹈是要求每一个参与者能够预测对方的移动。
概念模型：用户对于“交互组件将怎样工作”的观点。
规划好概念模型能帮助你做出一致的设计决定。
不必将概念模型明确的告诉用户，用户容易混淆视觉，更重要的是，概念模型是用于在交互设计的开发过程中保持使用方式的一致性的。
不要将比喻从现实世界中一字不落地照搬过来。
错误处理（预防+撤销允许犯错）
当人们犯错时系统要怎么反应，同时错误第一次发生时，系统要如何防止人们继续犯错。
系统应该帮助用户找出错误并且改正它，在某些情况下，系统甚至可以帮助用户自动改正错误，但是一些最令人反感的行为，往往出现在软件试图善意的修正用户错误的时候（eg: word必须关闭后才能完成某些工作和不再去改正那些“改正”）
一些用户的行为在一开始无法被看成是错误的，用户在完成这个动作后才发现做错了，这种情况下，系统应该为用户提供从错误中恢复的方式（撤销）；对于那些不可能恢复的错误，需要提供大量的警告，这种警告只有在用户真正注意到时会产生作用。