第一章 用户体验为什么如此重要

产品的内部运作是可以由功能所决定,但对于产品直接面对用户的那些部分——按钮、布局、文字,也包括外观,正确的产品形态应该由“用户自身的心理感受和行为”来决定的 ,而不是功能。

产品设计和用户体验设计的不同在于:创建良好的用户体验和产品自身的定义之间的关系相对而言是否是独立的。

产品越复杂,确定如何向用户提供良好的使用体验就越困难。

即使对信息拥有垄断权,不像图书商城那样有很多竞争对手,也依旧不能忽视用户体验

“特性”和“功能”总是重要的,但是用户体验对于客户的忠诚度有着更大的影响。

ROI:投资回报率,
一个最常用的投资收益的度量标准是转化率:有多少比例的用户被你转化到了下一步骤
3个注册并订阅邮件的用户/36个访问者=8.33%的转化率

那些不会被企业之外的人看到的网站(比如企业的内部工具或内部网站),用户体验仍然会造成很大的差异。一个是“为企业创造价值的项目”,一个是“变成资源消耗噩梦的项目”
以两种主要形式提高效率:1.帮助人们工作的更快2.减少他们犯错的几率
考虑用户的体验,把它分解成各个组成要素、从不同的角度来了解它
有粘性的、直观明了、甚至还让人愉快的体验——一次每件事都按照正确的方式在工作的体验

第二章 认识这些要素

表现层surface:一系列网页,由图片和文字组成。
框架层skeleton:按钮、控件、照片和文本区域的位置
结构层structure:(个人感觉框架是直观二维的结构,而结构层是多维立体的)框架是结构的具体表达方式,结构用来设计用户如何到达某个页面等。框架层定义了导航条上各要素的排列方式,允许用户可以浏览不同的商品分类,结构层则确定哪些类别应该出现在那里。
范围层scope:结构层确定网站各种特性和功能最合适的组合方式,而这些特性和功能就构成了网站的范围层
战略层strategy:经营者想从网站得到什么,用户想从网站得到什么
自上而下的建设
基本的双重性:功能型和信息型
《用户体验要素》读书笔记

战略层
挖掘用户需求——树立产品目标
范围层
功能型:功能规格 对产品的功能组合的详细描述
信息型:内容需求 对各种内容元素的详细描述
结构层
交互设计:系统如何响应用户的请求
信息架构:合理安排内容元素以促进人类理解信息
框架层
信息设计:一种促进理解的信息表达方式
界面设计:安排好能让用户与系统的功能产生互动的界面元素
导航设计:屏幕上的一些元素的组合,允许用户在信息架构中穿行
表现层
感知体验
应用这些要素
内容和技术两点仍旧不可或缺

一二章的思考

一二两章主要是分析了用户体验设计的重要性,然后粗略介绍了可以从五个层面来分解用户体验,绘制了用户体验要素的模型。从这个模型出发,反思我以前思考用户体验时候,基本只停留在表现层和框架层,偶尔涉及到范围层,比如《微信读书》表现层上“发现”页面的卡片式布局的简约、app配色的舒缓、以及适当留白的使用艺术;其框架层上的页面操作:左滑下一页,点击空白处显示其他相关的操作按钮。我在以前,除了这三个层面,其他层面的思考就比较少了,以后就会有意识的从各个层面切入,进行思考。
另外,五个要素也让我学会更清晰的去理解一个产品,从最抽象的战略层面到最具体的表现感知方面,产品更加立体化了,而不是一种很扁平的工具。

第三章 战略层

产品目标和用户需求
产品目标:我们要通过这个产品得到什么
用户需求:我们的用户要通过这个产品得到什么
关键词:明确
产品目标

商业目标

每一个我们做出的决定,都应该建立在我们确切的了解了他爱的影响力的基础之上

  • 品牌识别

经过产品设计者有意精心安排而不是让用户无意之中形成品牌印象

  • 成功标准——使战略目标得以量化

一些可追踪的指标
注,并非单次访问的时间越多越好。若想鼓励用户随意轻松发掘网站提供的服务,那么希望其时间长;但若想要提供快捷简便的信息或功能服务,或许会希望单次访问时间减少
印象数:你的网站上每一个广告的每天被展示的数量

任何断章取义的标准都可能造成误导;请务必后退一步,看看除了网站之外发生了什么事,以确定了解到事情的全貌。而不是看到回访率下降就怪罪于自己的产品设计本身

用户需求

抛弃立场的局限,从用户的角度来重新审视网站
询问他们问题,观察他们的行为

  • 用户细分

