About Face 3

按有用程度 按页码先后 最新笔记

• 

  Chapter 2-3

  霏昀 (身残志坚)

  Chapter 2 Implementation Models and Mental Models 实现模型指系统内部实现（每秒24格画面）。心智模型指用户看待系统的方式（图像在屏幕上移动）。 按:心智模型应该是心理学的一个术语，不清楚此处的应用是否准确。 实现模型和心智模型存在鸿沟。因此需要Represented模型，即（在数字产品中）设计师选择将程序功能暴露给用户的方式。 好的Represented模型更接近的心智模型（画面加速、减速），而开发人员进行设计的... (更多)

  Chapter 2 Implementation Models and Mental Models

  实现模型指系统内部实现（每秒24格画面）。心智模型指用户看待系统的方式（图像在屏幕上移动）。

  按:心智模型应该是心理学的一个术语，不清楚此处的应用是否准确。

  实现模型和心智模型存在鸿沟。因此需要Represented模型，即（在数字产品中）设计师选择将程序功能暴露给用户的方式。

  好的Represented模型更接近的心智模型（画面加速、减速），而开发人员进行设计的缺陷在于其设计结果常常更接近实现模型（每秒格数更多更少）。

  机械时代和信息时代需要不同的Represented模型。使用机械产品模型作为信息系统的隐喻，往往会限制信息系统的设计。好的设计需要信息时代的思维模式。

  ---------------------------------

  Chapter 3 Beginners, Experts, and Intermediates

  设计的一个难题是如何在统一的设计中兼顾初学者和专家。

  然而大部分用户既不是初学者也不是专家，而是中等用户（Intermediates）。实际上，大部分初学者会很快变成中等用户，但是他们永远也不会变为专家。

  开发人员设计的交互往往更适合专家（比如，列出所有可能的操作，不区分操作的优先级）；市场人员则需要更适合初学者的交互（方便推广）。

  设计需要为中等用户进行优化，这包括三方面内容：

  1. 初学者成为中等用户的学习曲线低——想象初学者聪明并且忙碌；

  2. 希望成为专家的用户不会遭遇障碍——专家积极地寻找并学习产品可能实现他们需求的方式；

  3. 永久性的中等用户（perpetual intermediates）能对产品保持满意——中等用户会使用手册；他们会很快区分出（对他们来说的）常用功能和不常用功能；他们通常知道高级功能的存在，虽然他们可能不知道如何使用高级功能。 (收起)

  2011-08-22 14:16:30   1回应

  收藏

  推荐
• 

  Chapter 5 Modeling Users

  霏昀 (身残志坚)

  Modeling Users: Personas and Goals 角色模型（Personas）是作为研究结果的行为模式、心智模型以及用户目标的形式化。角色模型可以帮助设计师对用户分类，确定不同用户的需求，进而确定目标用户的类型——包含所有可能特性的产品，不能取悦任何人（a product with every possible feature pleases nobody）。 角色模型可以帮助设计师避免产品设计中一些常见的问题： * 弹性（elastic）用户：每个设计师都对用户需求.. (更多)

  Modeling Users: Personas and Goals

  角色模型（Personas）是作为研究结果的行为模式、心智模型以及用户目标的形式化。角色模型可以帮助设计师对用户分类，确定不同用户的需求，进而确定目标用户的类型——包含所有可能特性的产品，不能取悦任何人（a product with every possible feature pleases nobody）。

  角色模型可以帮助设计师避免产品设计中一些常见的问题：

  * 弹性（elastic）用户：每个设计师都对用户需求有不同的理解。最终用户需求成为所有人需求的并集；

  * 主观设计：设计师按自己的目标、动机、心智模型来设计产品；

  * 边缘情况：关注那些可能发生但不是目标用户需求的情况。

  角色模型的一些基本要点：

  * 基于用户研究结果；

  * 每个用户模型被描述为一个人，但代表一组用户；

  * 包含一组行为；

  * 具备自身的动机；

  * 除用户外，也可能是客户（customer personas）或者被服务者（served personas）——例如医疗设备的病人。

  与传统软工方法中的用户角色（Role）相比，角色模型（personas）更关注用户的目标，更倾向用描述性的话语来表达自身。Personas可能是多个具有同样行为和目标的Role；也可能是对具有不同目标的同一Role的细分。

  按：我在原书上标注了这段话，但现在看意义有限。因为书中并没有定义Role获取方法，所以没法精确说明Personas和Role的区别。

  当不能通过研究获得严格的角色模型时，也可以使用靠猜想获得的临时角色模型（Provisional Personas）。但使用临时角色模型具有以下风险：

  * 关注于错误的设计目标；

  * 即使关注了正确的目标，也可能错失重要的行为；

  * 难以容易说服不认同你观点的人；

  * 错误的使用，可能导致他人不认同角色模型。

  目标（Goals）对于角色模型至关重要。目标是用户行为的动机，其必须由研究数据中获得。每个目标需要能够用一句简单的句子来描述。

  Norman提出了三个层次的认知加工（Cognitive Processing）：

  * 本能的（Visceral）：及时的，在进一步交互之前，在视觉或其他感觉方面的反应；

  * 行为的（Behavioral）：简单的，日常的行为——这是人类最主要的活动；

  * 反射的（Reflection）：基于以前的经验，有意识的行为；

  基于以上三个层次的认知，存在三种类型的用户目标（User Goals）：

  * 体验目标（Experience Goal）：

  * 与本能认知相关——用户想感受什么；

  * 用户希望在使用产品时希望获得的感受。这类目标关注于，视听特征、交互感受（动画的流畅度、按钮“硬度”）、物理设计；

  * 交互、视觉、工业设计师需要将这类目标转化为具备恰当感觉、情绪、音调的形式、行为、手势等；

  * 面向本能的设计意味着在深入使用之前，对产品的第一感觉进行设计。

  * 最终目标（End Goal）：

  * 与行为认知相关——用户想做什么；

  * 用户使用产品完成功能的动机。这类目标关注于，产品交互设计、信息架构、功能方面的工业设计；

  * 交互设计师需要以最终目标为基础设计产品的行为、任务、外观、感受；

  * 面向行为的设计使产品的行为符合用户的行为、隐含假设以及心智模型。

  * 生活目标（Life Goal）：

  * 与反射认知相关——用户想成为谁；

  * 用户长期的期望、动机以及自我实现愿景。这类目标关注于，产品的总体设计、策略以及品牌；

  * 交互设计师需要将生活目标转化为high-level的系统能力、设计概念以及品牌策略。生活目标很少直接指导具体细节的设计，但是这类目标必须时刻保持在脑海里；

  * 面向反射的设计使产品与用户建立长期的联系。

  除了用户目标外，设计还需关注客户目标（Customer goals）、商业与组织的目标（Business and organization goals）、技术目标（Technical goals）。

  “好的设计”只有在用户为了某种目标使用产品时才有意义。成功的产品首先满足用户目标。

  构造角色模型的步骤：

  1. 从访谈中辨识行为变量（behavioral variables），最常见的行为变量包括：

  * 活动（Activities）：用户做什么，以及频率和数量

  * 态度（Attitudes）：用户对产品领域和技术的看法如何

  * 能力倾向（Aptitudes）：用户的教育程度、受过何种训练、学习能力如何

  * 动机（Motivations）：用户为什么对产品领域感兴趣

  * 技能（Skills）：用户在产品领域技术方面的能力

  2. 通过访谈对象与行为标量进行映射，将访谈对象分组

  3. 通过分组辨识行为模式（behavior pattern），作为角色模型的基础

  4. 综合特征与目标：针对每个行为模式，参考访谈细节给出：

  * 角色模型潜在的使用环境、典型使用场景、现有解决方案及其不足。

  * 角色模型需要一个有意义的名字，以及一些简单的人物描述。

  * 目标是角色模型定义中最重要的工作，其中最终目标（end goals）对设计用处最大。

  * 一般来讲，一个角色模型会包含0-2个体验目标、3-5个最终目标、0-1个生活目标。

  5. 检查完备与冗余

  6. 扩展角色属性和行为的描述：描述应该是对角色模型日常生活的结论性概括，但不构成一个Short Story

  7. 指定角色的类型：

  * 首要（Primary）角色：产品的每个界面对应一个首要角色；当没有唯一清晰的首要角色时，意味着：要么产品需存在多个首要角色，需要为每个首要角色进行单独设计；要么产品想做的事情太多了。

  * 次要（Secondary）角色：次要角色的大部分需求可以被为首要角色设计的界面满足，但是他们还包含一些额外的，可以在不扰乱首要角色功能的情况下，被满足的需求。当存在多余3-4个次要角色时，可能意味着产品的边界不明。

  * 补充（Supplemental）角色：潜在的，或者源于Stakeholder假设的角色。

  * 客户（Customer）角色

  * 被服务（Served）角色：不直接使用产品，但被产品直接影响的角色——例如医疗设备产品的病人。

  * 无关（Negative）角色

  在用户建模阶段，除角色模型外，还可以获得一些辅助的模型：

  * 工作流（Workflow）模型：可能是角色模型级别的个人工作流，也可能是商业、组织级别的协同工作流。

  * 制品（Artifact）模型：用户完成工作需要用到的或者产出的制品。

  * 物理（Physical）模型：用户活动的物理环境。简单的物理环境可以直接在角色模型中说明，复杂的则需要单独的物理模型。 (收起)

  2011-08-26 11:53:19   1人收藏   回应

  收藏

  推荐
