Lec 11 原型和用户测试
主题包括
- 需求发现
- 头脑风暴
- 原型保真度： 深度、广度、外观、感觉
- 原型的类型
- 纸质原型
- 计算机原型：故事板、表
- Wizard of Oz
- 不要对某个原型产生依恋
- 因为他很可能最终需要被丢弃
用户为中心的设计
设计用户界面的标准方法是以用户为中心的设计（User-Centered Design，它包含三个组成部分：
- 迭代设计
- 早期关注用户和任务
- 持续评估
让我们把迭代式设计过程与另一种方法做一个对比。
瀑布模型（waterfall model）是软件开发中最早被系统化、明确提出的设计流程之一。它把设计过程建模为一系列按顺序进行的阶段。每个阶段都会产生一个具体的产物——例如需求文档、设计方案、一组已编码的模块——并作为输入传递到下一个阶段。同时，每个阶段也包含自身的验证过程：设计要根据需求进行验证，代码要根据设计进行验证（例如单元测试）等。
瀑布模型相比于早期（混乱的）软件开发方式，最大的改进在于它要求开发者在动手写代码之前先进行充分思考。需求和设计通常必须先于第一行代码完成。
如果你学过软件工程课程，你可能已经亲身体验过这个过程。课程组通常会给你一组软件需求——例如聊天客户端或弹珠游戏的规格说明。（在真实世界中，这些需求的识别本身就是软件开发者工作的一部分。）随后，你需要在项目的不同阶段完成一系列里程碑任务，每个里程碑都有明确的产物：（1）设计文档；（2）实现特定功能的代码模块；（3）集成后的系统。
不过，验证并不总是足够的；有时问题会直到下一个阶段才被发现。例如，在实现代码时可能会暴露设计问题——比如设计无法以满足性能要求的方式实现。在系统集成时，可能会发现单元测试未能覆盖的代码错误。因此，瀑布模型实际上隐含需要在阶段之间进行反馈。
真正的风险在于：早期阶段的错误——例如遗漏某个需求——可能直到非常后期的阶段（比如验收测试）才被发现。这类问题可能导致需要对中间所有阶段进行昂贵的返工。
尽管瀑布模型在某些类型的软件开发中是有用的，但它非常不适合用于用户界面（UI）开发。
UI 开发本身具有很高的风险。正如我们在第一节课中讨论的，UI 设计本身就是一件很困难的事情。（你不是用户；用户永远是对的——除非用户不是对的；用户本身也不是设计师。）我们目前（仍然）没有一种简单的方法可以预测某个 UI 设计是否会成功。
在瀑布模型的常见应用方式中，用户只会在流程中的两个阶段出现：需求分析和验收测试。希望我们在一开始（需求分析阶段）确实向用户询问了他们的需求，但之后开发者就会埋头编码，在完成整个系统之前几乎不会再回头与用户沟通。因此，如果设计出了问题，瀑布流程直到最后阶段才会暴露问题。
当 UI 问题出现时，往往需要非常大的修改：可能涉及新的需求或全新的设计。我们在第一讲中已经看到，简单地“打补丁”并不能解决严重的可用性问题。
迭代设计
迭代设计提供了一种管理 UI 设计中固有风险的方法。在迭代设计中，软件会通过不断重复一个设计循环来逐步改进：首先是设想它（设计），然后把它做出来（实现），接着进行测试（评估）。
换句话说，我们必须承认自己第一次通常做不对，并且要提前为这种情况做准备。根据评估结果，我们重新设计界面，制作新的原型，并继续进行更多评估。最终，希望这个过程能够产出一个足够好用的界面。
有时候，人们只是不断重复这个过程，直到满意或者时间和资源用完。但更有原则的方法是为系统设定可用性目标。例如，一个电子商务网站可能会设定目标：用户应当能在30秒以内完成一次购买。
从更高层次来看，迭代设计看起来就像是最糟糕的瀑布模型：我们一路从设计走到验收测试，结果才发现设计有问题，不得不重新再来一遍整个流程。那么迭代设计不就是在说，我们要一遍又一遍重复瀑布流程吗？这里的关键到底是什么？
螺旋模型（spiral model）为这个困境提供了一种解决办法。我们在设计过程中为多次迭代预留空间，并且通过让早期的迭代尽可能低成本来实现这一点。
螺旋模型中的径向维度对应的是每一次迭代的成本——或者等价地说，对应它的保真度或准确程度。例如，一个早期实现可能只是纸面草图或低保真原型。它的细节很少，只是未来真正交互软件外观和行为的一个淡淡影子。但它的制作成本极低，我们可以通过把它展示给用户并询问他们的看法来进行评估。
为什么螺旋模型是一个好方法呢？风险在早期迭代阶段最大，因为那时我们掌握的信息最少。所以我们在早期实现中投入的精力和承诺也应该最少。早期的原型本来就是用完就可以丢弃的。如果我们有多个设计方案，我们还可以同时构建多个原型（并行设计），并对它们进行评估，而不会花费太多成本。接下来这段内容会进一步说明并行设计的价值。
在我们经过几轮评估和重新设计之后，我们（希望）已经学到了足够多的东西，从而避免做出重大的用户界面设计错误。然后我们再真正实现这个界面——也就是说，构建一个我们打算长期保留的原型。之后再对它进行评估，并进一步改进。
我们能够进行的迭代越多，设计中可以做出的改进也就越多。在这里，我们是在做一种逐步爬升的优化，而不是随机探索整个设计空间。我们保留那些有效的设计部分，重新设计那些不好的部分。因此，如果我们能进行更多次迭代，通常就能得到更好的设计。
需求发现
需求发现中最好的信息来源是用户访谈和直接观察。通常情况下，你需要观察用户当前是如何解决问题的。
一套比较完整的信息收集方法可以在需求发现工具中找到总结
情境式访谈是一种结合访谈与观察的方法，在用户真实的工作环境中进行，并围绕真实的工作产物展开讨论。情境式访谈能够促进设计者与用户之间的紧密协作（Wixon、Holtzblatt & Knox，《情境设计：系统设计的新兴视角》，CHI '90）。
参与式设计则是让用户直接加入设计团队——参与需求发现、提出设计想法、帮助进行评估。当目标用户在某个领域的知识远比设计团队更深入时，这种方法尤其重要。例如，为股票交易设计一个界面而没有股票交易专家参与，是不明智的。
将用户直接纳入设计团队
访谈者观察并提出问题
用户展示并讲述自己的做法
进行用户分析的原因很简单：既然你自己不是用户，就需要弄清楚真正的用户是谁。
用户分析看起来非常显然，以至于经常被忽略。但如果不明确去做，就更容易掉入一个陷阱——以为所有用户都和你一样。因此，最好还是先进行一些思考并收集一些信息。
了解用户不仅仅是知道他们的个人特征，还包括他们所处的情境。他们会在什么环境下使用你的软件？周围可能有什么因素会分散他们的注意力？他们的社会环境是怎样的？比如电影院、安静的图书馆、车内、甚至航空母舰的甲板上，这些环境都会对用户界面提出完全不同的限制。
用户情境的其他方面还包括他们在组织中的关系，以及典型的沟通方式。用户之间能互相求助吗，还是彼此隔离？学生与实验室助教、教学助理和教授之间的关系又有什么不同？
需求发现中的很多问题，都是因为过早跳入系统设计造成的。这有时会导致一种“理想化的想法”，而不是基于现实。
了解你的用户，需要了解的内容包括：
- 年龄、性别、文化、语言
- 教育程度（是否具备读写能力？是否具备数理能力？）
- 身体方面的限制
- 计算机使用经验（打字能力？鼠标使用能力？）
- 动机与态度
- 领域经验
- 应用使用经验
- 工作环境与社会环境
- 与他人之间的关系以及沟通模式
常见陷阱：
- 过于关注系统设计，而不是用户本身
- “用户应该拥有电话”
- 把你希望用户具备的条件当成现实，而不是描述用户真实情况“用户应该能读英语，精通斯瓦希里语，惯用右手，并且是色盲”
很多应用程序（如果不是大多数的话）都必须考虑多种不同类别的用户。有些用户群是根据用户在系统中扮演的角色来划分的，比如学生、教师、读者、编辑。另一些用户群则根据用户特征来划分，比如年龄（青少年、中年人、老年人）、动机（早期使用者、频繁使用者、偶尔使用者）。你需要判断哪些用户群对你的问题最重要，并且对每一类用户分别进行用户分析。
最好的信息来源是用户访谈和直接观察。通常情况下，你需要观察用户目前是如何完成这项任务的。
过早系统设计的思维方式也会影响这一部分。如果你从系统的角度去写任务，比如“通知用户预约”，那么你其实是在写需求（系统应该做什么），而不是用户目标。有时候这只是措辞问题，你可以把它换个说法；但它也可能意味着你过于关注系统能做什么，而不是用户真正想要什么。用户目标与实现可行性之间的权衡是不可避免的，但在这个早期阶段，这种权衡不应该主导你的思考。
基于观察的需求发现也可能会过度强调当前的做事方式。现有系统中的步骤往往是具体任务，比如“把文件保存到磁盘”。但如果我们把它抽象为用户目标，比如“确保我的工作被保存”，那么我们得到的是一个本质任务，它在转化为用户界面设计时会提供更丰富的设计可能性。
具体分析的一个危险在于，它可能会保留一些低效的任务，或者那些本可以用完全不同的软件方式来完成的任务。例如，如果我们观察用户使用纸质手册，我们会看到大量翻页行为：“找到第N页”可能是一个重要的子任务。我们可能会据此错误地认为，在线手册应该提供非常高效的翻页和滚动机制，并且投入大量开发资源去优化这些操作。但翻页本身只是纸质书的产物！在在线手册中，也许更有价值的是提供快速有效的搜索和超链接功能。这就是为什么理解用户“为什么这么做”（本质任务）比只看“他们做了什么”（具体任务）更重要。
相反，如果分析不完整，也可能遗漏现有流程中的重要细节。在一个案例中，一家牙科诊所从手工账单转向自动化系统。但诊所助理并不喜欢新系统，因为他们习惯在纸质表格上记录一些重要备注，比如“这个病人的保险处理时间比较长”。而自动化系统没有提供记录这类补充信息的方式。这也说明，即使在观察具体任务流程时，访谈和观察真实用户仍然非常重要。
想法产生
在你收集了关于用户及其目标的信息之后，你需要确定一个关键问题——也就是你要通过开发新的软件来解决的问题。这个问题可能是全新的，也可能是现有工具中的某个问题，你要通过改进来解决，而不是完全从零开始。有时候，这个问题会很明显地跳出来；如果是这样，那很好。如果没有，你就需要自己去生成一些可能的问题想法。这意味着你要仔细阅读并思考所有收集到的信息，然后进行一些想法生成。
这些幻灯片会介绍想法生成的过程。它不仅在这个阶段有用，在项目的下一步也同样重要，因为那时你需要针对已经确定的问题去生成解决方案的想法。
需要注意的是，仅仅进行小组头脑风暴并不是最好的方法。研究表明，如果你和团队成员先各自独立思考，把自己的想法写下来，然后再聚在一起整合并在彼此的想法基础上进行扩展，那么你们能产生更多的想法。在像 IDEO 这样的顶级设计公司里，如果你在每次构思会议上带来的想法少于5个，你作为设计师可能很难长期留下来。
不要过早地固定在某一种方案上。
相反，在整个以用户为中心的设计过程中——包括设计、实现和评估——同时保留多个备选方案会更有帮助。人类在有多个选择时，更容易发挥创造力，也更容易给出有价值的反馈。下面是一些相关证据。
对于个人设计者来说：在迭代过程中始终保留多个设计方案的设计者，往往能够产生更具创造性和更多样化的设计。他们对自己的设计也更有信心，并且最终得到的设计在客观上也更好（Dow 等，《并行原型设计带来更好的设计结果、更高的发散性以及更强的自我效能感》，TOCHI，2010）。
对于团队来说：在团队中分享想法时，分享多个备选设计方案比只分享自己最喜欢的一个方案更好。团队更有可能将不同方案的部分进行整合，从而探索更大的设计空间，同时团队成员之间也会给出更有建设性的批评（Dow 等，《原型动态：分享多个设计可以提升探索、团队关系和最终结果》，CHI 2011）。
对于用户来说：当用户被要求同时使用多个不同的原型时，他们会给出更具建设性的评价（Tohidi 等，《做对设计以及把设计做对：测试多个方案优于单一方案》，CHI 2006）。
多种备选方案之所以有帮助，有两个原因。第一，人类在进行比较时，比起孤立地判断单个事物的好坏，更擅长做出准确判断。第二，只展示一个方案会让它承受过多的情感负担，使得提出该方案的人不得不为其辩护，而其他人也会因此不太愿意提出批评意见。
原型
现在我们来讨论原型设计：也就是用更便宜、更不精确的方式来呈现你目标界面的版本。原型设计在螺旋式设计过程的早期迭代中非常重要，在后期迭代中也同样有用。
我们做原型有几个原因，本质上都可以归结为成本问题，包括金钱成本和时间成本。
第一，原型比完整实现要快得多，因此我们可以更早地进行评估，并尽早获得关于设计优缺点的反馈。
第二，如果有一个难以抉择的设计决策，我们可以通过构建多个原型来分别体现不同的方案，从而进行比较。
第三，如果我们在设计中发现问题，原型也更容易修改，因为它本身就更容易被构建。同样的原因也使得它更具可塑性。最重要的是，如果设计缺陷非常严重，原型是可以直接丢弃的。在设计的早期阶段，不应过度投入或强烈绑定某种设计想法。然而，不幸的是，编写和调试大量代码会带来一种心理上的“投入感”，而这种感觉很难摆脱。你不想丢掉自己花了很多精力做出来的东西，因此即使它确实应该被废弃，你也往往会倾向于保留其中的一部分代码（Alan Cooper，《原型设计的风险》，1994）。
我们在这段内容中看到的大多数原型技术，实际上都会强迫你把原型丢弃。例如，纸面原型不会成为最终软件实现的一部分。这种心态在早期迭代中是很好的，因为它能够最大化你的创造自由。
保真度并不是一个单一维度的概念。原型可以在不同方面表现为低保真或高保真（Carolyn Snyder，《纸面原型设计》，2003）。
“广度”指的是原型所覆盖的功能范围比例。一个在广度上低保真的原型，可能缺少很多功能，只包含完成某些特定任务所需的最基本部分。例如，一个文字处理器原型可能会省略打印功能和拼写检查功能。
“深度”指的是每个功能被实际实现的程度。原型背后是否有真正运行这些功能的后端系统？低深度保真可能意味着功能受限（例如不能双面打印）、使用预设的固定结果（例如无论你输入什么，都打印同一段文字），或者缺乏健壮性和错误处理能力（例如打印机离线时直接崩溃）。
一种用图示来理解广度和深度的方法如下（参考 Nielsen，《可用性工程》，第94页）：横向原型在广度上完整，但深度很浅，本质上是一个没有后端的前端界面；纵向原型则相反，只把某一部分界面做得很深入。
选择构建横向原型还是纵向原型，取决于你想要降低哪种风险。在用户界面设计中，横向原型更常见，因为它们主要用于解决可用性风险。但如果应用中的某些部分在实现上存在较大风险——比如你不确定是否能够满足实现要求——那么就可能需要构建纵向原型来进行验证。
还有一种特殊情况介于横向和纵向原型之间：场景原型。它展示的是某一个具体任务在前端界面中的呈现方式。
计算机原型
所以在某个阶段，我们必须从纸面原型过渡到软件原型。典型的计算机原型通常是横向原型：在外观和交互体验上是高保真的，但在实现深度上是低保真的——也就是说，它背后没有真正的后端系统。
在纸面原型中，由人来模拟后端，因此当用户出现意料之外的操作时，人可以即时生成新的内容来回应；但在计算机原型中，这种灵活性通常不存在。
计算机原型：
交互式软件模拟 在外观和交互体验上是高保真 在实现深度上是低保真 纸面原型由人来模拟后端，而计算机原型通常没有这样的“人类后端” 计算机原型可能是横向的：覆盖大部分功能，但没有后端支持
例外情况：所谓“魔法师原型”（Wizard of Oz 原型）同时具有较广的覆盖范围和较深的模拟程度，但实现起来比较困难。
构建计算机原型的一种方式是直接用实现语言（如 Java 或 C++）进行编程，并使用用户界面工具包（如 Swing 或 MFC）。如果你不接入后端，或者用占位程序（stub）代替真实后端，那么你得到的就是一个横向原型。
不过，通常使用原型设计工具（比如 Figma）会更好。用工具搭建界面通常比直接编码更快，而且不需要调试代码，也更容易修改，甚至在设计错误时可以直接丢弃。
从长远来看，可以推测原型设计会比编码更重要，因为最终LLM模型很可能能够完成你原型的代码实现。但原型设计本身是一项约束更少的任务，因此模型要做好这一点可能还需要更长时间。
原型工具可以帮助你先把界面视觉设计和结构想清楚，这样之后再转到代码时，你就知道自己是在“努力让布局管理器实现你已经设计好的效果”。
即使使用原型工具，计算机原型仍然可能非常耗时。例如，当微软 Excel 在考虑加入拖拽功能时，两名微软暑期实习生用 Visual Basic 开发了一个原型。他们发现，为了测试拖拽功能，必须先实现大量基础的表格功能。结果他们花了整个夏天才完成这个原型，而真正把拖拽功能加入 Excel 的正式实现，只用了一个全职程序员一周时间。
当然，这个对比并不完全公平——也许花费六个实习生月来降低一个全职开发一周的风险是值得的，而且实习生也从中学到了很多。但关键点是：计算机原型很容易变成一个“滑坡”，让你不知不觉投入过多精力。所以不要被它拖得太深，要始终专注于你真正想测试的内容，也就是你需要降低的设计风险，并且只针对这一部分进行原型设计。
构建计算机原型有两种主要技术。
故事板（storyboard）是一系列（严格来说是一个图结构）固定的界面屏幕。每个屏幕上有一个或多个热点区域，用户可以点击这些区域跳转到另一个屏幕。有时屏幕之间的切换还会加入一些动画，用来展示动态效果，比如鼠标悬停反馈或拖拽反馈。
表单构建工具（form builder）是一种通过从组件面板中拖拽控件，并将它们放置在窗口中的方式，来绘制真实可运行界面的工具。
魔法师原型（Wizard of Oz prototype）是一种介于计算机原型和纸面原型之间的混合形式：用户是在与计算机交互，但在系统背后有一个人实时决定界面应该如何响应用户操作。
Photoshop 经典上常被用来做故事板（也称为“线框”原型），但现在也有一些其他工具越来越流行。Balsamiq Mockup 和 Mockingbird 都提供画布以及图形对象面板，这些对象看起来像界面组件，可以拖拽到画布上使用。然而，这些工具与表单构建工具不同，它们生成的结果只是图片——这些“组件”并不是真正的控件，也不具备实际功能。
这些线框工具在视觉上刻意追求某种“草图感”，因此它们属于中等保真度工具。它们不像手绘草图那样低保真，但也还没有达到最终界面的真实呈现效果。
故事板的一个最大优点和纸面原型类似：你可以在故事板上画任何你想要的东西。这种自由度能够释放你的创造力，而这是表单构建工具做不到的，因为后者只能使用固定的组件库。
它的缺点来自于其静态特性。有些工具允许用超链接把不同的图片连接起来，但即便如此，你能做的也只是点击，而无法进行真正的交互。当用户在故事板前进行测试时，常常会变成一种“寻找热点”的游戏，就像儿童软件一样，唯一的目的就是在屏幕上找到可以点击的地方，看看会发生什么。
这种“寻找热点”的现象意味着，故事板在用户测试中的作用很有限，不像纸面原型那样有效。一般来说，横向计算机原型更适合使用其他评估方法，比如启发式评估。
表单构建工具
从标准界面组件直接构建可运行的图形用户界面 Mac Interface Builder（Mac 界面构建器） Qt Designer（Qt 设计器） FlexBuilder Silverlight Visual Basic
与故事板不同，表单构建工具使用的是真正可工作的界面组件，而不仅仅是静态图片。因此，这些组件的外观和最终实现中的界面基本一致（前提是你使用的是兼容的表单构建工具——例如，用 Visual Basic 做的原型，未必会和最终用 Java 实现的界面完全相同）。
另外，由于表单构建工具通常底层依赖某种实现语言——甚至可能就是你最终用于开发正式界面的同一种语言——因此你可以根据需要接入部分或全部后端逻辑。
但缺点是，表单构建工具提供的是固定的标准组件库，这会限制设计者的创造力，也使它们不太适合用于复杂图形界面的原型设计，比如电路绘图编辑器这类应用。表单构建工具更适合用于界面周边的菜单和控件设计，但无法很好地模拟应用窗口“内部”的复杂交互逻辑。
纸面原型的一个强大之处在于，可以通过让人类来模拟后端，从而达到较高的“深度”。魔法师原型（Wizard of Oz 原型）同样使用人类来充当后端，但前端则是一个真实的计算机系统，而不是纸面草图。这个名字来自同名电影，其中“魔法师”其实是一个躲在帘幕后面操控巨大而复杂装置的人。
在魔法师原型中，“魔法师”通常（但不一定）是对用户隐藏的。这种原型常用于模拟尚未实现的未来技术，尤其是人工智能。例如，一个著名案例是“听写打字机”（Gould, Conti, & Hovanyecz，《用模拟听写打字机写信》，CACM，第26卷第4期，1983年4月）。该研究旨在比较早期80年代的技术水平下，孤立词语语音识别与连续语音识别的效果与可接受性，而当时连续语音识别还无法实现。
该系统的界面是一个语音控制的文本编辑器。用户看着屏幕，通过麦克风口述内容，而麦克风连接到另一个房间中的打字员（即“魔法师”）。魔法师使用键盘操作用户屏幕上显示的编辑器。
在这个实验中，魔法师的能力非常关键。她每分钟可以打80个单词，并且在模拟系统上进行了数周练习（期间还对模拟器进行了迭代设计，以优化她的操作界面）。她非常注意逐字输入用户说的内容，包括感叹词、括号内容以及各种插话。
计算机也在一定程度上帮助让她的输出更接近真实语音识别系统的表现。例如，系统会在固定词典中查找她输入的每个单词，不存在的词会被替换为“X”，以模拟识别错误。此外，为了模拟系统对上下文的缺乏理解，同音词会被替换为更常见的拼写方式，比如 “done” 会替换 “dun”，“in” 会替换 “inn”。最终结果形成了一种非常有效的假象。大多数用户在实验过程中（中途）被告知真相时都感到惊讶——他们没想到自己是在和一个人对话。
对于魔法师来说，进行机械化思考和操作比纸面原型更困难，因为这种方法通常用于模拟更“智能”的任务。如果魔法师对类似系统的能力有一定了解，会更容易提供逼真的模拟。此外，如果魔法师的操作界面能够刻意简化输出，也会有帮助，就像 Gould 的研究中所做的那样。
设计魔法师原型的一个关键挑战是：你实际上需要同时设计两个界面——一个是用户界面（也就是你要测试的界面），另一个是魔法师使用的后台操作界面。