把大量的用户需求划分成几个可管理的部分——较小的、有共同需求的小组
1.市场营销人员通常按人口统计学的标准——但其世界观和感兴趣的事情往往不同
2.消费心态档案:描述用户对于这个世界,尤其是与你的产品有关的某个事物的观点和看法的心理分析方法
也要考虑用户对技术和网页本身的想法:对技术的熟悉程度和适应程度、他们对网站相关内容的知识有多少、

  • 可用性和用户研究

市场调研方法:问卷调查、焦点小组等等
现场调查
任务分析:仔细分解用户完成任务的精确步骤的方法
用户测试:请用户来帮忙测试产品
对于信息驱动的产品,卡片排序法用于探索用户如何分类或组织各种信息元素

  • 创建人物角色(又叫用户模型或用户简介)

人物角色档案

团队角色和流程

最了解客户需求的普通员工,常常被忽略(拟定决策时)
战略文档要简洁明了并切中要点
要与团队分享该文档

第四章 范围层

功能规格和内容需求

把用户需求和产品目标转变成产品应该提供给用户什么样的内容和功能时,战略就变成了范围。
过程有价值,还可以产生有价值的产品
过程的价值在于,当整个事情还处在假设阶段的时候,他能迫使你去考虑潜在的冲突和产品中一些粗略的点
产品的价值在于,被定义的这个产品给了整个团队一个参考点,明确了这个项目中要完成的全部工作,也提供了一门用于讨论这件事情的共同的语言。

用文档来定义产品需求

原因1:这样你才知道你正在建设什么
在了解了一个详细策划的完整范围之后,你就可以看到各个相对独立、也不显著的要求之间的内在联系。

原因2:这样你才知道你不需要建设什么
许多功能听上去都相当的诱人,但是他们对于项目的战略目标并不是必需的
提供一个评估这些想法的架构,帮助你了解他们时如何(或是否)满足你当初所承诺要做的那些事
当前难以满足的需求,可以成为启动下一个版本的基础,这样就能形成一个不断循环的开发过程。
范围蠕变

功能和内容

我们要开发的是什么?

内容管理系统(CMS)

定义需求

一些需求适用于整个产品,另一些需求只适用于特殊的特性
需求的三个主要类别:
1. 人们讲述的他们想要的东西
2. 有时候人们口中说出来的、所期望的特性其实并不是他们想要的,只是他们用产品时遇到困难,想象某种解决办法缓解这一困难的正常反应。这个想法有时候是行不通的
3. 人们不知道他们是否需要的特性
往往那些很少去想象产品新方向的人,恰恰是参与创建和涉及产品最深入的人
汇集各个部门成员或不同类型的用户代表进行头脑风暴会议。打开设计者思路
需求序列要考虑到硬件需求
即使不是产品的直接竞争对手也能提供丰富的潜在需求

功能规格说明

足够清楚和准确,
记下来的规则
乐观,描述这个系统要去做什么事情去“防止”不好的情况发生,而不是描述这个系统“不应该”做什么不好的事情
具体,尽可能详细地解释清楚状况,这是我们决定一个功能是否被实现的最佳途径
避免主观的语气,使需求“保持明确”和“避免歧义”的途径——因而也避免了误解的可能性。。功能规格必须可验证

好的例子:网站的外观应该符合企业的品牌指南文档
也可以量化的定义一些功能,通过这样的手段来避免主观性

内容需求

FAQ:常见问题
但FAQ的真正价值主要在于可以随时提供用户普遍需要的信息。
内容需求应该提供每一个特性规模的大致预估:文本的字数、图片的像素大小、下载的文件字节、PDF或音频文件等相对独立元素的大小等。
事先知道内容元素的大小,能让我们在这个设计过程中做出最明智的决策
尽可能早地确定某个人来负责每一个内容元素也是非常重要的
内容是一件艰苦的工作
进而需要定义每一个内容特性的“更新频率”
整理一个内容清单。通常采用简单的格式,即使很庞大

确定需求优先级

有时候一个战略目标会产生多个需求,另一方面,一个需求也可以实现多个战略目标
首先要评估这些需求能否满足我们的战略目标(无论是网站目标还是用户需求)。
除此外,第三种范围:实现这些需求的可行性有多大?
技术局限、资源不足、时间限制
留意看上去有可能需要改变战略的特性建议,若听起来不错,或许可以重新审视某些战略目标

与管理层的沟通技巧

第五章 结构层

交互设计与信息架构

在对于最终产品将会包括什么特性有了清楚的图像之后,需要为网站创建一个概念结构,如何将这些分散的片段组成一个整体
交互设计和信息架构都强调一个重点:确定各个将要呈现给用户的元素的“模式”和“顺序”。交互设计关注于将影响用户执行和完成任务的元素。信息架构则关注如何将信息表达给用户的元素。
它们要求去理解用户——理解用户的工作方式、行为和思考方式

