CPT208 Human-Centric Computing 人机交互 Pt.5 原型保真度和维度

文章目录

• 1.原型保真度
• • [1.1 原型保真度时精确语言的重要性](#1.1 原型保真度时精确语言的重要性)
  • [1.2 原型设计的五个维度](#1.2 原型设计的五个维度)
  • • [1.2.1 视觉保真度（Visual fidelity）](#1.2.1 视觉保真度（Visual fidelity）)
    • [1.2.2 交互保真度（Interaction fidelity）](#1.2.2 交互保真度（Interaction fidelity）)
    • [1.2.3 广度保真度（Breadth fidelity）](#1.2.3 广度保真度（Breadth fidelity）)
    • [1.2.4 深度保真度（Depth fidelity）](#1.2.4 深度保真度（Depth fidelity）)
    • [1.2.5 内容保真度（Content fidelity）](#1.2.5 内容保真度（Content fidelity）)
    • [1.2.6 其他维度](#1.2.6 其他维度)
  • [1.3 同时处理多个维度](#1.3 同时处理多个维度)
• [2. 物理设计](#2. 物理设计)
• • [2.1 菜单设计（Menu design）](#2.1 菜单设计（Menu design）)
  • [2.2 图标设计（Icon design）](#2.2 图标设计（Icon design）)
  • [2.3 屏幕设计（Screen design）](#2.3 屏幕设计（Screen design）)
  • • [2.3.1 屏幕划分（Split across screens）](#2.3.1 屏幕划分（Split across screens）)
    • [2.3.2 单个屏幕设计（Individual screen design）](#2.3.2 单个屏幕设计（Individual screen design）)
  • [2.4 信息展示（Information display）](#2.4 信息展示（Information display）)
• [3. 原型设计](#3. 原型设计)
• • [3.1 原型类型](#3.1 原型类型)
  • [3.2 具体设计](#3.2 具体设计)
  • [3.3 注意事项](#3.3 注意事项)

1.原型保真度

在评估原型时，低保真度和高保真度之间可能没有明确的界限或分离。

尽管可能难以明确区分低保真度和高保真度原型，但我们可以从不同的角度来衡量和评估原型。

保真度可以通过多个维度来定义，每个维度代表原型的不同方面。

这些维度包括：

1. 视觉（Visual）：原型的视觉设计，如颜色、字体、布局等。
2. 交互（Interaction）：原型的交互设计，如按钮点击、滑动等。
3. 广度（Breadth）：原型覆盖的功能范围，即原型中包含多少最终产品的功能。
4. 深度（Depth）：原型中每个功能的详细程度，即功能的复杂性和完整性。
5. 内容（Content）：原型中包含的实际内容，如文本、图像、数据等。

原型的保真度（fidelity）本身没有绝对的好与坏，每种选择都有其成本和权衡。

作为设计师，你需要根据项目的具体需求、目标和资源来决定如何平衡保真度。这包括决定在视觉、交互、广度、深度和内容等不同维度上投入多少保真度。

低保真度原型适合快速迭代和测试概念，而高保真度原型适合评估更接近最终产品的用户体验。设计师需要权衡时间和资源，以及所需的反馈类型，来决定是选择低保真度还是高保真度的原型。

1.1 原型保真度时精确语言的重要性

其重要性如下：

1. 浪费时间和精力（We're wasting time and sanity with imprecise language about fidelity）：
   使用不精确的语言来描述原型的保真度可能会导致混淆和误解，从而浪费团队的时间和精力。
2. 错误验证的风险（Even worse, we risk falsely validating one thing today and failing to validate a better way tomorrow）：
   如果今天错误地验证了一个设计，可能会错过明天更好的解决方案。精确的语言可以帮助团队避免这种风险，确保设计决策基于正确的理解和评估。
3. 过度工程化的风险（Teams are prone to over-engineering a prototype prematurely）：
   团队可能会过早地对原型进行过度工程化，导致资源浪费。精确的语言可以帮助团队避免在不必要的地方投入过多精力。
4. 导致努力浪费（leading to wasted effort）：
   过度工程化原型可能会导致不必要的工作和资源浪费。
5. 关键维度的特殊需求（a prototype may be low fidelity except for one crucial dimension）：
   原型可能在大多数方面都是低保真度的，但可能有一个关键维度需要接近生产级别的质量和保真度来公平地验证。

1.2 原型设计的五个维度

前面介绍了这五个维度，现在我们就在这些维度上进行衡量。

1. 视觉（Visual）：
   定义：原型在视觉上有多接近最终产品？
   目的：评估原型的外观和风格是否与预期的最终设计一致。
2. 交互（Interaction）：
   定义：原型在用户交互方面有多真实？
   目的：评估用户与原型交互时的体验是否接近真实产品的体验。
3. 广度（Breadth）：
   定义：原型展示的是整个产品还是仅一部分？
   目的：确定原型覆盖的功能范围，是否包括了所有必要的功能或仅展示了部分功能。
4. 深度（Depth）：
   定义：在给定的广度下，用户在原型中的操作是否受限？
   目的：评估用户在原型中可以执行的操作深度，是否能够进行完整的任务流程。
5. 内容（Content）：
   定义：原型中的内容（如文本、图像、数据等）有多真实，是否与用户的实际使用情境相关？
   目的：确保原型中的内容质量高，能够提供真实的用户情境和反馈。

1.2.1 视觉保真度（Visual fidelity）

视觉保真度指的是在设计视觉界面和物理对象时所投入的精力和细节程度。

视觉保真度是用户对原型最直接的感受维度之一，因为人们往往会"以貌取人"，即使被告知不要这样做。视觉吸引力可以极大地影响用户的第一印象和整体感受。

在设计的早期阶段，视觉保真度通常较低，这意味着原型可能缺乏精细的视觉细节，如颜色、字体、图标和布局等。

在这个阶段，用户更可能更关注于动作/程序/概念，而不是视觉细节。这是因为低保真度的原型足以传达基本的交互和功能，而不会让用户被视觉细节分散注意力。

在设计的后期阶段，视觉保真度应该更高，以便测试可访问性、触摸感受、视觉细节等方面。

在这个阶段，用户界面的视觉吸引力和专业度变得更加重要，因为它们可以影响用户的使用体验和产品的感知质量。

在设计过程中过早地追求高视觉保真度可能会导致问题，因为它可能会分散对其他重要方面的关注。人们往往会有一种错觉，认为当某物看起来完成时，它实际上也已完成。这种错觉可能会误导设计师和利益相关者，使他们认为设计已经完成，而实际上可能还需要进一步的迭代和改进。

设计师有能力快速创建高视觉保真度原型并不意味着这是正确的决定。设计师有时应该故意保持低视觉保真度以鼓励他们想要的沟通和反馈/

1.2.2 交互保真度（Interaction fidelity）

交互保真度指的是原型在模拟真实世界交互行为时的精确程度。

交互保真度高的原型允许用户通过点击、轻触和滑动等动作与屏幕进行交互，并从中获得真实的感受。

这意味着用户可以体验到与最终产品相似的交互反馈和响应。

高交互保真度的原型使得团队能够快速且低成本地测试数百种不同的变化或设计方案。

这种能力对于迭代设计和用户测试至关重要，因为它允许团队在早期阶段就识别和解决潜在的可用性问题。

即使在技术受限的情况下，设计师也可以通过低保真度的原型来探索和测试交互设计。交互保真度的维度允许设计师在不同的保真级别上测试交互设计，从而在早期阶段发现问题并优化用户体验。这种方法有助于在资源有限的情况下进行有效的设计迭代和用户测试。

我们再介绍一些相关的工具。

Vision 是一款原型设计工具，它允许用户将不同的屏幕"缝合"在一起，创建更连贯和完整的交互流程。

Balsamiq 是另一款原型设计工具，它提供了屏幕链接功能，允许用户在不同屏幕或视图之间创建交互。

这些都可以帮助到设计师提升交互保真度。

1.2.3 广度保真度（Breadth fidelity）

广度保真度指的是原型所覆盖的功能数量。

在某些情况下，你可能希望原型包含产品的所有功能，以便全面测试和评估设计。

在其他情况下，你可能应该避免原型覆盖产品的大部分表面区域，因为这些区域可能无法进行任何改变。

这可能是因为这些区域已经非常成熟和稳定，或者改变它们需要大量的资源和时间。

因此在原型设计时，我们应该决定原型的边界。在确定原型的广度时，应该特别关注这些关键的交互点，因为它们对于用户体验和设计的成功至关重要。

1.2.4 深度保真度（Depth fidelity）

深度保真度是指原型所模拟的功能的详细程度，即原型在多大程度上复制了最终产品的功能性。

为了评估原型的深度保真度，可以问自己交互是否"浅层"的。浅层交互意味着原型只模拟了基本的、表面的功能，而没有深入到更复杂的操作或细节。

在评估原型的深度保真度时，需要考虑原型所受的限制（如资源、时间、技术等）对功能模拟的影响有多大。

例如，如果原型由于资源限制而无法模拟某些复杂功能，那么这些"手铐"（约束）对原型的深度保真度来说就非常重要，因为它们限制了原型能够展示的功能范围。

1.2.5 内容保真度（Content fidelity）

内容保真度指的是原型中内容的真实性程度，即原型中包含的信息、数据和材料与最终产品中的实际内容有多接近。

对于用户来说，他们最关心的是视频、数据以及他们团队的名称等实际内容，而不是界面的设计或技术细节。

因此设计师在创建原型时应做出明智的决定，确保原型中展示的内容是准确和相关的。

假设你正在设计一个严肃的招聘应用程序的原型，如果使用像"海绵宝宝（SpongeBob）"这样假的名字，显然与真实应用场景不符。

如果原型中的内容不够真实或相关，用户可能会提供不准确的反馈，因为他们的体验可能与实际使用产品时的体验不符。

另一方面，如果原型中的内容保真度高，用户反馈将更加可靠和有价值，因为他们的体验更接近于真实使用场景。

虽然 "lorem ipsum（占位文本）" 在某些情况下（如展示布局）可能有用，但在需要用户对内容和功能提供反馈的情况下，使用真实的内容可以确保用户反馈的相关性和准确性。内容保真度高的原型可以帮助用户更好地理解和评估设计，从而提供更有价值的见解和建议。因此，设计师应尽量在原型中使用真实或接近真实的内容，以提高原型测试的效果和质量。

1.2.6 其他维度

自主性（Autonomy）：自主性维度指的是原型在测试或使用过程中的独立性。

具有高自主性的原型可以独立于最终产品或系统进行测试和评估，不需要额外的监督或控制。低自主性的原型可能需要在测试过程中进行额外的监督或控制，以确保测试按照预期的方式进行。

平台（Platform）：平台维度涉及到原型运行的环境或基础技术平台。

临时平台可能指的是原型在开发过程中使用的临时或实验性的技术栈或环境，这些可能与最终产品所采用的平台不同。

最终实现平台指的是原型最终将在其上运行的最终技术环境或系统，这可能包括特定的硬件、软件或操作系统。

1.3 同时处理多个维度

同时在多个维度上创建原型（如视觉、交互、广度、深度和内容）可能既复杂又耗时，且成本高昂。

因此建议避免同时在所有维度上进行原型设计，因为这可能导致资源的浪费和效率低下。

提倡采用模块化的方法进行原型设计，即根据不同维度的需求和目标，分阶段或分模块地进行原型设计。

不同的原型工具在处理不同维度时可能有不同的优势和劣势。

例如，某些工具可能在视觉设计方面表现出色，而在交互设计方面则较弱。

在整个设计过程中，可能需要使用多种工具来满足不同阶段和维度的需求。

2. 物理设计

我们现在从概念设计转向更具体地设计。

这时候我们需要考虑更具体、细节地问题。这涉及到考虑更具体的设计细节和问题，如布局、颜色、字体、图标等。

设计过程中可能需要在物理设计（实际的界面元素和布局）和概念设计（抽象的想法和结构）之间进行多次迭代，以逐步完善设计。

在进行具体的界面设计时，需要遵循一些指导原则来确保设计的可用性和有效性。这包含了我们前面说的尼尔森的启发式原则以及施耐德曼的八个黄金法则，当然也可以是专门的风格指南（为界面元素如图标、工具栏等设定的外观和感觉的指南，这些指南可以帮助决定产品的"外观和风格"。）

这包含不同类型地小组件，包括：

1. 菜单设计（Menu design）
2. 图标设计（Icon design）
3. 屏幕设计（Screen design）
4. 信息显示（Information display）

2.1 菜单设计（Menu design）

菜单设计需要考虑以下问题：

1. 菜单的长度：
   需要决定菜单应该包含多少项。菜单项过多可能导致用户难以找到所需选项，过少则可能无法覆盖所有功能。
2. 菜单项的排列顺序：
   确定菜单项的逻辑顺序，通常基于使用频率、相关性或逻辑分组。例如，最常用的项可能放在顶部或易于访问的位置。
3. 菜单的结构：
   决定菜单的结构方式，包括是否使用子菜单（子菜单）或对话框来组织和显示菜单项。子菜单可以用于将相关选项分组，对话框可能用于更复杂的选择过程。
4. 用于分组菜单项的类别：
   确定用于对菜单项进行逻辑分组的类别，这有助于用户更快地找到所需功能。例如，文件、编辑、视图和帮助等常见类别。
5. 分组的表示方法：
   确定如何视觉上区分菜单的不同分组，例如使用不同的颜色、分隔线或其他视觉提示，以帮助用户识别和导航菜单项。
6. 菜单的数量：
   确定应用程序或网站中需要多少个菜单。菜单的数量应基于功能需求和用户界面的组织结构。
7. 使用的术语：
   确定菜单项和菜单中使用的术语。术语应清晰、直观，并与应用程序的功能和用户需求相匹配。
   例如，如果项目是关于攀岩的，术语可能包括"攀岩类型"、"装备"、"技巧"等。
8. 如何适应物理限制：
   考虑如何使菜单适应不同设备的物理限制，如手机屏幕大小、触摸目标等。
   例如，对于手机等移动设备，菜单可能需要优化以适应较小的屏幕，并可能需要考虑触摸屏的易用性。
   

2.2 图标设计（Icon design）

良好的图标设计是困难的：设计出既美观又实用的图标是一项挑战，因为它们需要在很小的空间内传达清晰的信息。

图标的意义是文化和上下文敏感的：图标的理解和接受度可能因文化背景和使用环境的不同而有所差异。某些符号在一种文化中可能具有特定的含义，而在另一种文化中可能有不同的解释。

对于图标设计有以下建议：

1. 借鉴现有的传统或标准。
2. 具体对象或事物比动作更容易表现。

2.3 屏幕设计（Screen design）

屏幕设计中需要考虑的两个主要方面------屏幕的划分和单个屏幕的设计。

屏幕划分（Split across screens）：

这涉及到如何在不同的屏幕之间分配和组织信息和交互。

在屏幕内和屏幕间的移动（moving around within and between screen）：考虑用户如何在不同的屏幕之间导航，以及每个屏幕上显示多少交互元素。

序列工作台风格（serial or workbench style）：这涉及到用户如何按顺序通过一系列屏幕完成任务，类似于工作台上的流程。

单个屏幕设计（Individual screen design）：

这涉及到单个屏幕的视觉布局和组织。

空白空间（white space）：考虑信息/交互和清晰度之间的平衡。适当的空白空间可以帮助用户更好地理解内容和导航界面。

将项目分组（grouping items together）：考虑如何将界面元素分组，以便用户更容易理解和使用。

使用盒子（separation with boxes）：使用边框或容器来区分不同的内容区域或功能。

使用线条（lines）：线条可以用来分隔和组织界面元素。

使用颜色（colors）：颜色可以用来区分不同的部分，同时增强视觉效果和用户体验。

2.3.1 屏幕划分（Split across screens）

我们可以跨屏幕分配功能（Splitting functions across screens）

以任务分析作为起点（Task analysis as a starting point）：在开始设计之前，进行任务分析以了解用户需要完成的任务和操作流程。

设计时，考虑每个屏幕是否只包含一个简单的步骤，以简化用户操作和提高可用性。但是如果将功能分割得过于细碎，导致需要太多屏幕，可能会让用户感到沮丧和不便。

我们还要考虑保持信息可用（Keep information available）：

确保用户在需要时可以轻松访问相关信息，即使这意味着有时需要同时打开多个屏幕。

2.3.2 单个屏幕设计（Individual screen design）

对于单个屏幕设计，我们可以使用颜色、动态效果、边框（boxing）等视觉元素来吸引用户注意到界面中最重要的部分。确保关键信息和功能对用户来说是可见的，以便他们能够轻松找到和使用。

例如，通过高亮颜色或动画效果来突出显示重要信息或功能。

动画可以有效地引导用户的注意力，提供反馈，但也可能分散注意力。因此需要谨慎使用动画，确保它增强而不是干扰用户体验。

通过分组和物理接近性来组织界面元素，可以帮助用户更快地理解和使用界面。

我们需要在界面元素的数量和空间利用之间找到平衡。

界面元素太少可能导致屏幕看起来空旷，而元素太多则可能导致界面显得拥挤和混乱。

2.4 信息展示（Information display）

界面应始终提供用户在任何时候都需要的相关信息，以帮助他们做出决策和完成任务。

对于不同类型的信息意味着不同种类的展示。

例如，文本信息可能需要清晰的字体和布局，而图像或图表可能需要适当的大小和对比度。

同时纸质展示与屏幕数据输入之间应保持一致性。这可以帮助用户更容易地理解和使用系统。

3. 原型设计

3.1 原型类型

有三种原型类型。

1. 一次性原型（Throw-away）：
   这种原型仅用于引发用户反应，测试某个概念或假设。
   创建这种原型的过程必须快速，否则成本会过高，不划算。
   一旦收集到足够的反馈，这种原型通常会被丢弃，不会用于最终产品。
2. 增量原型（Incremental）：
   产品被构建为独立的组件（模块）。
   每个组件分别进行原型设计、测试，然后添加到最终系统中。
   这种方法允许逐步开发和测试产品的不同部分，有助于管理和控制大型项目的复杂性。
3. 进化式原型（Evolutionary）：
   原型会根据设计变更进行调整。
   随着时间的推移，原型逐渐演化，最终成为最终产品。
   这种方法允许在开发过程中不断迭代和改进设计，使产品能够更好地满足用户需求和市场变化。

3.2 具体设计

在产品的设计生命周期中，原型的保真度应该逐步提升。

设计原型时，需要从不同的角度来理解产品，包括：

生态视角（Ecological perspective）：关注产品如何在现实世界中使用，与环境的互动。

交互视角（Interactive perspective）：关注用户如何与产品进行交互，产品的可用性。

情感视角（Emotional perspective）：关注产品如何影响用户的情感和体验。

在设计原型时，应首先关注用户的行为和交互，确保产品的基本功能和可用性。在这些基本要素得到验证后，再逐步关注产品的外观设计和视觉风格。

例如：早期想法阶段，此时的目标是探索和记录各种创意。适合使用低保真度的纸质草图（Low fidelity paper sketches）来快速表达和迭代想法。

概念设计阶段，设计师开始将想法转化为更具体的概念。可以使用低保真度的纸质草图和故事板（Low fidelity paper sketches, storyboards）来进一步发展和沟通设计概念。

中期设计阶段，设计开始变得更加详细，但可能还没有达到最终产品的复杂度。适合使用低保真到中等保真度的线框图（Low to medium fidelity wireframes）来展示设计的结构和流程。

详细设计阶段是设计过程的后期阶段，设计已经非常详细，接近最终产品。

适合使用高保真度的线框图和可编程原型（High fidelity wireframes, programmed prototypes）来精确展示最终产品的界面和交互。

3.3 注意事项

1. 合理化成本-价值权衡（Rationalize cost-value tradeoffs）：
   在设计原型时，需要在成本和所获得的价值之间做出合理的权衡。这可能涉及到决定投入多少资源来创建原型，以及原型需要达到的详细程度。
2. 不要过度承诺 - 能力无法交付（Do not oversell - capabilities that can't be delivered）：
   避免向用户或利益相关者承诺那些无法实现的功能或特性。这有助于管理期望，并确保原型设计的目标是可实现的。
3. 不要过度构建 - "足够好"的原型（Do not overbuild -- "good enough" as a prototype）：
   避免在原型上花费过多的时间和资源，以至于它变得过于复杂或完善。原型应该足够好以满足测试目的，但不必完美。
4. 早期决定探索性或进化性原型（Decide early on exploratory or evolutionary prototypes）：
   在设计过程的早期阶段，决定是创建一个用于探索和测试概念的原型，还是一个随着时间逐步发展的进化性原型。这将影响原型设计的方法和过程。