Communicating Design

ABOUT

这是一本关于交互设计基本的工作流程的书。书中介绍了基本的工作流程，以及流程需要使用的工具。对于工件的介绍，作者通过描述工件是什么，工件的作用和制作目的，以及制作工件，在制作完成之后如何召开工件的评审会议，以及如何提升工件的制作技巧，和如何避免一些新手的错误来展开，以及如何使用工件。

1. 简介

交付件和设计流程1. 理解领域：每个领域都有其特定的用户、术语、内容之间独特的关系、基本的和隐含的功能。

1. 表述问题：即对定义清楚用户的需求。
2. 解决问题：也就是设计产品。* 选择正确的交付件设计的过程是生成网站的过程，而不是生产交付件的过程。

2. 图表使用基础

设计图标分析每个图表从概念上可以划分为三层：

1. 基本要素：图标中最核心，不可或缺的部分。
2. 详细阐明：使用文字来阐述一些细节的描述，比如项目意图和必要条件等。
3. 背景与联系：将文档与其他部分联系起来的背景。* 创建设计工件1. 思考目的：思考产品的目的，以及这份工件的目的是什么。其中的一些目的包括：网站当前的运行状态、当前的一些设计问题、介绍设计理念。
4. 设计计划：设计计划讲的是::需要什么人来达到什么目的::，交付件只是活动的副产品。确定了计划的目标，就可以确定适合的交付件。
5. 思考受众：这里的受众实质具体使用工件的人，他们需要什么，概况还是细节。
6. 思考内容：确定适当的内容包括三个方面：内容具体到什么程度、对目前可获取信息的理解、该设计阶段最需要什么。* 制作图表的技巧1. 列出可能包含的信息
7. 草图
8. 反馈草图
9. 重复修改
10. 尝试不同的方法
11. 打乱材料的顺序
12. 谨慎使用色彩
13. 使用惯用语
14. 重新检查输入
15. 不断进行标注* 交流设计时的挑战1. 现状、近期目标与最终目标：通过产品的演变图来阐述背景和目标；如果需求是持续的，使用视觉效果，突显设计修改的地方。
16. 细节和复杂度：对于细节和架构的平衡，使用两个团队来进行；架构团队及早参与项目，并在后期包装框架的完整性；当框架问题解决后，细节团队开始参与，并提供见解。
17. 产品和使用环境：沟通设计的挑战在于把你能够控制和不能控制的事物区分开。当遇到一些风险的时候，需要提前沟通。* 展示设计1. 建立背景：确定对话目标、确定关键点、提醒参与者设计问题和原则、把用户加入到讨论中。
18. 阐述视觉惯例：
19. 突出主要的设计决策：包括设计风格、用研结果、站点地图的结构、流程图中的关键视图。
20. 提供基本原理和识别的约束条件：约束条件的思考范围：用户研究、项目目标、项目参数、技术实施、业务实施、行业标准、组织标准、设计原则。
21. 指出细节
22. 交流心得
23. 征集反馈信息
24. 提供一个评审的框架：

3. 人物角色

人物角色是描述目标用户的一种框架，帮助设计者更好的理解用户。 人物角色是一种虚构的用户，即哪些有共同特征的用户组，根据用户的行为目标以及他们对目前使用产品的期望进行描述。 一般有三种方法定义用户角色：

1. 数据驱动
2. 基于组织
3. 基于过程

内容：人物角色解析

构建人物角色时，关键是考虑人物角色包含多少种信息，一般有三层信息：

第一层：确定需求

人物角色的数据是实际应用的基础，用来确定用户需求。

1. 角色名字可以是真名、描述了角色或目标的名字、使用主要数据命名、使用和组织相同的名字、名称能够反映不同生命周期不同阶段的主要任务。2. 主要特征一两句话来概括用户特征，为什么和其他用户不同。3. 描述性维度我们需要了解用户的知识，用户可能的做法以及他们想要达到的目标。可以从以下几个维度来描述用户：

知识、任务、兴趣、特征

1. 目的和动机这些目标是用户在与系统交互时所希望得到的结果。5. 来源人物角色的数据点，必须标注其数据来源，即使是内部讨论或领导意见也要标注。*** 第二层：细化关系

1. 关注点：用户所关心的问题记录影响用户体验的关键，了解用户与系统的之间的关系， 包括系统之外的体验。* 2. 场景和情况场景能够帮助我们跳出对系统的思维，转而从用户的实际情况考虑问题。

对用户来说， ::信息是作出一项决策的诱因:: 。一个基本的场景包含以下 5 个部分： 上下文环境：场景的起始点，标示场景初始阶段用户的位置。 触发器：引起场景发生的事件。 动作：用户在场景中的行为。 输入数据：用户必须提交给场景的信息。 期望：情况如何发展才能满足用户的需求。* 3. 经典语录用户的经典语录可以帮助我们更好的理解用户与产品之间的关系。*** 第三层：使人物角色生动

1. 个人背景

2. 照片

3. 系统特性将系统功能与用户角色的动机相匹配，找出没有用户基础的功能。* 4. 人口统计学信息

5. 对技术的熟悉程度

制作：创建人物角色

人物角色的基本决策

判断何时来制作人物角色要考虑三方面因素：

1. 目的：创建人物角色的目的

有三个主要目的，制定需求、验证设计（人物角色可以帮助做决策）、假设研究（对人物角色的讨论可以帮助稍后做用户研究，研究者了解研究方向）。

1. 时机：创建人物角色的时间

单独的项目：在做人物角色的时候不要拘泥于某个项目，要保证在以后的项目中也可以用到。 设计项目之前：创建一些积极和消极的约束条件。 ::如何理解约束条件？::

1. 受众：人物角色的使用者

如果手中不熟悉人物角色，也可以通过设计决策的问题来创建用户决策。

润色人物角色的小贴士

1. 创建人物角色概要

从较高的层面来构建人物角色，包括： 名称和角色、照片、经典语录、最大的痛点。

1. 说明人物角色之间的关系

对人物角色进行分类之后要理解分类之间的关系。递进关系还是层次关系。 递进关系：按照用户熟练程度来区分。 层次关系：按照用户类型逐步细分。

1. 方便人物角色之间的比较

包括需求、关注点和任务之间的差异表现。 其目的包括：* 内容或特性具备实用性 通过人物角色和产品功能的二维对比，来了解功能是否覆盖全，以及是否有多余的功能。

为用户调查提供机会

如果有些特性无法覆盖，这就可以为之后的用户调研提供帮助。

使用两种维度

从两个维度来区分用户，最终把用户划分在两个象限当中，他们之间的不同可以从不同的维度来描述。

使用合适的维度

维度尽量选择有多个可选值的维度，而不要是「是/否」的二元维度。

互相保持独立性

两组用户必然是独立的，不会有交叉。