交互设计

交互设计关注于描述“可能的用户行为”,同时定义“系统如何配合与响应”
以前,用户和软件的和平相处唯一方式:计算机基础培训
现在,交互设计力图设计一个对用户而言最好的系统
(以用户可以理解的方式来包装处理系统??将抽象的概念的功能抽象成对象。面向对象)

概念模型

用户对于“交互组件将怎样工作”的观点称为概念模型
软件是否把某个特性处理成用户所熟悉的某个概念?
例如,购物车

不必将概念模型明确的告诉我们的用户,事实上,这样做会让用户觉得很混淆。更重要的是,概念模型是用于在交互设计的开发过程中保持使用方式的一致性的
理想情况下,我们不需要告诉用户网站使用的是什么样概念模型:用户在使用网站时,基本上是凭直觉的,因为这个网站的交互行为与它们隐含的期望值完全相符。

不要将比喻从现实世界中一字不落的照搬过来。

错误处理

  1. 设计成不可能犯错的系统
  2. 使错误难以发生
  3. 有效的错误信息和容易自我解释的界面可以在错误发生之后帮助用户纠正

信息架构

呈现给用户的信息是否合理并具有意义
结构化内容
信息架构要求创建分类体系,这个分类体系将会对应并符合我们的网站目标、希望满足的用户需求,以及将被合并在网站中的内容。
两种建立分类体系的方式:
1.从上到下
根据产品目标与用户需求直接进行结构设计
先从最广泛的、有可能满足决策目标的内容与功能开始进行分类,然后再一句逻辑细分出次级分类。
局限:可能导致内容的重要细节被忽略
2.从下到上
根据对“内容和功能需求分析”而来
从已有资料开始,将其统统放到最低级别的分类中,再将它们分别归属到较高一级的类别,从而逐渐构建出我们的产品目标和用户需求的结构。
局限:可能导致架构过于精细的反映了现有的内容,因此不能灵活的容纳未来内容的变动或增加。
类别质量只要能正确地反应你的用户与它们的需求就可以了。
结构质量最重要的标准,不是“整个过程要多少步骤”,而是“用户是否认为每一个步骤都是合理的”,以及“当前的步骤是否自然地延续了上一个步骤的任务”

一个高效结构的优点就是具备“容纳成长和适应变动”的能力

(当你发现需要重新调整结构时候,用户常常已经被折磨了一段时间了)

结构方法
信息架构的基本单位是节点。节点可以对应任意的信息片段或组合。我们要处理的是节点,而不是页面、文档或组件
节点的抽象性使得我们能明确的设定我们的关注点的详略程度
常见类型:
1.层级结构(树状结构、中心辐射结构) 父节点、子节点
2.矩阵结构,允许用户再节点与节点之间沿着两个或更多的“维度”移动。
帮助有不同需求的用户,能在相同内容中寻找各自想要的东西
当然,超过三个维度的矩阵可能就会出现问题,人脑很难可视化这些高维的移动
3.自然结构 不会遵循任何一致的模式。节点逐一被连接起来,没有强烈的“分类”概念。
鼓励自由探险的感觉,比如某些娱乐或教育网站,但用户很难再次依靠相同的路径,去找同样的内容(因为结构不那么清晰)
4.线性结构

组织原则
节点在信息架构中是依据组织原则来安置的
决定哪些节点要编成一组,而哪些节点要保持独立的标准。
不同的组织原则将被应用在不同的区域和网站的不同的层面
在产品最高层级使用的组织原则应紧密的与“网站目标”和用户需求相关。而在结构中较低的层级,内容与功能需求将对你所采取的组织原则产生重大影响
·例子,展示汽车信息的网站,第一考虑重量还是外观、型号和类型
这些属性,在图书馆学的术语中,称为截面
一种常见对策,将每一个有可能的截面都当作组织原则来使用
但,使用错误的截面可能比根本没使用截面会更加糟糕
另外,将“让用户自己使用所有的属性来排序,并且挑选什么是重要的”这种负担不应该丢给客户。
战略告诉我们“用户的需求是什么”,范围则告诉我们“什么样的信息将满足那些用户需求”。在创建结构时,我们就要具体地识别出用户心目中至关重要的那些信息。
成功的用户体验,就是能事先预知用户的期望并将其纳入设计之中。
语言和元数据
即使结构完全准确地代表了用户对你的网站地理解,用户仍然无法在结构中找到他们想走的路,因为他们无法了解你的命名原则:描述,标签,和网站使用的其他术语。
“使用用户的语言”并且“保持一致性”非常重要
用来强调一致性的工具称为受控词典:网站使用的一套标准语言
反应用户语言,让用户感到自然的命名
控制词汇的另一种较为精细的应用方法,就是创造“类词词典”其提供常用的、但未纳入该网站标准用语的词汇以供选择。
元数据,“关于信息的信息”,一种结构化的方式来描述内容的信息
掌握的内容信息越详细,在建设信息架构时灵活性就越高。

