# 最前沿的技术 - 利用用户体验驱动设计改善体系结构 作者 [Dino Esposito](https://msdn.microsoft.com/zh-cn/magazine/mt149362?author=Dino+Esposito) | 2015 年 11 月  任何软件系统的设计和工程都始于众所周知的一步，即收集客户需求。这通常需要与客户和域专家进行多次会议和面谈。在最后一次会议结束后，参与项目的几乎所有人都应该认为系统的全部详细信息均已落实，可以安全地启动项目开发了。任何人都不应当怀疑最终产品会与所解释和理解的有差异。客户应该感到满意，架构师应该认为自己完全知晓该怎么做。 不过，实践经验表明，在抽象的需求方面达成共识并不能保证成功实现。当客户真正看到原型时，他们并不喜欢，这种情况屡见不鲜。无论开展多少次会议和讨论，客户和开发者对最终产品的想法似乎都不同。开发者在收到需求后构建满足这些需求的软件。不过，最终产品经常会不符合用户的需求。 我认为，开发者往往会力求实现功能完整性，而不够关注让系统出色执行最终用户所需的业务流程。所以，虽然业务流程的功能方面有所覆盖，但总体实现很少与预期的一样完善和顺畅。在本文中，我将介绍一种设计方法，这种方法可以增加架构师首次就能构建正确的软件的可能性。我将这种方法称为用户体验驱动设计（或简称为 UXDD）。 ## 灵感来源 您可能还记得这样一段逸闻：苹果砸在 Isaac Newton 爵士的头上，让他想到了万有引力定律。最近，我的头也被苹果砸了一下，生出了以下想法：要充分注意用户的预期和实际流程，有时需要构建不同的内容。也就是说，要做的不仅仅是功能分析而已。 客户曾要求构建一个简便快捷（他们是这么说的）的 Web 应用程序，以支持网球公开赛的竞争对阵图。这只是一个用户情景。操作员指出了选手姓名和相关抽签排位，并希望系统能够公开部分 XML 源来反映当前抽签状态。我的开发者根据自己的思维模式立即想到了创建数据表来保存数据。接下来，我想到了创建包含两个文本框的某种快捷 HTML 窗体：一个文本框用来显示选手姓名，另一个用来显示选手的抽签排位。有趣的是，当讨论结束时，客户确信有工具可以输入选手姓名和排位了，并且还有提供支持的部分 XML。但当开发者（就是我）交付了这样的工具后，客户通过实际抽签模拟进行了测试，却发现这行不通。客户想要的工具实际上更复杂。请参见图 1，它展示了开发者和客户的不同视角。背景屏幕是客户需要的解决方案，展示了实际流程；叠加层内有黑色边框的黄色屏幕是低成本的解决方案，虽然快捷但并不适合。   图 1：客户预期和开发者理解之间的差异 总而言之，用户体验不仅仅涉及手势和图形，还涉及用户在与软件交互时获得的体验。为了设计有效的用户体验，作为架构师和开发者，您应该更加关注任务和业务流程，而不是数据模型和存储空间。您必须详细了解域、用户和用户在相应的域中执行哪些操作，才能理解任务。UXDD 能够解决此难题，但它不只是通常推荐使用线框和模型而已。我在一个简单方案中使用过这种方法，但并不行得通，因为客户（在他看来）认为软件过于简单，与完整设计实际流程的工作并不相当。作为架构师，我没有从客户那里获得有关任务重要性的正确信息。绝不要选择低成本的解决方案；请选择有效的解决方案。我不得不承认，我建议的原始解决方案（低成本的解决方案）在实际情况下根本无法使用。我所犯的错误是，盲目地完全相信客户的分析，而并没有详细了解实际的业务流程。 UXDD 是一组结构方案，能最大限度地降低遗漏与任务和 UI 相关的重要业务点的风险。有趣的是，UXDD 能够改变目前部分的开发和软件工程综合实践。 ## 自上而下的设计 从功能角度来看，无论您是从底部（即从暂留模型）还是从顶部（即从表示层和视图模型）开始设计，您都能成功地构建有效系统。从用户体验的角度来看，只有当您从表示层和视图模型开始设计，并由此构建其他所有内容（包括后端堆叠）时，您才能够成功。 我们中很多人学习过的专业知识都是，在根据客户需求构建由实体和关系组成的暂留模型后，您差不多就快完成了。此模型将是整个系统的模型，用于整个堆叠，只会偶尔与一些 UI 特定的数据传输对象合作。在这种情况下，系统的设计和构建都是按照自下而上的方式进行，而且表示层也必然会反映数据模型以暂留为中心的理念。我们通常将此称为创建、读取、更新和删除 (CRUD)，并且我们也经常会将任意系统简化为 CRUD，只含略复杂的业务逻辑。这样一来，我们就不太注意表示层。UI 太靠近数据模型有时对用户来说很好；有时却不是。在您交付首个有效原型后，后一个方案会促使开展更多协商。您在首次从头开始设计系统后发现，在某些情况下，必须更改最外层才能反映不同的用户流程。这无异于尝试将方形钉子钉入圆孔内。因此，我将这认为是许多软件项目的最大挑战。 我们可以如何改善流程呢？ 我认为答案是，回到自上而下的设计方法，从表示层开始设计，并根据表示需求制定任何进一步的决策和实现详细信息。为了使其有效，必须有一种冲刺 (sprint) 0 或瀑布式初步步骤，才能确保在构建系统后端之前，对用户体验有深入的了解。 ## 用户体验驱动方法 我从用户体验专家那里了解到，与通过面谈被动推导相比，最好是通过循证讨论来主动捕获需求。有时，架构师和分析员往往会在推导过程中过于被动，这就导致用户降低任意功能的优先级，以使软件尽快交付。然后，用户会在最终获得软件时抱怨系统几乎无法使用。同时，在推导过程中过于被动，以“这就是客户所需”为借口，对我们将要构建的“产品”没有任何帮助作用。如今，我们编写软件是为了反映实际应用，而不是为了针对所了解到的客户需求建模。遗漏业务结构方面是代价巨大的致命过失。 常见做法是，使用线框就预期 UI 达成共识。由用户反复运行线框以征集反馈意见只在一定程度上有用。线框虽然很不错，但若没有情节提要，就价值有限了。 只有很少的任务是完全通过一个您可以有效汇总到线框中的屏幕完成的。只观察屏幕的线框可能还不足以发现流程实现的可能瓶颈。最好是在情节提要中连接屏幕。在这一方面，我认为最大的挑战是寻找情节提要的构建工具。此类工具构成了快速发展的应用商店。图 2 列出了一些能够帮助您快速制作应用程序表示层的原型的工具，让用户可以具体地了解正在设计的流程。 图 2：可快速有效地制作 UI 原型的工具 | 工具 | URL | |---|---| | Axure | [axure.com](http://axure.com/) | | Balsamiq | [balsamiq.com](http://balsamiq.com/) | | Indigo Studio | [infragistics.com/products/indigo-studio](http://infragistics.com/products/indigo-studio) | | JustInMind | [justinmind.com](http://justinmind.com/) | | UXPin | [uxpin.com](http://uxpin.com/) | 另外，最新版 Microsoft Visio 和 PowerPoint（尤其是与 Visual Studio Ultimate 结合使用时）也具备一些原型制作功能。图 2 中列出的所有工具都提供了丰富的平台，可便于您创建线框，以及在某些情况下创建可单击的模型，并将其转化为功能性原型。 这些工具中最先进的可以提供早期反馈，更重要的是，您能够在设计过程的早期以及在编写任何一行代码之前就让客户参与进来。如果您在后端完成一半时发现遗漏了重要的表示点，要么放弃，要么进行调整。 同时，简单地将表示层外包给用户体验专家团队还不够。如今，表示层是系统最重要的一个部分，必须由解决方案架构师、用户体验架构师和客户共同生成。这必须是第一步，理想情况下，只有当客户赞同表示层时，您才能继续。在方法方面，可以接受的做法是，执行瀑布式倾斜，并在编码前完成整个表示设计，同时提高敏捷性，并将表示分析添加为冲刺 (sprint) 中的一个步骤，如图 3 所示。   图 3：用户体验驱动结构设计的三个步骤 ## 设计解决方案的其余部分 当您完成整个解决方案的表示层或仅当前冲刺 (sprint) 后，您便有一系列屏幕（例如，窗体）和定义明确的数据流（明确了流入和流出每个窗体的数据）。从体系结构上来说，这就意味着您了解每次操作的输入模型，以及填充窗体或生成预期响应所必需的视图模型。表示层通过从概念上匹配服务层模式（如 Martin Fowler ([bit.ly/1JnFk8i](http://bit.ly/1JnFk8i)) 所定义）的中间服务层，以及域驱动设计的分层体系结构中的应用程序层与后端相连。您实现用例及其所需任务的任何业务流程的位置正是系统的逻辑段。应用程序层是后端的顶层部分，并与表示层直接对话。应用程序层由每个操作的直接终结点构成，这些操作可由表示层触发。这些终结点接收并仅返回线框生成的输入模型和视图模型。 这种方法真的有效吗？ 那当然。如果线框分析不仅彻底还正确无误，则您实现的流程就是客户想要的，并且第一次就是对的。这样大大减少了在部署第一个版本或演示后重新协商更改的可能性。不仅节省了时间，而且随后还能缩减开支。如图 4 所示，开发者将这指明为用户对软件的典型看法。使用 UXDD，就可以这样设计软件。   图 4：用户视角的软件本质 ## 总结 与我们当前采用的软件设计方法（从数据模型往上）相比，UXDD 更加重视的是任务和表示，而不是数据模型。数据模型和暂留并不是不重要，只是它们的角色对任务具有功能性，而不是任务对它们的角色具有功能性。无论您是否乐意，这都更接近于当前的实际应用需求。UXDD 关乎于方法，而不是技术或模式。UXDD 既不拒绝也不授权任何技术或模式，尽管它可以与 CQRS 和 Event Sourcing 完美结合使用。如果您不满意应用程序的实际构建流程，请将 UXDD 方法看做一种横向思维方式。 * * * 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](http://software2cents.wordpress.com/) 和 Twitter [@despos](https://twitter.com/@despos) 上分享自己对软件的看法。*