对设计师具有指导意义

这些维度必须对设计师来说有意义。4. 显示心理模型 心理模型包括按照用户故事分解的用户任务，以及网站的内容和功能。根据二者的契合度来调整。

提高人物角色的技巧

制作人物角色的时候要注意以下问题：

1. 包含有使用价值的信息
2. 引用一些资源
3. 准确的再现实际情况
4. 使人物角色保持简洁

展示：表现人物角色

一、确定会议目的讨论 Persona 的主要原因是为了提炼出一些信息。* 1. 讨论对 Persona 的描述从三个部分来讨论用户角色的描述：

已有知识的澄清：在反馈会议室，澄清当前已有知识是否都有体现在 Persona 当中。 调查结果的分析：没有经过调查分析的用户描述是不可靠的。 优先权：可以使用用户角色对产品需求进行排序。* 2. 设计评审中的人物角色使用人物角色来精简用户研究范围或修改设计方案。此时需要包含的人物角色信息： 主要的用户需求、表示人物角色与设计之间的关系、更新的内容。* 3. 介绍人物角色想不了解人物角色的人介绍人物角色的价值时应考虑以下几点：

1. 用户需求驱动设计
2. 我们需要更多的用户信息
3. 我们没有掌握需要的信息，市场调研仅仅是为了了解用户的需求，但是不了解用户的行为
4. 我们不是为了调查而调查
5. 最低限度*** 二、调整基本的会议模式除了前面提到的讨论方式，还可以按照顺序来讨论人物角色。

当你需要将用户需求转化为系统功能，可以按照重要性分别描述每个人物角色，描述重要性排序的标准。 当你需要查找人物角色可能存在的交集，可以描述用户的行为范围，然后说明人物角色如何对应需求。 当你需要告知如何创建人物角色，可以从初期的调研结果开始，像受众表述如何从数据变成人物角色。* 1. 描述 Persona 的重要性及创作过程说明人物角色的重要性，以及其信息来源：基本研究、次级研究还是采访用户代理等。* 2. 按照视觉管理描述 Persona

3. 强调主要的设计决策人物角色本身不具备「设计决策」* 4. 提供基本原理，确定约束条件必要时可以详细说明人物角色的方法论。但要注意以下问题：

1. 不要在方法论上花费过多时间
2. 你可能需要证明你的理由
3. 用户调查并不是面面俱到* 5. 描述细节信息最好在 30 分钟内描述清楚 Persona* 6. Persona 如何确定设计

可以得出以下几点：

1. 公共需求和设计原则
2. 不同人物角色的需求之间所产生的冲突，以及记录这些挑战。

将所有的维度链接起来，可以表示用户组如何对应到模型中的每个行为。* 7. 征求反馈确定一种范围和需要的反馈类型，一般包含以下几点：

1. 细分模型：如何划分目标对象
2. 优先级：如何排序
3. 行为维度：是否还有其他重要行为
4. 描述性元素：人物属性对设计的影响 * 8. 提供评审框架让所有人之后继续思考两个问题：
5. 如果你可以问用户一个问题，你会问什么。
6. 在设计过程中面临的最大的挑战是什么。*** 三、描述人物角色

1. 把人物角色看作真实的人 * 2. 人物角色的特性 *** 四、避免出错

1. 人物角色影响设计过程

2. 人物角色是设计工具

3. 用好研究结果在会前发研究结果，可以避免人们对 Persona 的不理解。* 4. 预见关于方法论的争议人们会对调查的方法产生质疑，多半是以下几点：

1. 用户数量
2. 调查的用户类型
3. 招聘人员
4. 调查不足
5. 数据收集方法* 5. 改变团队的文化氛围要引导与会成员将会议的主题集中在会议目的上。** 实践：人物角色在实际中的运用

人物角色提供解决下列问题的方法：

1. 优先级：哪些特征或内容是最重要的；

2. 验证：是否包含某种特征；

3. 完整性：是否还缺少某些特征或内容；

人物角色和设计文档

在文档中使用人物角色的名称来说明特定的设计决策是如何支持特定的用户需求的。

人物角色和设计过程

人物角色是讨论用户的时候的基本语言。

1. 人物角色帮助用户具体化

2. 人物角色帮助确定设计工作的重点

3. 人物角色帮助组织确定以用户为中心的决策* 4. 概念模型

概述

介绍：在概念模型中，所有的节点都是名词，所有的关系都是动词。「节点-链接-节点」形成一个主谓宾的句子。 受众：设计师 规模：分析网站的数据，取决于网站的规模。 何时开始：在设计阶段开始前就要创建概念模型。 借助概念模型，设计师可以了解：

1. 如何把内容相互连接起来
2. 如何在网站的各个位置展示内容
3. 每个概念应该包含哪些信息
4. 不同类型的交互用户可能需要不同类型的信息
5. 不同类型的内容或特性具有相对优先权
6. 那些概念是网站的核心概念
7. 那些概念将提供浏览其他信息的上下文

作用

理解网站需要显示的不同类型的信息。也可以确定项目的研究范围和产品的框架。 有助于确定模版、组件、模块、导航、元数据以及内容管理系统基本结构的策略。 概念模型帮助我们进行思考，有助于解放自己的思想。 概念模型能够明确信息域，用于形成结构化的分类和关联关系。它的优点在于无需建立领域概念的层次关系。 概念模型确立了一个词汇表，用于探讨内容的结构，以及如何在站点的不同部分及不同的烦事对他们进行排版。

别名

Concept map

挑战

分析瘫痪：明确概念设计的目的，而不要为了设计而设计。

实用性：知道什么时候停止，知道什么是有用的。

远景：概念模型使用的概念比较单一，如果从多种角度理解，那么会更有意义。仅仅是意识到要从多个角度理解就很好了。

内容：概念模型解析

概念模型能够明确信息域，用于形成结构化的分类和关联关系。它的优点在于无需建立领域概念的层次关系。

第一层：基本元素

两个接本元素：节点和连接。 节点表示名词，连接表示动词，用来表示节点之间的关系。

节点使用时要注意以下问题：

1. 节点都是名词
2. 使用复数
3. 可以举例，但是要写明副标题* 连接标记连接时要注意：
4. 记住，要使用动词
5. 要避免使用「属于」
6. 避免模糊的修饰词
7. 避免构造多节点关系语句*** 第二层：添加更多细节

根据类型和背景区分节点

关系分支在设计中会出现概念与子概念的关系，在使用时要注意：

1. 子概念是概念的描述。
2. 子概念代表概念的不同状态和条件。* 直接宾语和间接宾语连接两个节点分别是句子的主语和宾语：主语作用于宾语。

模型的中心思想必须明确，中心思想在某种意义上确定了节点间的关系。 在不涉及其他名词的情况下不能描述清楚关系，就需要用颜色标示出来。* 根据类型和背景区分节点

关系分支

直接宾语和间接宾语

第三层：从模型到插图

如果要把模型展示给其他人，通过插图可以让受众更易理解。

增强细节对比度

找到一种隐喻通过比喻，我们建立域与域之间的映射关系，基于映射的知识得出目标域的推论。* 作为背景的概念故事的关键时连接中心思想和细节的桥梁。* 简化情节少量的概念使你可以集中精力表示概念间的关系。有两种简化的方法：

1. 聚焦局部：一个好的模型可以显示表面上看似无关，实则有关的内容。
2. 聚焦更高层次：从主要概念开始。* 增强细节对比度

找到一种隐喻

作为背景的概念

简化情节

制作：创建概念模型

在制作时，对目的、使用者和内容做一些基本的判定，可以确定模型的重点。

基本决策

1. 目的不同的设计阶段，有不同的目的。可以告诉我们这个阶段应当做什么。2. 受众设计师自己3. 包含内容通过 4 种标准来衡量是否应当把概念加入：
2. 对用户的重要性
3. 对相关人员的重要性
4. 有意义的里程碑
5. 提供洞察力

在标注的时候，应当以这样的方式标注：

1. 强调主动动词：使用主动动词说明一个概念如何影响其他概念。
2. 激发界面动作：假设所有的概念最终转换为网站上的信息，所有连接都反映了用户的界面操作。4. 如何布局有三种典型的结构：
3. 中心辐射型：从一个概念控制其他所有概念。
4. 对称、三角形、四边形：有两三个概念的集合定义主结构，其余分支从该组概念中延伸出来。
5. 价值主张型：三四个节点构成一个橘子，作为图表其他部分的骨架。*** 完全透明的概念模型的提示
6. 进行调查

通过了解公司业务来深化对问题域的理解。

1. 深入探究用户研究中可以得出对用户有用的概念。

如果没有思路，就选择一个节点，然后问自己： 这个概念有什么特别之处。 如何描述这个概念 这个概念如何影响其他概念3. 移动节点 移动概念来了解概念之间的新观念。

1. 建模后再修剪

为了减少概念间的连接，需要查看模型中的三角形连接。节点间的三角形连接是其中一个是多余的。 为减少节点，要去除那些表达乏力、不足以作为概念间桥梁的词语。

提高概念模型的水平

1. 汇合：将所有的内容都链接到一个概念上

如果你需要重复同一个概念，那这个概念就不适合作为描述域的工具。

去除中心概念

采用价值主张型结构

1. 保持概念的正确性

概念的最终目的是解释问题域。 经验表明一个模型中的概念不应该超过 24 个。

1. 保持模型的实用性在将模型组合前继续问自己以下问题：

这个概念同目标对象相关吗？ 这个概念对业务有多重要？ 哪些关系是受众优先关注的？ 我能想象出这些概念是如何转换成界面元素的吗？ 我能想象通过用户调查可以帮助我验证这些概念吗？** 展示：推介概念模型

确定会议目的

目的只有两个：

1. 设计的准备工作此类会议要包含 3 种关键信息的一种：

这是有用的练习，因为…：确信你已明白概念模型时如何域设计过程相契合的，以及下一步如何设计概念模型。 初始设计准则或要求：准备几条对概念模型的见解作为会议讨论主题或切入点。 关于范围的其他问题：突出模型中仍不清楚的部分或项目中存在疑问的部分。2. 共同建模会议上确立 3 项关键主题： 确定问题域的范围。 关注模型中遗漏了什么内容。 抽象思维很困难。*** 调整基本的会议结构

1. 建立上下文环境

说明概念模型对设计的作用

1. 描述视觉规则

说明概念模型中图形表示什么

1. 强调主要的设计决策深入分析模型之前，先从 3 方面介绍概要信息：

总体结构：介绍 3、4 个主要模型，描述关系及如何构成整体。 统一主题：介绍概念模型基本的主题。 包含哪些内容，去除哪些内容。 在继续之前，描述概念模型的创建过程，说明其价值。可以概括为以下几点： 用户体验必须的型概念：可以反映用户的信息、或表示合并了其他概念的分类。 概念之间的新关系：清楚的表示优先级。 用户体验的新观点：偶尔会从概念模型中发现新的想法。4. 提供基本原理和确定限制条件 反复重申概念模型的目的及作用。

1. 解释细节信息

当希望得到更深层次的反馈时，才可以从细节入手。

1. 表达的含义首先要明确模型所包含的内容：

充分理解域 充分理解目标对象 需求的优先级列表 潜在风险的列表 可能的屏幕的列表7. 征求反馈

1. 提供评审的框架

介绍的风险

1. 可能的反应「我不知道想要什么」

概念模型可以呈现对信息的归类，或者是细微的几块数据，或者元数据信息。 介绍时，不妨把概念模型的内容压缩成 3 句话。

1. 可能的反应「那又如何」

这种情况要么说明概念模型与设计的关系，要么直接结束会议。

实践：运用概念模型

为其他交付件提供情境

从模型到屏幕

概念模型应该设计一个域，可以很好的控制网站需要表达的信息的范围和深度。

1. 概念就是屏幕

概念中的任何节点都可以作为屏幕

1. 概念就是元数据

有些节点是描述性的，提供了概念的细节信息，这些都是一些有用的信息，但是不能作为导航。

1. 形成框架的模型

概念模型作为网站基本框架的基础：每个主要概念都可转化为模版，每个概念之间的连接对应模版之间的连接。

1. 关系就是交互作用

概念之间的关系可以转化为交互作用。模型中的动词可以直接转化为用户在网站上执行的动作。

概念很重要* 5. 站点地图

1. 概述

站点地图表示一个网站中数据的层级体系。 **目的**：

1. 澄清数据的层级体系：确定内容的存放位置以及如何分类。
2. 建立导航框架：站点地图可以表示网站的主要结构。
3. 方便内容移植：方便将网站的内容从旧版映射到新版。

**受众**：

1. 设计人员和开发人员
2. 项目经理

**规模**： 站点地图是一种需要不断修改的图表，是一个产品生命周期内的活动稳定。 **何时使用**： 首先，基于内容的审查及过确定新结构，或者创建当前网站的结构。 **格式**： 由表示站点不同区域的方框组成，通过线连接在一起。

1. 作用

站点地图在很多地方都有作用：

1. 描述导航策略

导航策略描述一个或多个系统，用于浏览网站的内容。

1. 描述分类策略

分类策略建立了分类信息的框架。站点地图有助于可视化通过分类策略所得到的架构。

1. 验证内容策略

内容策略描述了哪些内容放在哪些问题。 内容策略可以使用站点地图查看所有需要填补空缺的内容。

1. 便于内容迁移

站点地图允许将以前的内容映射到新的内容，有助于推动该过程。

1. 发现以上过程的问题

通过描述站点在当前状态的结构，可以发现导航、分类和内容策略目前所面临的问题。

内容：站点地图的结构

第一层：方框、箭头和一点其他内容

用以展示用户是如何在信息层级结构中导航的。

1. 页面和模版

只有一个页面；页面组；资源；类别。

1. 链接

网站的页面和模版之间的连接需要确定是显示层级体系还是导航关系。

1. 布局

如果站点地图想要表示严格的层级体系，采用类似企业组织结构最佳；如果是表示导航关系或不严格的层级，可以考虑不和网格对齐的布局。

第二层：详细描述页面和链接

1. 页面的详细信息和区别页面详情和区别主要是以下内容：

全局导航条目 模版类型：网站地图可以从外观上区分节点，表示正在使用的模版。 行政或管理问题：当企业行政上的变动比网站内容还快，最好明确内容和支持内容的用户之间的关系。 部分页面或部分元素：可以把页面元素当作一个节点，但要区别于整个页面本身。2. 页面分组虽然站点地图通过分层连接显示类别，人仍有其他方法对它进行分类： 页面池：类别页和内容池之间的链接表明类别可能链接内容池中页面。 功能组：可以将相互之间有关系的页面分为一组，他们有相同的目的。 上下文背景组：一组页面可以获得相同的外部上下文。3. 其他连接可以考虑以下链接： 其他连接：网站中的一些交叉链接。 上下文设置链接 页面组链接 出现在：有些节点表示部分页面或页面组件。*** 第三层：提供更多的背景信息 这一层提供了网站的结构信息的上下文。指的是项目的其他方面，包括内容和编辑策略、商业目标和技术约束。

1. 项目管理和规划项目管理的问题包括：

优先级 顺序 所有权2. 内容和编辑策略 如果信息架构的重点是体验的机构，内容战略就主要讨论体验的用户。

重点：该页面最重要的内容是什么？内容策略需要确定如何对内容进行排序。

更新：另一种区分页面的方法是通过它们的编辑周期。

资源：内容移植的理想的标签、内容类元都可以作为特定 URL 的注释。

1. 用户需求

站点结构和用户需求的关系可以为站点地图定义的方法提供依据。

制作：创建站点地图

1. 站点地图的基本决策

1. 目的和时机

站点地图显示了设计过程中的两种状态：目前的状态和将来的状态。

1. 受众

设计师、开发人员

1. 内容的形成

创建站点地图之前，创建一个你想记录在文档中的所有页面的列表很有用。 站点地图中的节点都表示用户体验的离散部分。 每个节点的关键参数是抽象层次，该参数的数值分布在两个极之间： 节点完全是结构型的，还是一部分特定的内容是。 决策就是一种设计：信息架构的工作就是计算需要创建有效体验的模版的范围和深度。 信息架构的抽象程度越高会有两种风险：

1. 异常：分类的实例可能存在异常。
2. 补充文档：可能需要一些补充文档指定确切的内容。

2. 星型站点地图的技巧

这些技巧可以帮助扩展站点地图，脱离单调的表达形式。

1. 等距布局这种结构加强了站点的分层机构。以下两种情况适用：

显示层级体系。 显示目前的状态。2. 可视语言 可视语言是创建站点地图形状的模版。 模版有助于保持不同站点和图表的一致性。

1. 大型地图

在绘制不规则的站点地图时，可以将它拆分为几个不同的文档页。

3. 提供站点地图的绘制水平

1. 仅显示必要的连接
2. 将差异最小化
3. 过分简化

展示：站点地图评审会议

1. 确定会议目的

一般有两个目的：

1. 站点地图都包括哪些内容
2. 站点地图中遗漏了哪些内容

2. 评审会议流程

1. 情境说明说明当前的情况及会议目的。2. 解释图表含义
2. 强调主要的设计决策主要的设计决策通常是关于结构的，选择哪种类别，以及如何选择。4. 提供基本原理和确定限制条件遗留的 CRM 会对内容的结构产生限制，技术原因也会有一定的限制。

在公司内部的政策上，也会造成限制。 需要记录下所有的这些限制。5. 解释细节信息深入分析具体实例，包括以下几点内容： 内容之间的连接； 分类和标签 模版选择 异常：注意脱离设计原则的结构决策6. 表达含义如果站点地图要使用一种新的设计决策，应该注意以下内容： 补充内容：修改结构意味着更新并补充内容。 依赖性：网站的有些却与需要在项目早起开发完成。 模版更新：开发需要通过模版更新信息，了解哪些地方需要更新。 操作的影响：设计结构可能会不断生成新的内容。7. 征求反馈征求意见分为两类，主要集中在 5 个方面。8. 提供评审框架会议结束时要完成这些事情： 确定用户应该关注的范围。 列出剩下的问题，尽量描述清楚。 确定一个符合实际情况的期限。*** 3. 避免新手错误

1. 使用标签多数时候我们不会讨论标签，因为标签只是暂时的。2. 层级体系的性政策路可能会出现的问题：

内容不属于企业自身 确定每个页面的期望 并不是所有内容都可以通过主页进行链接 用户不通过主页进入网站，例如搜索引擎 有多个导航系统 利用实例说明** 实践：使用站点地图

1. 规划项目

规划网站意味着确定「我们要做什么事情，以及何时开始做这些事情」。 规划很大程度上取决于「依赖性」。依赖性可以确定顺序和范围：在给定的区域中，需要创建什么内容、何时创建、需要创建多少内容。 站点地图通过绘制站点和模版之间的连接说明依赖性。

2. 站点地图和线框图

可以使用站点地图和其他图形显示站点结构。例如在线框图中，利用站点地图展示页面所在的位置。

站点地图的难题

不要过分强调内容或分类，而是突出模版的重要性。* 6. 流程图

1. 介绍

流程图向团队成员展示了用户完成具体任务的全部过程。 受众：对开发人员来说，就是系统逻辑的概述 对于设计师来过用了规划屏幕设计 也可以用来做用户测试2. 作用 在设计初期：

网站提供的任务类型

不同人如何协作完成任务

进入站点后如何展现信息

在设计过程中：

用户完成任务所需的界面

展示整体应用的框架

流程图必须展示用户和网站之间的进展和互动信息。

捕获设计决策

反应对现状的理解

内容：流程图解析

流程图必须包含开始、中间和结束。中间部分展示了用户完成任务和到达终点之间的路径。 流程图分为三层，第一层必须，后两层可选。

必备内容

1. 步骤

步骤包含两个部分：

1. 征求和收集部分：用户输入信息
2. 响应和指示部分：响应用户输入

步骤的标题，可以考虑使用动宾结构

2. 起点和终点

最好使用粒度来描述步骤，而不是页面或者界面。