有了受控词典,在内容中,每一个独特的概念都对应了一个固定的词,通过这种对应,就可以依靠自动化来帮助你定义内容元素之间的联系。你的网站可以动态的将一组与某个主题有关的页面链接到一起,没有任何人需要额外做什么,只要它们的元数据始终一致地使用同样地词组。

好的元数据比基本地全文搜索引擎更能提供可靠地搜索结果。因为后者并不了解字符串地意义,只是寻找一模一样地
将搜索引擎与类词词典联接起来,再加上元数据,就能让搜索引擎变得更聪明。
搜索引擎使用类词词典来区分“禁用词”与“首选词”,接着它从元数据中查找这些“首选词”

团队角色和流程

文档一定要描述清楚网站的结构——从命名原则和元数据的具体细节,到信息架构和交互设计的整体概况——根据项目复杂度的不同,可以有很大的不同。
信息架构或交互设计的主要文档是示意图。
架构图,内部用来描述这种网站结构工具的术语
最重要的是记录概念关系:哪些类别需要放一起,而哪些需要保持独立?在交互过程中那些步骤要怎样相互配合?
“视觉辞典” 图解网站结构
信息架构与交互设计非常相近且相关,“用户体验设计师”
若网站需要稳定而持续地增加新内容和新功能,那么可以招聘一名全职地信息架构师。

第六章 框架层

界面设计、导航设计和信息设计

在充满概念的结构层中开始形成了大量的需求,这些需求都是来自我们的战略目标地需求。在框架层,我们要更进一步提炼这些结构,确定很详细地界面外观、导航和信息设计,让晦涩地结构变得更实在。

框架层定义

结构层界定了我们的产品将用什么方式来运作,框架层则用于确定用什么样的功能和形式来实现。
关注点在独立的组件以及它们之间的相互关系上。
界面设计:框架——做某些事
导航设计:用于呈现信息的一种界面形式——去某个地方,用户可以在结构中自由穿行
信息设计:呈现有效的信息沟通——传达想法

习惯和比喻

界面与用户早已养成的习惯保持一致很重要,但更重要的,界面要与它自身保持一致。
网站特性的概念模型有助于你保持内部一致性。
若两个特性使用同样的概念模型,那么它们很可能会有比较类似的界面要求
不应该过于强调交互设计背后的概念模型,同样,应该抑制在产品四周建立起比喻的冲动

界面设计

选择正确的界面元素
让用户一眼就看到“最重要的东西”的界面设计
好的程序员是平等对待每一种可能性
但界面设计不能将极端情况呈现出来
一个技巧,在界面第一次呈现给用户的时候,仔细考虑每一个选项的默认值
另一个更好的做法,是能自动记住某个用户最后一次选择状态的系统。但技术实现可能困难
学习相对较小的标准控制方式的用户,可以把他们的知识应用到更大范围的产品中去。
复选框、单选框、文本框、下拉菜单、多选菜单、按钮

导航设计

  1. 提供在网站间跳转的方法
  2. 元素和它们包含内容的关系
  3. 内容和用户当前浏览页面的关系
    全局导航
    局部导航
    辅助导航
    上下文导航,嵌入页面自身内容的一种导航
    友好导航
    远程导航:工具一网站地图
    索引表

信息设计

有时是视觉上,有时涉及“分组”或“整理”散乱的信息。
最关键的,使用一种能“反映用户的思路”和“支持它们的任务和目标”来分类和排列这些信息元素。
指示标识

线框图

《用户体验要素》读书笔记

第七章 表现层

感知设计

内容、功能和美学

表现层定义

在框架层,主要解决放置的事情。界面设计考虑可交互元素的布局,导航设计考虑在产品中引导用户移动的元素的安排,而信息设计考虑传达给用户的信息要素的排布
在表现层解决并弥补“产品框架层的逻辑排布”的感知呈现问题。

合理设计感知

视觉

忠于眼睛

用户眼睛的移动轨迹的模式的特点:

  1. 遵循一条流畅的路径
  2. 为用户提供有效选择的、某种可能的“引导”。

对比和一致性

基于栅格线

内部和外部的一致性

设计一些反复出现的设计元素
品牌识别的一致性

配色方案和排版

特殊字型

设计合成品和风格指南

视觉模型

风格指南

第八章 要素的应用

提出正确的问题
比用户自己更准确的理解他们的需求

相关文章: