事件风暴和用户体验驱动设计

引言

用户体验驱动设计 (UXDD) 和事件风暴是两种互补的分析方法，用于设计应用程序，**从用户的角度**（或流程）出发。实际操作中，这意味着它们是在深入研究如何提供技术细节之前，用于确定用户想要什么的工具。

背景

有一句俏皮话是**“雕刻一匹马的方法是，从一块石头开始，然后切掉所有不像马的部分”。**

我们认识到这是一个愚蠢的说法，但我们却经常以同样的方式进行软件分析——要求用户（或利益相关者）对系统的构建方式做出超出他们专业知识水平的决定——最终导致业务方说**“我不确定我想要什么，但我看到它时就会知道”。**

事件风暴

实体是关于事物是什么，事件是关于事物做什么。我们似乎花费了太多的精力来建模事物是什么，而忽略了事物做什么。

事件风暴会议是少数分析师和少数业务领域专家之间的会议。良好的会议管理规定，人数必须保持较少（著名的“两人披萨原则”），如果需要比这更多的领域专家，您必须准备多次会议来获取信息。

您需要的设备是一个公共空间（白板、空白墙或大桌子）和便利贴。然后，您开始识别系统中的“事物”，并为每种事物，尽可能多地识别可以发生的事件。然后，您将这些写在便利贴上，并将它们围绕系统的“事物”进行分组。

如果一个事件涉及多个事物，您为每个受影响的事物写一张单独的便利贴——不要试图将它们连接起来，因为这会过早地进行解决方案设计（在分析领域与编码领域过早优化一样糟糕）。

重要的是，所有事物和事件都应使用业务语言书写，而不是技术术语。例如，在业务术语中，订单是“已下单”，而不是“已创建”。

示例：一头牛可能发生的事件

然后，您可以扩展事件，添加关于每个事件可以捕获的信息的说明。在此阶段，不必决定每条信息是否是强制性的，也不必认为输出是事件的“最终”数据。进一步的分析可能会发现更多可用或所需的数据。

用户体验驱动设计

下一步是采用事件风暴会议中发现的事件（和“事物”），然后问“该事件的信息如何进入系统？”。在绝大多数情况下，这可以通过两种方式之一实现——数据来自另一个系统（或传感器或其他非人类输入），或者必须由操作员输入。

对于必须由人类用户输入的事件，我们需要设计一个屏幕布局来完成此操作。通常，此布局会由某个原型设计工具（如 Balsamiq）创建，以便用户能够设想输入事件的数据。

然后，我们需要设计屏幕来呈现用户为了执行其业务职能而需要从系统中获取的任何数据。用户查看系统的角色很可能会有所不同——例如，会计人员希望看到订单和库存的价值，而仓库经理则希望看到履行订单所需的物品和地点。同样，原型设计工具也适用于此。

在此阶段，您需要从这些原型设计工具和事件描述中获得一份已签署的文件——这就是您的用户体验合同，只要按照该合同交付，您如何在幕后实现它就只属于您的（技术）范畴。

异议和障碍？

用户体验驱动设计可能面临的一个异议是它没有解决系统的架构和技术方面——但事实并非如此。它没有与非技术人员讨论这些方面。相反，您承诺交付用户所需的用户体验，然后让他们以最适合系统的方式来处理细节。

工作示例

我们所做示例的最高级别需求是：**创建一个系统，以允许管理一个跑团联盟，以改进或取代当前密集的手动系统。**

对该系统的初步考察让我们认为，根据用户（或用例）的不同，系统有三个截然不同的视图。对于联盟组织者，他们希望一个系统来跟踪团队表现、会员资格等。对于赛事组织者，他们希望能够可靠地跟踪跑者的完成时间、名次，而对于个人跑者，他们希望能够跟踪自己随着时间的推移的表现。因此，我们决定将应用程序分成三个**领域**。

领域 1：联盟

联盟领域负责注册团队和个人，安排比赛，并跟踪这些比赛的结果以创建联盟排名等。

我们安排了一次事件风暴会议，与联盟代表以及一些跑者和监督员一起进行。选择这个更大的群体是为了（a）在这个层面上不引入不利于其他用户的设计限制，以及（b）让所有人同时了解事件风暴的概念。我们希望这些利益相关者感觉是**他们**在设计应用程序，因为这将让他们对这个过程有更多的所有权。

事件风暴会议仅限于系统应捕获哪些事件以及它们如何与我们需要建模的事物相关联。我们有意识地决定推迟讨论系统将如何显示（甚至在什么设备上可用），因为根据我们的经验，如果涉及设计决策，系统分析的探索阶段可能会很快被扼杀。

在此次会议中确定的实体类型是：

• Race - 单个特定安排的赛事
• Season - 一系列明确定义的比赛，比赛结束后将确定总冠军
• Team - 一群跑者作为一个团队一起参赛
• Club - 团队或个人跑者可以所属的组织
• Runner - 在联盟注册的运动员

对于每种实体，我们都能够确定一种唯一标识它们的方法，并确定可以发生在其上的事件的初始集。在此阶段不必捕获所有事件，也不必捕获事件的所有属性，因为这些通常在分析过程中被发现。

接下来是 UXDD 步骤。对于所有来自人类的事件数据，我们需要设计输入屏幕；对于联盟希望从系统中提取的每一组信息，我们设计显示屏幕和/或报告。这些是通过铅笔画完成的，以将重点放在整体概念上，而不是颜色和字体的深入设计元素。

领域 2：比赛

比赛领域负责由联盟安排的每场比赛的组织。这意味着要记录每位跑者冲过终点线时的名次和时间，以及跟踪在任何给定时间点已完成比赛的跑者数量。

最初，我们认为与联盟领域有很大的重叠，但在事件风暴板上工作了一段时间后，很明显在此级别上重要的唯一实体类型是跑者。我们决定使用与联盟领域相同的唯一标识符（跑者编号）。

比赛领域的 UXDD 方面也很有趣——跑者希望在冲过终点线时知道自己的时间名次，但他们真的不希望为系统输入任何内容，因为他们几乎已经筋疲力尽地冲过终点线了。因此，我们仍然需要比赛监督员来处理实际的输入。

领域 3：跑者

跑者希望随着时间的推移跟踪自己的表现，并有一个社交反馈方面，以鼓励训练和参与。他们可能还希望跟踪联盟外的比赛、训练计划以及各种其他信息。

从 UXDD 的角度来看，跑者还希望能够控制与注册用户的共享内容以及哪些是私密的。与代表们交谈后，我们发现大多数人认为使用智能设备或网站是最好的——我们决定一个对移动设备友好的网站比设备特定的“应用程序”提供了更好的覆盖范围。

历史

• 2015-11-18：初稿
• 2016-03-24：添加了示例