PDF案例研究：用户体验设计与敏捷：天作之合？
一位来自 SAP 的用户体验设计师和一位软件工程师讨论了在业务智能查询工具上协作的挑战。
用户体验 (UX) 设计位于可用性、人机交互 (HCI) 和交互设计等多个领域的交叉点，它关注软件用户的整体体验：从登录到导航、访问、修改和保存数据。不幸的是，用户体验设计常常被忽视或被视为“事后补救”，只有那些有额外时间和预算的项目才能顾及。然而，仔细设计用户体验对于产品的成功至关重要。这不仅仅是表面功夫：关于用户体验的选择会对软件产品的底层架构、数据结构和处理算法产生重大影响。
为了提高我们对用户体验设计的理解及其在软件开发过程中的作用，我们在此重点关注一个项目，在该项目中，用户体验设计师与软件工程师紧密合作，构建了 BusinessObjects Polestar（目前以 SAP BusinessObjects Explorer 的名义销售），这是一款专为临时业务用户设计的 BI（业务智能）查询工具。过去，此类用户没有自己的 BI 查询工具。相反，他们会将业务查询传递给分析师和 IT 人员，然后由他们使用复杂的 BI 工具从数据仓库中提取相关信息。Polestar 团队希望利用公司更复杂的 BI 查询工具的许多后端处理功能，但新软件需要一个更简单、更友好的用户界面，并减少晦涩难懂的术语。因此，良好的用户体验设计至关重要。
为了了解开发过程，我们与 Polestar 团队的两名关键成员进行了交谈：软件架构师 Jean-Luc Agathos 和高级用户体验设计师 Julian Gosper。Agathos 于 1999 年加入 Business Objects 巴黎办事处，并在 2007 年 SAP 收购该公司后继续留在公司。Gosper 五年前开始在该公司位于加拿大不列颠哥伦比亚省温哥华的办事处工作。两人在项目早期就开始合作，就在创建了一个包含 Gosper 一些初始用户体验设计的 Java 原型之后。由于关键的后端架构是由巴黎软件工程团队早期开发的，因此 Gosper 加入了巴黎团队，共同努力在那个架构之上实现 Polestar。
为了引导我们的讨论，我们请来了一对开发人员，他们的技能组合在很大程度上反映了 Agathos 和 Gosper 的技能组合。Terry Coatta 是一位资深的软件工程师，也是位于加拿大不列颠哥伦比亚省温哥华的 Vitrium Systems 的首席技术官。他还是 编辑顾问委员会的成员。与 Coatta 一起提供用户体验设计方面另一种视角的是 Richard Rutter，他是一位资深的 Web 设计师，也是位于英国布莱顿的用户体验设计公司 Clearleft 的创始人。
在深入了解 Agathos 和 Gosper 之间的合作如何展开之前，熟悉经典用户体验设计的一些基本原则是有益的。
情境调查。 在开发用例之前，团队会观察当前工具的用户，并记录痛点所在。情境调查通常有助于识别用户自己没有意识到的问题。不幸的是，这通常很昂贵，因此并非总是执行。
形成性测试。 形成性测试用于了解用户体验设计在多大程度上解决了产品的预期用例。它还有助于确定这些用例与真实世界体验的贴合程度。在准备阶段，用户体验设计师通常会创建轻量级原型来表示产品最终将要服务的用例。通常这些是纸质原型，测试组参与者只需翻阅并对其进行评论即可。对于 Polestar 项目，用户体验团队使用了可工作的 Java 原型来促进早期的形成性测试。
总结性测试。 在总结性测试中，用户根据一些脚本试用完成的软件。这些测试的反馈通常用于为下一轮开发提供信息，因为它通常在流程中来得太晚，以至于无法将重大更改纳入当前版本。
虽然 Polestar 团队没有预算进行情境调查，但他们能够与构建了负责催生该项目的研究原型的软件工程师紧密合作。这使他们能够借助可工作的用户体验设计进行早期的形成性测试，这反过来又使得改进将用作进一步测试基础的用户故事成为可能。与负责初始设计的软件工程师合作，还可以从性能和可行性的角度评估一些初始用户体验设计，从而避免了在正式开始开发后出现许多不受欢迎的意外情况。
TERRY COATTA 您提到您早期与一位软件工程师合作迭代了一些轻量级的纸质原型。工程师在该过程中扮演了什么角色？
JULIAN GOSPER 构思该项目的高级产品经理 Adam Binnie 将我引入，以详细阐述早期 Polestar 原型的交互设计。为研究目的制作了初始概念验证的 Davor Cubranic，正在寻求将我开始与 Adam 合作的一些用户体验想法融入到他的原始设计中。Davor 认为创建一些新概念的 Java 原型是有价值的，这样我们不仅可以使用纸质原型，还可以使用最终用户可以与之交互的实时原型，并且开发团队可以从技术角度进行评估。我真的推动了这一点，因为我们已经有了这个出色的开发资源可供我们使用。而且，Davor 似乎不需要花费太长时间就能敲定一些关键的用户体验概念，这当然会使实时原型成为形成性测试的更好载体。
一般来说，作为一名交互设计师，您不想投入大量时间来编写实时程序，因为您真正想要的是快速迭代设计的基本原理。这就是为什么在项目早期使用纸质原型如此普遍且有效的原因。通常，我们会使用 Illustrator 或 Visio 来模拟关键用例及其相关的 UI、交互和任务流程，然后输出一个 PowerPoint 文件，您可以翻阅该文件以了解典型的用户会话。然后，各种项目干系人可以标记该文件以向您提供反馈。您还可以获得一个用于形成性测试的工具。
然而，在这种特定情况下，在该阶段与开发团队密切合作很有吸引力，因为我们在用户界面方面采取的一些方向可能会对后端产生严重影响——例如，应用程序每次点击都能返回和重新评估各个方面和可视化的能力。让 Davor 在那里通过基于 Java 的轻量级原型的快速迭代，立即从性能角度帮助评估这些提议的设计更改，有助于从一开始就创造出一套良好的协同效应。
JEAN-LUC AGATHOS 即使我直到后期才参与该项目，但看起来 Davor 已经制作了一个可靠的概念验证。他还在此过程中弄清楚了一些非常重要的处理步骤，此外还评估了我们稍后在过程中开发的一些关键算法的可行性。我认为这对项目至关重要，因为即使人们倾向于认为用户体验仅仅是关于事物的显示方式，但弄清楚如何操作这些东西以便能够有效地处理它们也很重要。
JG 完全正确。为了使该产品获得成功，性能至关重要——无论是在处理大型数据索引方面，还是在能够评估要返回给用户的哪些方面以支持以迅雷不及掩耳之势点击浏览新的数据分析的体验方面。评估元数据相对于任何特定新查询的相关性的能力实际上一直是 Davor 的真正关注点，因此他最终推动了与我所做的改进界面可用性的工作并行进行的调查。
我确实记得与 Davor 进行过讨论，他说：“你知道，如果你以你建议的方式处理‘X’，将会对性能产生重大影响；但如果我们以另一种方式处理，我们可能会获得更好的响应时间。”因此，我们像那样来回讨论了很多，我认为这最终使用户体验设计比我们采用典型的瀑布式方法可能实现的设计要好得多。
TC 当用户体验方面的事情仍在最早的整理阶段时，产品工程师通常会对参与项目感到兴奋吗？
J-LA 是的，我认为开发人员需要在流程的早期尽可能多地了解用户故事。对我来说，用户体验和开发本质上是一回事。我认为我们将用户故事转化为可交付成果是我们的工作。
当然，在开发中，我们通常从架构图或其他来自产品管理的产品描述开始工作。我们还在期待用户体验人员弄清楚交互模型应该是什么样子。
关于 Polestar 的第一个版本，有趣的是 Julian 基本上最终承担了这两个角色。他充当项目经理，因为他知道用户故事是什么以及他希望如何在产品功能方面处理每个用户故事。他还清楚地知道他希望如何在 UI 中公开所有这些内容，以及他希望最终用户最终如何能够与系统进行交互。从我的角度来看，这大大简化了事情，因为我只需要向一个来源寻求指导。
TC 你们在这个项目上使用了敏捷方法。软件开发人员和用户体验设计师可以在流程的哪个阶段开始并行工作？
JG 如果您有一组由项目执行成员商定的良好用户故事，并且包含与相关工作流程和用例的明确定义，那么敏捷迭代过程就可以开始了。在那个时候，您能够具体了解产品需要提供的功能和体验。在此基础上，用户体验交互设计师和开发团队都应该有足够的信息开始并行工作。也就是说，开发人员可以开始处理产品需要做什么，而用户体验人员可以处理用例图、线框图和场景，并开始协调最终用户的时间以提供所需的任何验证。
重要的是，您需要让许多不同的人参与进来，以帮助将这些用户故事汇总在一起。显然，用户体验团队需要参与其中，但开发团队也应该参与——以及业务分析师和任何其他可能对产品需求应该是什么有一些见解的人。这就是我们在谈论基于一些共同的“模型”开始开发时我的想法。
**
在很大程度上，Polestar 第一个版本的开发进展顺利。Gosper 与原型开发人员的合作帮助早期解决了一些技术挑战，并改进了主要用户故事，这为与 Agathos 一起实施产品铺平了道路。从该过程中产生的用户界面确实面临一些挑战，这些挑战在总结性测试期间得到了验证，当时版本 1 的开发工作基本上已经完成。当时，临时业务用户的查询工具普遍匮乏，这也加剧了这个问题。幸运的是，Gosper 和他的用户体验团队有自由创新他们的设计。然而，这种创新意味着该软件不可避免地最终会融入新的设计概念，即使经过多次形成性测试迭代，这些概念的用户接受度仍然不确定。
在 Polestar 后续版本的开发过程中，一旦 Agathos 和 Gosper 不再合作，又出现了进一步的挑战。为了响应用户反馈，新的用户体验团队决定对 UI 进行根本性的更改，这迫使工程团队重新架构软件的某些部分。除了这些挑战之外，新团队还了解到，当对底层概念模型感到困惑时可能会发生什么，而 Agathos 和 Gosper 在第一阶段的开发中设法避免了这种情况。
当然，这并不是说初始阶段完全没有开发挑战，其中一些挑战可能归因于向管理层证明新尝试的价值的压力。
**
RICHARD RUTTER 这个项目最具挑战性的部分是什么？
J-LA 一大挑战是，就在我们收到最初的 Java POC（概念验证）之后，我们收到消息，我们需要在不到两周的时间内制作一个 Flash 版本，以便在 Business Objects [现在的 SAP BusinessObjects] 国际用户组会议上展示。实际上，这只是我们面临的众多约束之一。POC 本身在如何处理数据以及向用户公开适当的方面方面施加了某些约束。用户故事已经驱动了一些 UI 约束。然后我们得知我们只有几周的时间来准备一些东西以展示给客户。最后，强烈建议我们使用 Adobe Flex——我们以前甚至没有意识到这一点——来完成这项工作。
因此，我们的首要任务是学习该技术。最初，我们对此感到非常沮丧，因为这实际上并不是我们有选择余地。然而，我们没有与之抗争，而是很快意识到这是一个非常好的主意。Flex 非常强大，它实际上使我们能够及时为用户会议提出一个可工作的原型。
JG 该项目有一个特殊的方面，它被指定为创新——迈向下一代自助服务 BI 的一步。在此之前，公司从未将面向业务用户的轻量级业务智能工具产品化，因此我们在公司内部或市场中都没有太多类似的产品可以参考。因此，我们最终推进的设计从用户采纳的角度来看有点冒险。
老实说，Polestar 的第一个版本最初往往会让用户感到困惑。我们测试的大多数用户都需要花费几分钟时间探索该工具，才能真正理解设计隐喻和整体用户体验。
J-LA 的确如此。
JG 这在用户体验团队中引发了相当多的争议，因为当时围绕形成性测试的一些方法论因站点而异。分配给该项目的下一批设计师最终对如何改进交互设计并使其更直观得出了不同的结论。有人质疑我们在界面多个不同领域从根本上是否采用了正确的交互开发方法。我们以一种相当独特的方式使用了分面导航，我们围绕分析创建的交互也非常新颖。[由于用户通常对他们正在寻找的某些信息参数或方面只有模糊的概念，因此分面导航是一种 UI 模式，它允许用户交互式地改进搜索的相关类别（或“分面”）来促进查询。]
许多初始设计方向最终在巴黎用户体验团队开发产品的第二个版本时被重新探索为开放主题。他们最终得出了一些不同的结论，并开始推广一些替代方案。当然，这对于产品的发展可能非常健康，但与此同时，当新的 UI 选择与您已在底层运行的代码不完全一致时，它确实会挑战开发团队。
TC 我认为另一个可能出现巨大问题的领域与用户体验设计的反馈过程有关。我经历过那个过程，发现它极具挑战性。例如，假设您需要找到两个彼此相关的业务对象。假设我们知道其中一个对象可以在多个业务领域共享。一种可能性是它们共享唯一的所有权，这将对用户体验产生巨大的影响。当我们遇到类似情况时，我们经常难以将语义含义传达给负责 UI 的人员。我想知道您是否遇到过类似的情况。
J-LA 实际上，Julian 在加入我们在巴黎的团队之前就已经解决了所有这些问题，因此我们在最初一轮开发中没有遇到任何类似的问题。然而，在后来的版本中，我们在管理模块中遇到了“信息空间 (infospace)”问题，这是一个我们仅向管理员公开的概念。这个想法是，您可以基于某些数据源创建一个信息空间 (infospace)，该数据源可以是 BWA（Burrows-Wheeler Alignment）索引，也可能是 Excel 电子表格。[BWA 是一种快速、轻量级的工具，可将相对较短的查询与序列数据库对齐。这些序列通常以 FASTA 格式索引。]
在任何人可以使用系统的探索模块来调查这些信息空间 (infospace) 之一之前，必须对该空间进行索引，从而产生一个新的索引实体。这看起来很简单，但是当我们花费大量时间试图就当一个人碰巧正在探索一个信息空间 (infospace) 而另一个人试图索引同一个空间时应该发生什么达成一致。事实证明，这些讨论很困难，仅仅是因为我们没有明确指出所讨论的实体是一个索引。也就是说，我们最初严格地将其称为信息空间 (infospace)。直到经过几次争论之后，才清楚我们实际上谈论的是该信息空间 (infospace) 的索引。
每当可以精确地讨论模型时，您就可以避免许多不必要的复杂性。当一个模型从项目一开始就被正确且清晰地定义时，唯一应该需要的反馈类型——以及您在后续迭代中应该需要添加的唯一类型的更改——与您想要公开事物的方式有关。例如，您可能会决定从下拉框更改为列表，以便用户可以更快地访问某些内容——只需单击一下，而不是两次。如果您从一个清晰的模型开始，您可能不需要在以后进行任何可能对 UI 或底层架构产生重大影响的更改。
**
在开发市场上没有明显同类产品的产品时，Agathos 和 Gosper 已经在某种程度上驶入了未知的领域。他们还将面临另一个未知的领域：他们都没有使用过敏捷方法来实现用户体验设计。加剧这种不确定性的是敏捷开发方法本身，其原则包括需要接受需求变更，即使在开发过程的后期也是如此。
幸运的是，Polestar 团队很快接受了迭代开发过程及其所有固有的不确定性。事实上，Gosper 和 Agathos 都发现敏捷方法比瀑布式方法在实现用户体验设计方面更有效。但这并不意味着一切都一帆风顺。敏捷需要团队成员之间的密切协作和频繁的面对面沟通，通常是在具有截然不同的背景和技术词汇的干系人之间进行。因此，团队最大的挑战之一是确保沟通尽可能清晰有效，这也就不足为奇了。
**
TC 我了解到一些用户体验设计师认为敏捷与其说是要合作，不如说是要绕过。然而，这是您第一次面临使用敏捷方法实现用户体验设计，而且看起来您非常喜欢它。这是为什么呢？
JG 在理想的世界中，您会在开始实际编写代码之前完成所有情境调查、纸质原型制作和形成性测试。在现实中，由于产品构思和产品发布之间的周转时间持续缩短，这根本不可能。如果要在瀑布式项目中实施用户体验设计，那么一旦编码开始，就很难知道如何利用您对用例的了解并将其付诸实践。
相反，如果您嵌入在开发团队中，并且战术性地了解他们计划在未来两到三个迭代中完成什么，那么您可以开始计划如何根据用户体验的不同方面进行测试。
TC 换句话说，您只是摸着石头过河？
JG 是的，在不了解所有答案的情况下直接投入开发可能会有点可怕。我这样说不仅仅是指您没有机会研究某些领域以确保从工程角度来看一切都说得通；您也不能确定如何表达设计，因为没有足够的时间对其进行迭代以充分了解什么最有可能对用户有效。然后，您还必须考虑所有层面的开发因素。所有这些都同时发生，因此您必须对周围发生的一切保持高度警惕。
迭代计划中也有很多来回沟通需要进行。例如，Jean-Luc 会告诉我，我们确实需要在某个特定的迭代之前整理出用户界面的某个方面，这意味着我基本上收到了我的行动指令。相反，有时我也需要及时看到一些特定的功能就位，以便将其用作我想要纳入即将到来的形成性测试中的实时构建的一部分。仅这一点就需要大量的协调。
对迭代计划的另一个重要影响来自产品管理，因为他们也经常希望能够在某个特定日期之前展示某些功能。由于所有这三个既得利益集团都在不断争夺在特定时间点之前实现产品的某些部分，因此在此过程中需要进行大量的谈判。
RR 是的，但我认为您必须接受，在此过程中对部分内容进行一些重新工程是该过程固有的组成部分。也就是说，根据测试的反馈，您可以指望未来的迭代涉及对至少一些已构建的内容进行重新工程。但只要那是您的预期……就没问题。
J-LA 我认为您说得对：我们必须培养一种接受沿途变更的心态。但我实际上认为最大的问题是工具。我们今天拥有的开发工具无法帮助我们进行所有这些迭代，因为它们没有为我们提供足够的业务逻辑和 UI 之间的分离。理想情况下，我们应该能够从上到下更改 UI，并重新审视绝对的每一位，而无需触及底层逻辑。不幸的是，今天情况并非如此。
JG 这就是为什么，作为一名用户体验交互设计师，您必须准备好向产品开发人员证明您推荐的任何更改都是基于实质性证据，而不仅仅是一些直观的或轶事的对用户需求的理解。您需要提出强有力的理由，并能够使用尽可能多的定量和定性最终用户验证数据来支持设计更改。
TC 到目前为止，我们主要从用户体验的角度来看待这个问题。从更工程的角度来看，使用敏捷方法来实现用户体验设计有哪些好处和挑战？
J-LA 我们在这个特定项目中面临的最大挑战——至少在我们完成 Polestar 的第一个版本之后——与在我们即将完成版本时对整体架构所做的更改有关。即使在敏捷环境中，您仍然需要预先非常彻底地考虑问题，然后勾勒出您的设计，制作原型，对其进行测试，并继续修复它，直到它变得稳定。一旦您为架构中的任何给定层实现了相当稳固的东西，您就需要完成它并继续处理下一个更高的层。从这个意义上说，它就像建造一座建筑物。如果您必须回到地基，一旦您已经进入流程的后期阶段，就开始进行一些相当重大的更改，您很可能会最终损坏您已在其之上构建的所有其他东西。
敏捷的优点在于，它允许在沿途的每次迭代中输入设计——以及一些关于该设计输入背后的推理的讨论。这非常重要。例如，当我们与 Julian 合作时，他向我们解释说，Polestar 的基本设计目标之一是将最终用户完成任何特定任务必须执行的点击次数降至最低。他还谈到了这如何应用于每个最重要的用户故事。对于我们开发人员来说，这确实有助于理解所有这些。
我认为我们几乎没有进行过像那样的交流——这不仅适用于用户体验人员。与项目经理进行类似的讨论也很好。
JG 在 Polestar 项目的那些讨论中，对我来说最大的挑战之一是如何确定在描述特定设计规范时要深入到什么程度。有时，一套支持特定用例的线框图似乎已经足够好了，因为我想传达的大部分内容都可以从中推断出来。但是，在其他时候，将事情分解为更细粒度的规范对我来说会很有帮助。在当时弄清楚这一点有点挑战，因为一方面您试图管理您的时间，以便为下一次迭代生成规范，但另一方面您希望使它们达到适当的深度。
另一个挑战是每个领域都有自己的技术语言，有时要确保您正确理解您听到的内容可能很棘手。例如，我记得有一次迭代，我非常关注一组与用户指定他们可能正在探索的数据的财务期间的功能有关的功能。因此，我变得非常积极地尝试让产品管理部门为这项工作分配更多资源，因为我确信如果功能不足，这将成为最终用户的主要痛点。
在那段时间里，我记得看过一个迭代评审演示文稿，其中提到了许多功能，其中一些功能与日期和财务期间等相关。在每个项目旁边都有“d-cut”的注释。我一句话也没说，但我只是惊呆了。我当时想，“哇！所以他们只是决定删减那个。我简直不敢相信。而且甚至没有人费心告诉我。”但当然事实证明“d-cut”代表“开发删减 (development cut)”，这意味着他们已经实现了这些项目。因此，有时您最终可能会彼此说错话，仅仅是因为每个人都在使用特定于自己技术领域的术语。当然，产品和项目管理也是如此。
TC 每个领域使用的不同工具是否也对这些沟通问题有所贡献？
J-LA 我完全同意。例如，当您用 Java 编程时，有些事情您可以表达，有些事情您不能表达。同样，对于架构师来说，使用 UML 等语言在某些方面会限制他们。他们最终不得不在告诉系统他们实际想要什么之前问自己大量问题。
TC 既然我们正在谈论工程师和设计师如何生活在不同的世界中，因此使用不同的工具、不同的技能组合和不同的世界观——您如何看待让软件工程师直接参与形成性测试？这个想法会引起您的兴趣吗？还是看起来很危险？
JG 实际上，两者都有。这完全取决于您如何根据这些信息采取行动。在某个时候，会有一个内部验证过程，即将要发布的产品会向公司中比最初的干系人群体更广泛的群体开放。然后，所有这些人都会得到一个脚本，使他们能够演练产品，以便他们可以亲身体验它。
这自然会引发一批针对接近尾声的项目的反馈，而这时我们已经没有太多时间采取行动了。在许多反馈中，人们不仅指出问题，还提供解决方案，例如：“那个复选框不能是绿色的，把它改成灰色。” 当然，全盘接受这些意见可能很危险。 我认为，通过开发或任何其他内部渠道获得的反馈，应该为下一次用户研究奠定良好的基础。
RR UX 设计应该始终在整个过程的多个不同阶段与大量不同的最终用户接触。 不过，正如 Julian 所说，关键在于如何处理这些信息。 解决由此暴露出来的问题，这正是 UX 设计师的工作。
Q
喜欢它，讨厌它？ 请告知我们
© 2010 1542-7730/10/1100 $10.00
最初发表于 Queue vol. 8, no. 11—
在 数字图书馆 中评论这篇文章
© 版权所有。