3. 路径

一些注意事项：

1. 不要交叉连线
2. 使用带箭头的连线
3. 强调主要结构
4. 使用直角直线

4. 决策点

决策点的条件多数是「是或否」来回答。 决策点考虑一下准则：

1. 集中决策点
2. 按相同的格式描述决策点
3. 决策点可以超出二元条件

5. 名称

流程的标题，最好使用用户故事。

更多细节

1. 步骤之间的区别

有时候需要特别标记一些步骤：

1. 非常重要的步骤
2. 主要路径和次要路径
3. 流程保护可选操作

2. 步骤细节

有时候需要展示步骤的细节（页面信息图）的方式。 页面信息图中，并不是所有的元素都需要展示，一些对页面内容没有影响的元素可以不展示（例如：提交按钮）。

3. 路径的细节

两种情况需要特别说明路径：

1. 在决策点：用户的操作会出现分支
2. 状态变化：例如任务的转移，有时候需要用到泳道图来说明

4. 泳道和其他分组

泳道的优势在于过程可以描述多个角色。 使用颜色分组：

1. 开发角度，开发需要知道哪些地方修改了。
2. 页面来自不同的内容管理器
3. 开发需要知道一些错误页面
4. 用户在不同状态下的同一个页面
5. 策略角度：有些屏幕可以作为广告
6. 可用性角度

5. 错误路径

流程图应当可以区分不同的分支

情境说明

1. 连接到其他流程

将大的流程图拆分

2. 用户动机

在不同级别的流程中对用户动机进行描述

3. 界面标识符

用来标记独特的界面，方便沟通

4. 其他问题

制作：创建流程图

设计方向

1. 用途

流程有两个基本用途：

1. 捕获设计决策
2. 反应对现状的理解

2. 适应过程

适应过程：

1. 流程图可以记录在设计过程中的一些上下文信息

3. 受众

4. 内容

设计的早期阶段，流程图会比较抽象，用于帮助自己理解产品。随着项目的发展，流程图变得具体。 在决策、目的和受众明确之后，你可以把要展示在流程中的对象列一个清单。

5. 构建方式

流程的结构、节奏和顺序完全取决于你。有两种常见的结构，所谓结构就是模式，模式就是思考过程的典型方法。

1. 单向流程：每种选择都把用户带入唯一的路径。
2. 多向流程：用户可以选择多个可选的流程。

提升流程图

1. 从关键页面开始

2. 保持布局简单

3. 确定视觉语言

4. 简化负责流程

5. 构建框架

一个框架就是所有屏幕组成的网络，这些屏幕允许用户完成多个任务。

提升绘制技巧

1. 捕获所有细节以下方法有助于捕获所有细节：

让其他人查看流程 尝试设计不同的流程2. 表示实际情况流程会消除环境差异，一些消除策略有以下几个： 将流程与需求联系起来 在流程中嵌入人物角色 流程不是终点，继续前进3. 更新文档首先要判断是否有必要 如果作为系统文档的一部分，那么才有必要。 要注意以下问题： 保持简单 备份原版** 5. 流程图评审会议

确定会议目的

主要三个目的：

1. 评价现有设计目的是验证屏幕的顺序、用户体验的逻辑是否正确。

需要讨论以下内容： 设计原则，说明指导整个设计过程的决策。 与流程图相关的关键需求 用户的流程复杂度 技术的风险2. 技术可行性从技术的角度来验证方法： 需要讨论以下内容： 流程中的依赖关系 复杂的交互方式 与之前版本的变化 流程的优先级3. 组织是否支持关注流程能否正确的反应现实情况，需要讨论以下内容： 从不同的角度讨论一个流程 用户操作的复杂度 决策来源*** 确定会议流程

1. 介绍流程图及现状说明流程，并用一两句话来总结流程图，需要说明以下内容：

用户需求如何在流程图中展示 流程图如何支持业务目标 技术的可行性 澄清问题 流程图如何满足公司内部的希求2. 描述视觉规则

1. 强调主要的设计策略

需要描述流程的主要特征：

1. 交互横型：指出叫之间的区分，单向还是多向。
2. 高级过程：分组、泳道这些方法来在更高级别上描述流程。
3. 提供基本原理和确定限制条件

引用用户研究的资料，说明设计方案

1. 指出细节信息

从头到尾沿着没有分支的理想路线来遍历整个流程

1. 说明设计原则
2. 征求反馈意见可反馈以下内容：

逻辑是否正确 步骤是否有遗漏 有没有更高效率的方法8. 提供评审框架 与技术人员确定风险

避免新手错误

1. 将抽象的内容具体化
2. 保持灵活性

6. 使用流程图

1. 规划型流程图

用于规划的流程图需要满足：

1. 避免挖掘逻辑上过多的细节问题
2. 展示用户体验来调整项目安排

2. 流程图与线框图

3. 流程图与人物角色

7. 过程的深层次

开始应用程序设计* 7. 线框图

1. 线框图概述

线框图描述了网页内容及其相关优先级； 线框图可以帮助项目团队建立对网页的功能、行为和内容相关优先级的裂解；

内容：线框图剖析

第一层：矩形，且只用矩形

一个矩形是基本的单位，它可以分成更多的小矩形：

1. 内容区域

最好用一句话就能概括一个内容区域的作用。

1. 优先级与区别

最简单的方法是按照优先级顺序列出的区域

1. 屏幕标识符

复杂的产品需要进一步注释，例如发生了哪些变化等

第二层：矩形与表单

使页面结构接近真实页面可能会有风险：

1. 布局

不要再布局上投入太多精力，线框图表示的内容不一定回转变为网页。

1. 标签、结构和指示性内容

文字和其他指示都是辅助内容，提供特殊功能的指引。

1. 示例内容

加入真实的内容也可以，只要是用来支持线框图的目的。

1. 功能元素

线框图中还可以加入交互元素，表示界面提供的行为范围。

第三次：其他形状

这一层元素能够美化你的线框图

1. 网格
2. 优先级样式
3. 美学元素

制作：创建线框图

基本决策

规模：页面或是内容区域

保真度：需要多贴近实际

抽象性：内容更多具体

深度：要有多少变化

一般的变化包括：

1. 二级屏幕
2. 页面级变化
3. 组件级变化

目的

通常有两种目的：

1. 蓝图

详细记录了功能规范，目的是向开发者提供开发网站所需的细节。

1. 概念

获取总体的设计概念

1. 测试

受众

线框图技巧

先画草图

确定网页的目的

回忆设计原则

列出页面内容

使用真实场景

提高线框图绘制技巧

采用模块化方法

建立样式

创建元素库

保持一个设计工作室

展示：推介线框图

确定会议目的

1. 确定一个概念追溯性：线框图可以追溯到每一个所提出的设计问题。

