领先技术 - 不要拿 UX 冒险 - 使用线框

作者：Dino Esposito | 2016 年 1 月

Dino Esposito 请允许我改写不朽的科学家 Albert Einstein 的话，我敢说，虽然我不知道未来软件体系结构面临着什么，但是谈到即将到来的变化，其中一项肯定是层设计方面使用的自上而下方法。UXDD 是用户体验驱动设计的缩写，这种方法主要是促进将线框和情节提要用作软件体系结构的起点。在 UXDD 中，获取过程的结果不再是枯燥单调的需求集合，取而代之的是生动有趣的草图集合，这些草图集合可以清楚地指示用户喜欢的工作方式。毫无疑问，用户喜欢的工作方式是实际业务流程清楚明白的软件表示形式。在我看来，技术正在失去它数十年来在软件体系结构中拥有的核心地位。今天我们更看重的是架构师在考虑特定技术、传统平台、技能和预算的现有投资的前提下，结合可用技术和产品以实现一组特定目标的能力。

听起来像过去的想法？好吧，它可能是。软件远景不再是什么新鲜事物了，但这是一种从未成为主流的软件远景。

定义线框

我一直使用“线框”一词，并且将它与“草图”一词互换使用。我会从 UXDD 的角度出发，说明线框和“模型”之间一成不变的差异。下面是 UXDD 中的一些术语定义：

草图是一种主要用于草草记下和捕获酷炫想法的手绘图。纸张是保存草图的理想表面，包括自动餐厅里的餐巾纸。草图可能表示体系结构的顶层框架，但是它更可能捕获到用户和系统之间的交互想法。
线框是一种更加精密和准确的草图类型，因为它添加了与布局、导航逻辑有关的信息以及内容组织的详细信息。与此同时，线框不涉及颜色、图形、阴影和字体等 UI 细节。
当扩展线框以合并图形外观时，它就变成了模型。

模型和线框之间有一个关键的心理差异。当您向用户展示应用程序模型时，用户会不可避免地关注图形方面（如背景图像、颜色和样式）。用户很少会关注信息的组织以及相同信息的导航和布局方式。线框是一种完全没有图形内容的稀疏模型。可以手动绘制线框或者通过通用绘图工具（如 PowerPoint、Visio 或 Balsamiq）绘制。但是，更专业的工具似乎将线框连接在一起，因而形成的情节提要可以让用户对最终体验有个具体了解。

为什么线框是经济高效的

开发者们普遍认为在规划后端之前，应使用线框形成表示层的理念。他们认为这种做法大有裨益。多年来，本行业的人们一直在培养一种理念，即构建应用程序其实与设计建筑物相同。然后在敏捷运动中，人们开始反对一种理念，即在编写代码前我们需要大量的前期封闭式设计。敏捷并不表示没有设计和分析，我想要说的是情况刚好与之相反，但是敏捷可能未能解决软件开发的核心问题。软件的终极目标是什么？我们编写软件仅仅是为了存储和处理数据吗？并非如此，我们编写软件的主要目标不正是为了让用户更高效、更快速地执行业务任务吗？到了今天，随着相关性的不断增长，在后一种方案中，最重要的就是表示层。本例中的敏捷性意味着与用户进行迭代和协作以定义一组可接受的线框和情节提要，而不是与足够的信息进行迭代和协作来创建一个良好的持久性模型。

但是软件经理们经常把花费在线框上的时间看作是不会带来可交付结果和直接效益的无用成本。因此，让团队关注实际的软件项目可以避免这种情况。软件和土木工程之间的类比是一种为时甚久的类比，回顾这种类比有助于我们讨论以下内容：如果想要建造一个车库（更不用说更复杂的建筑物类型），您是打算先说明您想要的东西还是希望砖匠将砖头堆在一起，然后抱怨他们提供了一些您不想要或未要求的东西？

创建和验证线框是需要管理的额外任务并且会产生额外成本。但是，调整草草记下视觉对象屏幕的线框是一回事；调整由数以千计的代码行组成的多层系统又是另一回事。通过采用线框和 UXDD，在编写一行代码前，您肯定要花费更多的时间。但一旦您交付了第一次冲刺任务之后，您会节省大量的时间。当系统完成了一半并且可以更好地体验和评估其效果和好处时，您可以节省更多的时间。使用 UXDD 后，您可以比以往任何时候更接近于实现立即交付项目这个梦想。您在后续冲刺和改编中节省的时间要远远多于您前期花在线框上的时间。

如何生成线框

UXDD 和线框基础背后的理念是不应该创建软件来为业务域建模。不如说，应该编写软件来映射业务域。这种视角转换在我们用于设计系统的模式中具有相关衍生品。尤其是它对初步分析给予了一种强烈地面向任务的关注度并且模糊了建模的相关性。这一点吓坏了大多数的经理，因为它听起来是一件很奇怪的事情，数十年来还没人这么做。与客户进行访谈的预期结果长期以来都是带来可以创建全方位数据模型的信息，以读取和更新系统状态。随着域和应用程序的复杂度不断增大，这种方法变得越来越低效并且管理起来越来越困难。

经典的单人和群组访谈仍然是可接受的，但是更可取的情况是旨在了解系统中要处理的相关事件以及造成这些事件的任务和环境。事件风暴是一种新兴的方法，它可以快速高效地捕捉线框和布置表示层。您可以在 bit.ly/1N25MJl 上找到关于事件风暴实践的简介，该简介由我编写并且归我所有。简而言之，这种方法能够以快速和切中要害的方式来探索复杂的业务域。它带有强烈地面向任务的特点，可以让您了解域，特别是要实施的任务。更好的是，它可以让您倾听用户们真正需要做的事情、实际操作流、触发器以及您需要通过软件映射和反射的事件。

如何验证线框

这一点很关键：如果客户没有对线框创建进行明确签字和接收，将丢失所有的工作量，因为它无法保证最终的 UX 是理想的。在 UXDD 中，在您开始编写大量代码前，您的线框必须获得批准。

但是让客户查看线框仅仅是第一步。有效的线框验证通常需要更多的工作量。您必须向用户展示这些线框在执行任务时的含义、生成的步骤顺序和完成特定任务的屏幕。情节提要这个术语指的是用于组成业务任务的多个线框串联。如果线框的内容足够准确，播放情节提要很接近于测试软件制作的原型，只不过情节提要的成本是软件原型成本的一部分并且几乎可以在瞬间修复。在更高级的方案中，合理的做法可能是电影用户在播放情节提要时使用电影。他们的身体语言以及每次操作花费的平均时间可以揭示很多事情。正确的验证过程还可能包含认知分析元素（如测试-运行-测试-退出 (TOTE)）。如图 1 所示，TOTE 实质上是一种旨在逐步改善用户满意度和实现共同目标的迭代式试错会话。

图 1 适用于 UX 分析的认知分析 TOTE 流程图

TOTE 没有任何奇妙之处，它只是平淡无奇的常识。但是尽管它听起来像过去的东西，它可以进行有效的工作。您应用的认知分析越多，您在前期花的时间就越多，那么您在后期节省的时间就越多。对于那些这么做的人来说，最后的结果是十分可观的。总之，这总好过您基于假设的模型开始编码，然后断定您已经交付了错误的项目。

典型故事

下面的故事是真实的。经过一连串无穷无尽的会议后，该团队和客户都确信他们已经正确地探讨和分析了要建设的网站的所有方面。据说系统的每一个方面都已经阐明并且无法更改；没有遇到不好的惊喜。然而，蜜月只持续了几天，一名致力于登录页面的开发者提出了第一个异常。是不是只有通过成员资格才能登录？将来没有社交身份验证吗？答案当然是“没有，客户没有提到这些”。他们在没有 Facebook 和 Twitter 身份验证的情况下就交付了该登录。猜到了吗？社交登录对于该客户而言是一种严格要求；它是如此的严格和明显以至于该客户甚至没提到这点。社交登录是额外工作，事先知道这一点很可能会有区别地调整成员资格系统的实施。与此同时，该团队中的每个人都很清楚如果有人向用户展示一张登录页面的草图，用户们会注意到缺少社交按钮并报告这个问题，如图 2 所示。

图 2 无人创建的社交登录线框

从线框到原型

您对在获取过程中使用认知分析这个理念越感兴趣，您就越想找到可以帮助创建线框和情节提要的特定工具。创建线框相对简单和快速，但是创建情节提要则复杂得多。应注意的是，一些线框的简单串联对于特定用户和特定业务方案来说可能远远不够。有时必须写入一些代码以证明概念。此处应用的术语有助于阐明这个问题。概念证明通常是用于验证假设的小型练习或者是在给定上下文中使用一种全新技术。我喜欢将概念证明称为特定于域的“hello world”。相反，原型是一种尝试模拟完整系统的虚设系统，目的是为了测试系统的可行性，甚至是实用性。当情节提要被证明不足以满足您的需要时，您需要的就是这个。最后，另一个经常互换使用的术语是“试点”，尽管它有自己的严格定义。试点是一个只针对常规目标受众的子集或数据集进行测试的完整生产系统。

总结

为提高效率，线框应该成为利益干系人之间交换的货币，只是与域驱动的设计通用语言处于一个不同的抽象级别。通用语言和线框都旨在简化对话和减少发生误解、数据误传和由于缺乏信息和指导造成的错误假设的风险。

通用语言和线框不是那种可以神奇地将灵感转换为运行代码的方法。它们的作用小得多，两者的要点是找到一系列可减少软件编写成本的具体步骤，使其接近预期的预算和最后期限。

我将在下个月进一步阐述这个问题并且探讨使用线框的（深度）体系结构含义。

Dino Esposito是《Microsoft .NET: Architecting Applications for the Enterprise》（Microsoft Press，2014 年）和《Programming ASP.NET MVC 5》（Microsoft Press，2014 年）的合著者。作为 JetBrains 内的 Microsoft .NET Framework 和 Android 平台技术传播者，Esposito 经常在全球行业活动中发表演讲，并在 software2cents.wordpress.com 和 Twitter @despos 上分享自己对软件的看法。

衷心感谢以下技术专家对本文的审阅： Jon Arne Saeteras