• 

  Chapter 7 Design Framework

  霏昀 (身残志坚)

  From Requirements to Design: The Framework and Refinement 设计框架（Design Framework）定义了用户体验的整体结构。在此阶段不必考虑细节，只需要产生产品的Big Picture。纸面原型（Paper Prototype）可以作为本阶段讨论用的有效工具。设计框架包含三部分： * 交互框架：使用场景和需求创建产品界面和行为的骨架 * 视觉设计框架 * 工业设计框架 定义交互框架的步骤： 1. 定义产品形态（Web, Pho... (更多)

  From Requirements to Design: The Framework and Refinement

  设计框架（Design Framework）定义了用户体验的整体结构。在此阶段不必考虑细节，只需要产生产品的Big Picture。纸面原型（Paper Prototype）可以作为本阶段讨论用的有效工具。设计框架包含三部分：

  * 交互框架：使用场景和需求创建产品界面和行为的骨架

  * 视觉设计框架

  * 工业设计框架

  定义交互框架的步骤：

  1. 定义产品形态（Web, Phone或者其他什么）、使用姿态、输入方式——这些定义依赖于需求定义中获取的语境场景

  2. 定义功能（functional）以及数据（data）元素：

  * 定义时需要经常回顾场景、角色目标和心智模型；

  * 将系统想象为一个“人”，有利于实现结构化的交互细节；

  * 基于场景的设计方法是一种top-down不断细化的方法，而已有最佳实践的设计原则（Principle）和模式（Pattern）是对top-down方法一个补充；

  * 除非非常明确的理由，不应该破坏已有的最佳实践。

  3. 确定功能的分组和层次：需要考虑角色的工作流程以及某个任务的相关任务

  4. 交互框架骨架（Sketch）：

  * 主要任务是画线框图

  * 尝试多种布局

  * 迭代

  * 一开始建议使用白板直接绘图，当细节完善到一定程度后再使用CAD工具（Firework、Illustrator、Visio、PPT、OmniGraffle）

  5. 构造关键路径场景（Key Path Scenarios）：

  * 关注任务（task）级别

  * 角色的目标（goal）必须在考虑范围内

  * 使用故事板（storybroading）描述关键路径场景

  6. 步骤3-5可能存在一些变体，例如：

  * 从功能出发的变体：先辨识关键路径，再分组，再创建骨架

  * 从视觉出发的变体：先分组+骨架；再关键路径，回头检查分组是否和关键路径切合

  * （按：我觉得显然应该从功能出发，因为这更不容易出现错误…… 当然可能是思维定势）

  7. 使用验证场景（Validation Scenarios）检查设计：

  * 设计能否满足关键路径场景的变体

  * 设计能否满足一些不频繁发生但必要的场景（Necessary use scenarios）：不频繁意味着不需要诸如快捷键、用户定制等功能

  * 设计能否满足边缘场景（Edge case use scenarios）：边缘场景不应该被忽视，但是针对其的设计不应该影响其他场景

  按：后面两部分没有很认真的看。

  定义视觉设计框架的步骤：

  1. 开发视觉语言（Visual Language Studies）：需要考虑角色的体验目标、产品品牌关键词、以及公司品牌

  2. 将视觉风格应用到原型

  定义工业设计框架的步骤：

  1. 与交互设计师合作定义产品形态和输入方式

  2. 开发粗略原型

  3. 开发形式语言（Form Language Studies） (收起)

  2011-08-26 12:43:25   回应

  收藏

  推荐

• 

  Chapter 7 Design Framework

  霏昀 (身残志坚)

  From Requirements to Design: The Framework and Refinement 设计框架（Design Framework）定义了用户体验的整体结构。在此阶段不必考虑细节，只需要产生产品的Big Picture。纸面原型（Paper Prototype）可以作为本阶段讨论用的有效工具。设计框架包含三部分： * 交互框架：使用场景和需求创建产品界面和行为的骨架 * 视觉设计框架 * 工业设计框架 定义交互框架的步骤： 1. 定义产品形态（Web, Pho... (更多)

  From Requirements to Design: The Framework and Refinement

  设计框架（Design Framework）定义了用户体验的整体结构。在此阶段不必考虑细节，只需要产生产品的Big Picture。纸面原型（Paper Prototype）可以作为本阶段讨论用的有效工具。设计框架包含三部分：

  * 交互框架：使用场景和需求创建产品界面和行为的骨架

  * 视觉设计框架

  * 工业设计框架

  定义交互框架的步骤：

  1. 定义产品形态（Web, Phone或者其他什么）、使用姿态、输入方式——这些定义依赖于需求定义中获取的语境场景

  2. 定义功能（functional）以及数据（data）元素：

  * 定义时需要经常回顾场景、角色目标和心智模型；

  * 将系统想象为一个“人”，有利于实现结构化的交互细节；

  * 基于场景的设计方法是一种top-down不断细化的方法，而已有最佳实践的设计原则（Principle）和模式（Pattern）是对top-down方法一个补充；

  * 除非非常明确的理由，不应该破坏已有的最佳实践。

  3. 确定功能的分组和层次：需要考虑角色的工作流程以及某个任务的相关任务

  4. 交互框架骨架（Sketch）：

  * 主要任务是画线框图

  * 尝试多种布局

  * 迭代

  * 一开始建议使用白板直接绘图，当细节完善到一定程度后再使用CAD工具（Firework、Illustrator、Visio、PPT、OmniGraffle）

  5. 构造关键路径场景（Key Path Scenarios）：

  * 关注任务（task）级别

  * 角色的目标（goal）必须在考虑范围内

  * 使用故事板（storybroading）描述关键路径场景

  6. 步骤3-5可能存在一些变体，例如：

  * 从功能出发的变体：先辨识关键路径，再分组，再创建骨架

  * 从视觉出发的变体：先分组+骨架；再关键路径，回头检查分组是否和关键路径切合

  * （按：我觉得显然应该从功能出发，因为这更不容易出现错误…… 当然可能是思维定势）

  7. 使用验证场景（Validation Scenarios）检查设计：

  * 设计能否满足关键路径场景的变体

  * 设计能否满足一些不频繁发生但必要的场景（Necessary use scenarios）：不频繁意味着不需要诸如快捷键、用户定制等功能

  * 设计能否满足边缘场景（Edge case use scenarios）：边缘场景不应该被忽视，但是针对其的设计不应该影响其他场景

  按：后面两部分没有很认真的看。

  定义视觉设计框架的步骤：

  1. 开发视觉语言（Visual Language Studies）：需要考虑角色的体验目标、产品品牌关键词、以及公司品牌

  2. 将视觉风格应用到原型

  定义工业设计框架的步骤：

  1. 与交互设计师合作定义产品形态和输入方式

  2. 开发粗略原型

  3. 开发形式语言（Form Language Studies） (收起)

  2011-08-26 12:43:25   回应

  收藏

  推荐
• 

  Chapter 6 Scenarios & Reqs

  霏昀 (身残志坚)

  The Foundations of Design: Scenarios and Requirements 在GDD方法中，从定性的研究数据到设计解决方案，通过四个不断迭代的步骤来完成： 1. 通过研究数据以及角色模型，想象用户交互的场景（Scenario） 2. 利用场景定义需求（Requirement） 3. 利用需求定义基本的交互框架（Interaction Framework） 4. 不断丰富框架的设计细节 场景（Scenario）作为设计中的概念最早由John Carroll在90年代提出。Ca... (更多)

  The Foundations of Design: Scenarios and Requirements

  在GDD方法中，从定性的研究数据到设计解决方案，通过四个不断迭代的步骤来完成：

  1. 通过研究数据以及角色模型，想象用户交互的场景（Scenario）

  2. 利用场景定义需求（Requirement）

  3. 利用需求定义基本的交互框架（Interaction Framework）

  4. 不断丰富框架的设计细节

  场景（Scenario）作为设计中的概念最早由John Carroll在90年代提出。Carroll的基于场景的设计（Scenario-based Design）方法中，场景以故事的形式描述用户如何完成工作——类似于电影中的故事板，进而用于创建和演示设计方案。

  AF3中的GDD方法与Carroll方法的不同之处在于：在场景获取之前，角色模型，特别是用户的目标已经明确；而场景的获取依赖于之前步骤生成的角色模型（Personas-based Scenario）。

  GDD方法中定义了三类场景：

  * 语境场景（Context Scenario），或曰“日常生活场景（Day-in-the-life Scenario）”：先于任何设计，只涉及活动、感觉、愿望。

  * 关键路径产场景（Key Path Scenario）：由语境场景精化得到，关注于最重要的交互，以及用户如何使用产品实现其目标（goal）。

  * 验证场景（Validation Scenario）

  场景和用例（Use cases）的不同在于：用例更加技术化，更具体地描述用户的每个操作以及系统的响应。用例的问题在于，一来用例没有详细定义系统（在设计层面上）的行为；二来用例没有优先级，因此更适合用来验证系统功能的完备。

  需求（Requirement）定义产品是什么以及产品做什么。设计定义产品如何做。需求先于设计。需求不是功能（function）或者特性（feature），而是用户或者公司业务的需要（need）。

  按：大白话，这也是我为什么说AF3的Part I与其说是设计方法，不如说是需求方法。

  需求定义的步骤：

  1. 建立问题和愿景描述：

  * 问题描述（Problem statements）反映了需要改变的现状，例如：公司X的客户满意度很低，因为用户没有适当的工具完成任务X、Y、Z以帮助他们实现目标G；

  * 愿景描述（Vision statements）是问题描述的反面，例如：新设计的产品X可以使用户可以更好（精确、有效等等）地完成任务X、Y、Z，并解决现有的问题A、B、C，进而帮助用户完成目标G。新设计将会显著提高用户的满意度。

  2. 头脑风暴：对于产品的头脑风暴，目的是排除一些在研究阶段产生的思维定势。

  3. 辨识角色期望（Personas expectations）：

  针对每个首要和次要角色，需要辨识：

  * 一些影响用户期望的因素，例如：态度、经验、社会身份、文化等等

  * 对于使用产品体验的期望

  * 对产品行为的期望

  * 角色认为产品应该包含的基本元素以及数据

  4. 构建语境场景：

  * 语境场景很像故事，其关注于用户活动、动机以及心智模型；

  * 语境场景high-level地从用户的视角展示了产品使用模式（Usage pattern）；

  * 语境场景不关注产品和交互的细节；

  * 语境场景不应该被已有产品所局限，假设任何想法都可以神奇地实现（Pretend the interfa is magic）。

  * 按：大概是全书精化所在之一，书中的例子很有说明性，限于篇幅不再引用。

  5. 辨识需求：

  需求由对象、行为和语境组成。 例如：在一个预约条目中（语境）直接给某人（对象）打电话（行为）。按：GDD强调这个需求应该是一个need，而不是task或feature。但仅以上面例子，我感到其中的差异很微妙。此外，这里的结构很像从场景中发现用例，再从用例中辨识名词（类）和动词（方法）的方法。需求可以被进一步划分为：

  * 数据需求：需要被展示在系统中的对象和信息；

  * 功能需求：在对象上执行的操作；

  * 其他需求：其他一些需要，特别是限制。例如：商业需求、品牌体验需求、技术需求、客户和合作伙伴需求。 (收起)

  2011-08-26 12:14:36   回应

  收藏

  推荐