复杂性：交代清楚所面临的挑战。 剩余工作：描述还有哪些任务未完成。2. 站在一个更高的角度来讨论体验需要问答以下问题： 这个方法能够实现所有目标？ 这个方法是否符合设计原则和良好的设计方法？ 我们需要重新评估需求吗？ 这个屏幕暗示着什么？3. 从一个更深层次讨论体验深入讨论最终归结为对设计的压力测试，已明确能够适应严格的生产要求。为此需要讨论以下问题： 我们是否处理了所有可能的场景？ 项目团队是否足够的信息来呈现一个可视化设计？ 界面需要什么样的内容？

调整推介

1. 建立上下文背景
2. 描述视觉规则
3. 突出重要的设计决定
4. 提出原理和确定约束
5. 阐述细节
6. 表达的含义
7. 获取反馈
8. 提供一个评审框架

避免新手问题

1. 设定关于目标的预期
2. 内容分歧
3. 视频设计的分歧
4. 结构、没话和声音：控制重叠
5. 拒绝反馈和自我封闭

实践：运用线框图

注释线框图

1. 概述
2. 行为
3. 内容规则
4. 状态

线框图与其他交付件的关系

线框图圆形测试和可用性测试

即时线框图

以书写方式进行设计* 8. 交付件基础知识

定义：优秀交付件的特征

内容：包含的页面

主题页以及元素标示

前沿

摘要

简介与上下文

章节

后续步骤

最终产品

制作：页面布局

说明性页面

描述工件的详细情况，通常使用注释标记出线框图中的重要元素并进行详细说明。 注释包括一个编号，以及在说明的时候引用该编号。

评价性页面

对工件（屏幕）提出批评，通常是用在专家评审和竞品分析中，通常还会包含严重性或优先级的度量。

介绍性页面

用于介绍设计的重点内容，通常使用缩略图，从更高的角度来看待设计，将在后续的页面中针对细节逐个说明。

比较性页面

适合用于竞品分析，用于展示面对同一个设计问题，所给出不同的解决放哪。 也可以用于可用性测试，通过比较网站当前和未来的情况，来判断网站的问题是否得到了解决。或者收集用户对不同的设计方案的反馈。

决策性页面

决策页面提出了一个问题，并提供了足够的信息来寻找答案，决策页面还需要为决策提供标准。

展示

交付件的生命周期

成熟交付件的生命周期取决于以下三个特点：

1. 内容与占位符的比例：占位符越多意味着文档越不成熟；
2. 与项目计划的关系：
3. 为项目目标服务：交付件是否按照计划交付并且被执行，是否覆盖到足够的产品细节；

1. 构思：文档开发

评价标准：

1. 文档是否清楚的说明了目的；
2. 文档内容能否支撑目的；
3. 文档的开始和结尾是否指出后续步骤；
4. 各章的结构是否自然衔接；
5. 页面布局是否符合目的；
6. 是否有可以合并的页面；
7. 是否需要拆分页面；
8. 每个章节是否有优秀的介绍性页面；

2. 诞生：首次亮相

文档已经包含了主要的信息和思想：

1. 可能性：文档将会包含未来可能会出现的内容，使用占位符标记出来；
2. 与计划一致：占位符的出现依然是计划当中的，文档应该呈现出项目当前所处的阶段；
3. 说明挑战、限制和参数：了解当前与期望的差距，以及潜在的障碍是什么。

3. 青春期：仍需要继续成熟

如果内容继续缺失，文档将处于青春期。文档有可能保持一段时间在这个阶段，在评估这部分内容时你应当提出以下问题：

1. 它们与未来的活动是否相关？
2. 文档的其他部分是否满足了相同需求？
3. 合并或者重构能否更好的满足未来的活动？
4. 可以把它们的要点集成到现有的各章节吗？

4. 成熟期：所有内容出现

成熟的文档中，占位符会被内容取代，当文档能够与最初的愿景相匹配时，文档就算是成熟了。 随着项目的进展，旧内容与未来的关联性会降低，在更新中可以考虑去除旧内容；

5. 生命结束：束之高阁

交付期限之后，团队的重心转移到其他地方，对文档的更新逐渐减少。但以下行为依然会长时间存在：

1. 澄清：向 QA 解释某个遗漏的场景；
2. 更新：有时候文档中的错误会在测试的时候发现，此时需要更新文档修复错误；
3. 迭代：当项目有新的需求的时候，就需要根据下一版的需求进行更新迭代。

6. 维护：保持健康

有时候文档需要不断的维护来保持最新：

1. 开发过程中的设计改动；
2. 测试过程中发现文档的缺漏；
3. 产品的更新迭代；

交付件的未来* 9. 设计纲要

在项目开始阶段，设计纲要从设计的角度概括了项目的目标和参数。 设计纲要有以下特点：

1. 清晰的表达了项目目标；
2. 将项目置于一个更大的范围内；
3. 阐述设计问题；
4. 创建其他参数，比如时限；
5. 概括所有输入，比如技术、内容等；
6. 定义设计者采用的方向或方法；

定义：设计纲要的组成要素

设计纲要的内容包括：目标、最佳实践、需求、约束、项目参数、设计理念、设计愿景，以及其他可以指导设计师的陈述。

清晰的阐述问题

设计纲要需要包括：要求、约束和目标等信息，以便形成以一个完整的蓝图。 设计纲要要包括所有类型的陈述、断言、原则和指南，以及尽可能把问题描述清楚的图例。

用范例支持陈述

在描述问题时会包括目标、指南和要求，通过范例来对这些陈述进行说明来增加可信度。 范例的来源可能用到竞品分析的一些结果，可以参考以下几点：

1. 权威网站：一些知名的大型网站的案例；
2. 其他类型的产品：不一定是网站，可以是实体物品；
3. 现实中的经验：例如去图书馆借书，观察散步的人等等；

使用范例的时候有两种方法：

1. 每页一个陈述并提供相关范例；
2. 每页一个陈述并提供相关原则；

第一种适用于数量有限的断言，页面中的大部分篇幅用于描述原则并提供范例； 第二种一个范例可以说明多个断言；

可追溯性

设计过程就是将决策逐步清晰化的过程，在这个过程中，早期的决策包括「产品需要支持哪些任务」，以及逐步简化到「哪些屏幕是必须的」「屏幕的次序」以及「按钮的位置」等等，这些决策是有先后的，前期的决策会直接影响到后期的。设计纲要应当包含这种结构。 在描述设计决策的时候，每一个决策都应当对应到具体的项目目标中。 在文档中，为元素进行编号，以便在之后的决策中引用相关的项目编号来进行说明。

明确的指出界限

设计纲要应当指出哪些该做，哪些不该做，同样设计纲要应当清楚的表明预先确定好的期限。 同时确立优先级，将团队的经历集中在某个范围内也很重要； 特殊情况，一些法律因素等也会影响项目进度；

计划

计划需要描述的内容与最后的期限有限：

1. 活动：团队将进行哪些任务；
2. 交付件：团队的输出物是什么；
3. 人员：谁会负责这些任务；

不断完善

设计纲要要反映设计目的，因此要保证及时更新。 在制作设计纲要的时候，其文档结构应当支持更新。

奠定项目基调

设计纲要还可以作为介绍所使用的项目管理工具的载体。

工作量要适度

工作量要包括以下几点：

1. 目的
2. 总体预算
3. 输入
4. 预计的价值

交流优先级

展示设计纲要的技巧

1. 预先就高层次的内容达成共识，提前沟通相关的目的、愿景这些信息；
2. 不要自以为是，要确保设计的可追溯性；
3. 不要缩减后勤开支，尽可能的花时间与队员交流设计理念和原则；

内容：设计纲要解析

组织设计纲要

这种设计结构遵循全书的一般性文档体系：以关键语句开篇，在随后章节中深入细节：

1. 前页：封面、目录、执行概要；
2. 愿景目标：设计主题、期望的目标、现状；
3. 挑战：范围、需求、约束；
4. 设计原则：每个原则一页篇幅；
5. 计划：项目计划、活动描述、交付件描述；

设计目标、组织和原则

分类：根据不同的主题将原则进行分类，有助于为项目的特定领域建立一个总体方向。 优先级：随着项目的进展，可能需要确定大量的原则，一开始就对它们进行排序； 语言：原则应该使用前执行的语气提出； 草图：用概念草图来说明原则；

设计的上下文和范围

界限是为了让设计师不会越界，需要考虑一下问题：

1. 特异性：例如一些组件的数量、屏幕、接口组件等；
2. 来源：记录范围可以租金可追溯性；
3. 权重：为提供上下文和范围的原则加上优先级；

设计理念

设计理念应当帮助读者了解到以下方面：

1. 体验
2. 设计挑战
3. 范围

防止设计理念失控的方法：

1. 重点集中在一个屏幕上
2. 保持它的草图性质
3. 避免死守某个特定的方向

需求摘要（用户故事）

我可以理解为是用户故事，通过描述用户故事进一步限定了设计团队的设计方向，可以归纳为以下几种摘要：

1. 提取主题
2. 使用祈使句
3. 从用户的角度进行表达

约束摘要

约束没有定义设计问题，而只是限定他的界限。 一般的约束包括以下几种：

1. 技术性的
2. 操作性的
3. 后勤上的；人力短缺等

定义约束的标准字段。这些字段都是团队无法掌控的，如果能够掌控，那么就不算真正的约束。 对于后期出现的约束，团队最好维护一个约束工具，来持续追踪这些约束点。

项目进度表

计划中最好使用甘特图来展示项目进度，甘特图包含两个图：总体计划和当前活动。 在时间线的顶部，需要指定活动和交付件，有时候还需要指出二者之间的关系。

挑战：单页幻灯片的挑战

如果一个人能够清晰的陈述一个问题或者挑战，这个人就最适合解决它。 设计纲要应当用单独一页篇幅为团队总结目标、愿景、方向、约束和方法。通过阅读这篇，队员可以了解接下来几个月内设计团队将要进行哪些工作。* 10. 竞品分析 竞品分析是一个用来份爱其他往回走哪并汲取教训供后续设计活动参考的文档。 执行竞品分析的原因：

1. 了解其他人如何解决同样的设计问题；
2. 将语气的特性和优先级与同类网站做对比，以进行验证；
3. 探索解决相似问题的方法；

定义：优秀竞品分析的要素

竞品分析必须是可操作的，从其他网站分析得到的经验教训必须能够很快的应用到设计工作中。

重点明确

在文档中清晰的写明竞品分析的目标，是为了研究某个控件还是整个系统如何解决某个用户问题。 与队员进行头脑风暴可以收集竞品分析的结果，但同时也会面临着范围的扩展，清楚的了解目标非常重要

坚实的竞品分析框架

竞品分析的框架有助于提取结论，也是阐述事情的一种方法：

1. 首先确定竞品分析的目标；
2. 基于目标设定评估的标准；
3. 基于这些标准进行评估；
4. 对竞品的方案排列优先级；

竞品分析的结果不是要超越对手，而是了解解决问题的各种潜在的方案；

有意义的对比

不要直接分析权威网站的设计，首先要确定这些网站与项目是否有很大的关联性

展示竞品分析的技巧

展示竞品分析的结果往往从已经得到的经验开始，一般分为两种：

1. 围绕某个竞品来分析，分析竞品的独特点，一般用于竞品较少的时候；
2. 围绕每个结论来详细阐述不同竞品的做法，一般用于竞品较多的时候；

展示竞品分析要注意以下几点：

1. 要点1：围绕竞品展开陈述；

先简要介绍测评标准，然后介绍每个竞品是否达标。这种方法适用于处理宽泛的问题。

1. 要点2：围绕结论展开陈述；

就每个问题讨论竞品如何应对。先简介每个竞品，然后针对每个结论介绍标准和依据。

1. 保持会议主题；

对竞品过多的纠缠会导致会议偏离主题，此时要强大会议的主题。

1. 熟悉方法背后的依据；

与会者会质疑你的方法论，对此要做好准备。

1. 倾听各种不同的观点；

你最终关注的还是结论，因此要帮助与会人员总结分析，为它们提供指引；

内容：竞品分析解析

竞品分析的基本要素是对目标的陈述、结论和证据。

分析报告结构

根据展示方法的不同，报告的结构也分为两种：

1. 根据结论来组织
2. 根据竞品来组织

按照结论的报告包括：

1. 前页：封面、目录、摘要、结论；
2. 结论：每个结论一章，包括后面的标准与竞品；
3. 标准与竞品：评价的标准、如何选择的竞品、竞品模版

这种方式剥离了网站原有的环境，只能在有限的角度进行分析。 按照竞品来组织，每个网站对应一个模版，可以全面的介绍一个竞品的用户体验，但是不利于竞品之间的对比；

结论与结果

结论为设计团队明确了一部分方向，竞品分析框架的描述必须能够支持和证明这些结果。 同时需要注意以下问题：

1. 保证结论是清晰的；
2. 对结论进行更详细的描述；
3. 显示足以说明网站的内容，简单描述它们之间的联系；
4. 考虑使用「反面例子」

结论总结

在文档的开始需要对结论进行汇总，用一个备忘清单记录所得到的经验。

范畴总结

竞品分析报告有两个维度：竞品和评测标准； 显示竞品分析框架最简单的方式使用表格，竞品位于表头，每一行是一个标准描述，标准位于左侧表头； 如果只有两个标准可以考虑象限图； 缩略图对比，对比多个竞品针对一个问题的缩略题，对于对比页面布局有很大的帮助； 在描述结论的时候，可以通过是/否、打分和文字描述来说明竞品如何满足标准；