• 

  Chapter 5 Modeling Users

  霏昀 (身残志坚)

  Modeling Users: Personas and Goals 角色模型（Personas）是作为研究结果的行为模式、心智模型以及用户目标的形式化。角色模型可以帮助设计师对用户分类，确定不同用户的需求，进而确定目标用户的类型——包含所有可能特性的产品，不能取悦任何人（a product with every possible feature pleases nobody）。 角色模型可以帮助设计师避免产品设计中一些常见的问题： * 弹性（elastic）用户：每个设计师都对用户需求.. (更多)

  Modeling Users: Personas and Goals

  角色模型（Personas）是作为研究结果的行为模式、心智模型以及用户目标的形式化。角色模型可以帮助设计师对用户分类，确定不同用户的需求，进而确定目标用户的类型——包含所有可能特性的产品，不能取悦任何人（a product with every possible feature pleases nobody）。

  角色模型可以帮助设计师避免产品设计中一些常见的问题：

  * 弹性（elastic）用户：每个设计师都对用户需求有不同的理解。最终用户需求成为所有人需求的并集；

  * 主观设计：设计师按自己的目标、动机、心智模型来设计产品；

  * 边缘情况：关注那些可能发生但不是目标用户需求的情况。

  角色模型的一些基本要点：

  * 基于用户研究结果；

  * 每个用户模型被描述为一个人，但代表一组用户；

  * 包含一组行为；

  * 具备自身的动机；

  * 除用户外，也可能是客户（customer personas）或者被服务者（served personas）——例如医疗设备的病人。

  与传统软工方法中的用户角色（Role）相比，角色模型（personas）更关注用户的目标，更倾向用描述性的话语来表达自身。Personas可能是多个具有同样行为和目标的Role；也可能是对具有不同目标的同一Role的细分。

  按：我在原书上标注了这段话，但现在看意义有限。因为书中并没有定义Role获取方法，所以没法精确说明Personas和Role的区别。

  当不能通过研究获得严格的角色模型时，也可以使用靠猜想获得的临时角色模型（Provisional Personas）。但使用临时角色模型具有以下风险：

  * 关注于错误的设计目标；

  * 即使关注了正确的目标，也可能错失重要的行为；

  * 难以容易说服不认同你观点的人；

  * 错误的使用，可能导致他人不认同角色模型。

  目标（Goals）对于角色模型至关重要。目标是用户行为的动机，其必须由研究数据中获得。每个目标需要能够用一句简单的句子来描述。

  Norman提出了三个层次的认知加工（Cognitive Processing）：

  * 本能的（Visceral）：及时的，在进一步交互之前，在视觉或其他感觉方面的反应；

  * 行为的（Behavioral）：简单的，日常的行为——这是人类最主要的活动；

  * 反射的（Reflection）：基于以前的经验，有意识的行为；

  基于以上三个层次的认知，存在三种类型的用户目标（User Goals）：

  * 体验目标（Experience Goal）：

  * 与本能认知相关——用户想感受什么；

  * 用户希望在使用产品时希望获得的感受。这类目标关注于，视听特征、交互感受（动画的流畅度、按钮“硬度”）、物理设计；

  * 交互、视觉、工业设计师需要将这类目标转化为具备恰当感觉、情绪、音调的形式、行为、手势等；

  * 面向本能的设计意味着在深入使用之前，对产品的第一感觉进行设计。

  * 最终目标（End Goal）：

  * 与行为认知相关——用户想做什么；

  * 用户使用产品完成功能的动机。这类目标关注于，产品交互设计、信息架构、功能方面的工业设计；

  * 交互设计师需要以最终目标为基础设计产品的行为、任务、外观、感受；

  * 面向行为的设计使产品的行为符合用户的行为、隐含假设以及心智模型。

  * 生活目标（Life Goal）：

  * 与反射认知相关——用户想成为谁；

  * 用户长期的期望、动机以及自我实现愿景。这类目标关注于，产品的总体设计、策略以及品牌；

  * 交互设计师需要将生活目标转化为high-level的系统能力、设计概念以及品牌策略。生活目标很少直接指导具体细节的设计，但是这类目标必须时刻保持在脑海里；

  * 面向反射的设计使产品与用户建立长期的联系。

  除了用户目标外，设计还需关注客户目标（Customer goals）、商业与组织的目标（Business and organization goals）、技术目标（Technical goals）。

  “好的设计”只有在用户为了某种目标使用产品时才有意义。成功的产品首先满足用户目标。

  构造角色模型的步骤：

  1. 从访谈中辨识行为变量（behavioral variables），最常见的行为变量包括：

  * 活动（Activities）：用户做什么，以及频率和数量

  * 态度（Attitudes）：用户对产品领域和技术的看法如何

  * 能力倾向（Aptitudes）：用户的教育程度、受过何种训练、学习能力如何

  * 动机（Motivations）：用户为什么对产品领域感兴趣

  * 技能（Skills）：用户在产品领域技术方面的能力

  2. 通过访谈对象与行为标量进行映射，将访谈对象分组

  3. 通过分组辨识行为模式（behavior pattern），作为角色模型的基础

  4. 综合特征与目标：针对每个行为模式，参考访谈细节给出：

  * 角色模型潜在的使用环境、典型使用场景、现有解决方案及其不足。

  * 角色模型需要一个有意义的名字，以及一些简单的人物描述。

  * 目标是角色模型定义中最重要的工作，其中最终目标（end goals）对设计用处最大。

  * 一般来讲，一个角色模型会包含0-2个体验目标、3-5个最终目标、0-1个生活目标。

  5. 检查完备与冗余

  6. 扩展角色属性和行为的描述：描述应该是对角色模型日常生活的结论性概括，但不构成一个Short Story

  7. 指定角色的类型：

  * 首要（Primary）角色：产品的每个界面对应一个首要角色；当没有唯一清晰的首要角色时，意味着：要么产品需存在多个首要角色，需要为每个首要角色进行单独设计；要么产品想做的事情太多了。

  * 次要（Secondary）角色：次要角色的大部分需求可以被为首要角色设计的界面满足，但是他们还包含一些额外的，可以在不扰乱首要角色功能的情况下，被满足的需求。当存在多余3-4个次要角色时，可能意味着产品的边界不明。

  * 补充（Supplemental）角色：潜在的，或者源于Stakeholder假设的角色。

  * 客户（Customer）角色

  * 被服务（Served）角色：不直接使用产品，但被产品直接影响的角色——例如医疗设备产品的病人。

  * 无关（Negative）角色

  在用户建模阶段，除角色模型外，还可以获得一些辅助的模型：

  * 工作流（Workflow）模型：可能是角色模型级别的个人工作流，也可能是商业、组织级别的协同工作流。

  * 制品（Artifact）模型：用户完成工作需要用到的或者产出的制品。

  * 物理（Physical）模型：用户活动的物理环境。简单的物理环境可以直接在角色模型中说明，复杂的则需要单独的物理模型。 (收起)

  2011-08-26 11:53:19   1人收藏   回应

  收藏

  推荐