方法论

清楚的表明你的分析过程，有助于处理任何方法论上的不足，这些对于听众来说非常重要。 重点在于如何选择竞品和设定测评标准。

认可竞品分析的价值

竞品分析趋势你去了解受众是如何支配时间，以及哪些关键点会影响用户的决策，你可以从期望竞品中发现它们是如何吸引用户的注意力的，从而可以从这方面展开深入研究。* 11. 可用性计划 可用性计划用于描述可用性测试的目的、方法和步骤，包括了测试目标、测试的后勤保障、用户简介和测试脚本。 可用性测试的电梯推销： 可用性测试是在真实的环境下执行真实的任务，收集对系统设计方案的反馈意见的一种手段。通过询问用户使用系统的情况，我们能够观察到设计的改进余地，在设计过程中发现问题，而不是在上线之后才发现。可用性测试在项目开始的第一天就列入了计划。我们需要完成计划，因为我们已经将用户安排在下周了，但是如果你想进一步讨论可用性测试，我们可以随后继续。

定义：可用性计划的组成要素

建立目标

可用性测试计划的目标就是回答「我们期望通过可用性测试来得到什么」

测试场景

计划应当在一个位置列出所有将要测试的场景。

指导主持人

可用性测试计划的两个受众：指导人员和其他设计人员。指导人员可能是团队中的一员，也可能不是，后者则需要具体操作脚步。

认清测试材料的局限性

这个计划应当描述测试所使用的材料，以及发现特定场景的潜在问题。

讨论可用性计划的技巧

可用性计划的评审最好确保覆盖了足够多的内容。在讨论的时候要谨防便偏离主题，对于新手的质疑可以使用电梯推销来介绍可用性测试。

内容：可用性计划解析

组织测试计划

可是计划一般包含以下内容：

1. 前页：封面、目录、执行摘要；
2. 方法与逻辑：方法概述、逻辑与时间线、人员准备；
3. 场景：每页介绍一个可用性测试场景；
4. 后续步骤：测试概述、测试报告

计划摘要

摘要包括三个方面：

1. 描述参与者特征，可以使用 Persona；
2. 询问什么问题；
3. 希望获得什么；

场景

场景描述了参与者面对的虚拟情景，为他们建立了一个使用你提供的网站来解决的问题。

1. 问题列表：在场景中加入具体的问题，可以让主持人更好的提问。
2. 场景变化：如果场景需要变化，在计划结构中应当能够体现这种变化。

测试前后的问题

测试前可以向参与者展示原型，以获取他们的期望和经验水平； 询问一些问题也可以了解参与者的相关经验。 尽可能从一个角度来描述问题，并且描述清楚；

测试的后勤保障与招募

测试计划中概述测试的时间、地点和方式，可以是相关人员更容易理解处理方式。

详细的招募信息和人员

如果是通过第三方中介来招募人员，应当描述清楚如何判断目标人群以及一些筛选条件。

最轻松的计划

可用性计划的难点在于保持对最终目标的关注* 12. 可用性报告 可用性报告用于展示可用性研究的结果，以此来指导接下来的设计活动。

定义：优秀可用性报告的要素

可用性报告必须解决以下三个问题：

1. 可操作性：设计人员应当可以根据报告来改进设计。
2. 权威性：观测到的结果要能够反映一个基本原理。
3. 可读性：报告应当简介清晰，复杂的说明可以在另一份文件中体现。

关注点与关联性

好的可用性报告将内容关注到一个目标上。 通常可用性测试会有以下几种目标：

1. 诊断设计问题；
2. 建立设计项目的优先级；
3. 更加了解用户及其行为；
4. 验证设计概念；
5. 验证需求并划分优先级；

按优先级划分的结果和数据

报告应当可以让设计团队了解应当优先解决按些问题，以及问题的严重程度（原因）

展示可用性报告的技巧

展示报告时需要解决以下问题：

1. 确定目标：
2. 尽早报告结果：报告的完成需要一定的时间，而结果的相关性会随着时间的推移而减弱。
3. 客观、真实：可用性测试是一种不精确的方法，因此要区分「发生的现象」和「你对现象的解释」。
4. 准备设计问题：展示的时候要考虑预期的结果是什么；提醒与会者报告的范围；如在报告中整合了建议，要考虑如何讨论这些建议。
5. 不要对方法论产生抵触：很多可用性测试的方法都存在争议，考虑使用这些方法来弱化争议：

总结方法和原理：交付件中介绍所使用的方法和原理；

承认方法的局限性：但仍然需要测试；

捕捉计划的偏离：如果你需要及时修改测试方法，需要记录这些修改；

内容：可用性报告解析

报告的内容主要是用来总结测试过程中所观察到的结果和收集到的其他数据。

可用性报告的结构

报告有两种组织方法：

1. 按场景和任务组织；
2. 按主题组织；

按场景和任务组织1. 前页：封面、目录、执行摘要、关键结论/最高优先级

1. 场景：屏幕的观察结果；
2. 其他观察结果
3. 参与者：个人介绍、参与者介绍
4. 背景：方法、招募
5. 附录：全部观察结果的完整表格

按主题组织需要确定一些特定的主题：

1. 用户不知道下一步做什么；
2. 用户不理解术语；
3. 用户不理解视觉规则；
4. 用户错过了重要内容；*** 观察结果与严重性

在书写观察结果是要考虑以下问题：

1. 观察结果能否合并；
2. 给出观察的上下文；在撰写的时候考虑：
3. 在一个表格中总结观察结果：包括观察结果、严重程度、上下文条件；
4. 表明结果的严重程度；
5. 其他修饰件；*** 总结与分析

总结包含两个主要结果：网站的优点和缺点，以及给项目团队一个优先级印象。总结还可能明确说明后续步骤。

建议

尝试在报告的结尾添加建议，在表格中组织建议，建议包含三个要素：

1. 关注点，建议的位置/元素；
2. 改进策略
3. 需要注意的问题

支持内容

同时报告还需要指出测试中所用到的方法以及方法论，包括：

1. 技术；
2. 参与者数量；
3. 参与者代表特征；
4. 研究中使用的材料；
5. 研究范围（属于体验过程）；
6. 研究范围量化（场景数）；

可用性测试的另一种形式

在用户真实的环境下测试的效果最佳，但是成本也会更高。不过在做企业产品的时候这种方法就很合适。

UML

http://poetpainter.com/index.html Stephen 将基本的思想（用户体验的定义）变换为可视化的图形，已明确主题。

by Nathan Curtis

by Zaki Warfel

by Tufte

Designing Web Navigation: Optimizing the User Experience by James Kalbach - Books on Google Play