情境化设计：超越预定义流程

设计界面何时应适应的规则，以及用户如何保持控制权。

许多数字产品仍然留给用户一个重要任务：当变化发生时，他们需要去哪里。

我们采访一小群用户和相关领域的专家，识别反复出现的模式，并利用这些模式为更大群体设计体验。这对反复出现的行为效果很好。但这些模式并不总是告诉我们当下、对这个人、此刻最重要的事情。

传统用户体验已经有工具来展示重要内容：通知、提醒、横幅、徽章、个性化。这些工具通常会为现有层级体系增加信号。它们可以改变吸引关注的内容，但团队仍需要规则来应对何时做出合理改变。

“自适应用户界面”和“生成式用户界面”引发了关于机制的问题：系统如何决定改变什么。这篇文章讲的是关于这个上游的一些问题：一个团队如何决定何时可以改变任何东西，以及错误时会发生什么。

考虑使用保险应用。在正常情况下，客户会看到：

保障 ·付款 ·文件 ·理赔

现在想象一下，如果同一个客户刚刚报告了一起事故。应用可以直接说：

现在该怎么办 ·开始理赔 ·道路救援

保障和付款并没有消失。它们变得不那么重要，是因为它们现在不那么重要。用户没有输入不同的产品。现有的理赔和援助流程可以保持完整。

改变的是优先级。

情境设计，定义

情境设计利用系统已知的信息以及当前发生的情况，来决定界面应强调哪些内容。系统不再给每个人设置相同的层级并让他们自己解决，而是将最相关的信息传递到前，并保持通往其他所有可用的熟悉路径。

对于现有用户来说，这可能意味着角色、账户状态、最近的活动、行为历史。对于新用户来说，主要是显式输入和合理的默认值。过去的行为提供上下文。

当前情况决定优先级。目标是改变值得关注的部分，其余的保持原样。

优先级问题

随着企业产品的增长，它们不断积累功能。新的工作流程、角色、异常、报告、警报、设置、集成，全部汇聚在同一产品中。

结果可能是一个界面，既让所有内容都可用，同时让用户不知道该先看什么

巨型仪表盘谬误

当产品无法确定明确优先级时，它们往往会通过展示更多：更多导航、更多卡片、更多提醒、更多选项。结果就是熟悉的超级仪表盘：用户可能需要的一切，而用户仍负责寻找。

在任何人行动之前，他们必须先完成另一项工作。他们必须将现实世界的情境转化为系统的内部结构。我该去哪里？哪个选项适用于我？

我先做什么？功能已经存在。解释仍然是他们的。

我称之为解释成本将现实世界情境转化为产品内部结构所需的努力。

一个组织良好的界面可以减少导航上的摩擦，同时完全让用户自行判断。流程可以引导某人完成任务。仅仅绘制流程并不能告诉你任务何时值得关注。

情境设计将部分转换工作从用户转移到系统，利用已知条件和业务规则在用户之前设定优先级。

情境不是优先

我们称智能产品为“情境感知”，但仅凭情境并不能告诉系统什么重要。系统可以知道你的位置、时间、设备、交易历史，但仍然没有依据决定优先级。

数据不是解读。

再举保险为例。系统可能有二十分钟前的事故报告、客户同意分享的最新位置更新，以及他们刚刚打开应用的记录。报告是明确的。他们是否还需要道路救援只是推断。

设计问题在于这些信号意味着什么，以及系统是否有足够的信心去采取行动。

真实产品已经通过信号来改变体验的反应方式。Revolut描述减少疑似诈骗付款并引入核查流程，报告导致的欺诈损失减少了30%。柠檬水描述支票账户提交了理赔，约40%的理赔即时支付，最快的结算只需三秒。

这些都是操作决策。以我们的保险为例，道路救援是界面决策。派遣拖车则是操作决策。提出诉讼并代表他人采取行动需要不同的权限。

公司的例子展示了这种更广泛的区别。它们并不能验证这里提出的界面方法。

技术响应变化环境的更广泛理念并不新鲜。2014年，Mads Buch 舞台采用了“情境设计”用以描述根据用户情况优先排序内容。Microsoft2019年人机交互指南关注上下文相关性、不确定性、纠正和谨慎适应。

本文重点关注决策规则：哪些证据支持改变界面优先级，哪些可能改变，以及何时改变应停止。

AI为团队提供了更多方式来共同解读信号，包括用普通语言表达的不完整信息。这可以扩展产品试图识别的情境范围。仅凭这种能力并不能判断解读是否正确。

报告的事故可能只需明确的业务规则。推断出的帮助需求则需要更多的判断。

但更大的能力并不能解决设计问题。它反而让问题更加紧迫。系统推断得越多，定义它能用这些推断做什么就越重要。

情境设计将这些关注点围绕一个具体决策汇聚：何时某一情境需要改变界面优先级。这意味着要设计变更的规则和界限：系统知道什么、推断什么、信心度、允许改变什么，以及用户如何保持控制。

当系统出错时

情境设计的真正考验在于当系统处理情况时会发生什么。

系统可能误读信号、基于不完整信息、应用错误规则，或过度重视某人历史中的某个模式。当你没有发生事故时，打开保险申请寻求事故支持，充其量感觉无关紧要。

最糟糕的情况是，这感觉很侵入性。

当系统推断出敏感情况时：健康问题、财务压力、个人危机，风险会大幅提升。能够检测出模式并不意味着产品有权揭示或采取行动。

有三个原则支撑着这一点。

可见。用户可以理解发生了什么变化，并在关键时刻解释原因。系统不需要解释全部原因，但有意义的变化不应让任何人感到疑惑。

比例。干预的强度应反映证据、错误行动的代价以及无所作为的代价。弱信号可能成为质疑或不改变的理由。更强的证据可能支持采取行动。

自动采取行动需要自身的政策和保障措施。仅有信心并不等同于许可。

可逆的。用户可以关闭推断的优先级，纠正情况，并无争斗地回到熟悉的结构。拒绝帮助建议应恢复通常的优先级。不应默默取消客户已请求的服务。

逆转界面变更和撤销操作操作需要分开控制。

如何为情境设计

你不需要重建整个产品。可以从一个用户反复无法判断哪些内容值得关注的情况开始。

返回保险客户。他们报告了一起事故，但系统还不知道是否需要道路救援。接下来是拟议设计，不是已部署产品的报告或已完成的用户研究。

1. 定义情况和证据。事故报告告诉系统发生了什么。单凭报告，它并不能说明客户接下来需要什么。明确的求助请求比单纯重新打开应用更有力。

判断哪些信号足够强烈以支持问题，哪些值得完全更改优先级，哪些则不应有任何影响。

2. 确定哪些成为主要的，哪些是禁止的。报告后，应用可以提前提交协助和理赔处理。如果客户说需要道路救援，援助将成为首要服务。

但这仍然不授权应用单独订购服务。客户需单独确认该操作。

3. 决定什么能保持稳定。导航、保障、付款、文件、常规目的地，这些都不需要移动。即使系统认为帮助更重要，打开应用找保单文件的人仍然应该能做到。

4. 做出最小的有用改变，并给它一个终点。展示相关操作并简短说明：“您报告了事故。您需要道路救援吗？”提供“查看援助选项”和“我不需要帮助”。

第二个回复可以消除该建议。如果已经请求过帮助，请显示其状态，而不是重复请求，解决后停止优先处理。

同样的情况会根据系统实际需要的因素产生不同的反应：

将这些内容写成情境规范，团队可以在流程中进行审查，这很有帮助。

上述到期规则是一个起始假设，而非确定答案。
它在错失后续需求的风险与反复打断别人之间的成本之间做出权衡，而帮助无论如何都会持续可用。把规格写下来，才能让这种权衡在变成产品行为之前显现出来。

测试优先级和错误

比较两个内容和可用动作相同的原型：一个具有常规的层级结构，一个具有情境优先级。给参与者相同的情境和目标，但不指定他们应该选择的按钮。

测试有用的情况和错误的案例。先从需要路边救援的人开始，观察他们是否更早找到合适的行动。然后尝试那些已经在别处安排帮助的人，观察他们是否能否决建议，同时还能找到政策文件。

回访时，观察旧情况是否会在不该发生时反复占据主导。改变参与者先看到的版本，记录时间、错误转弯、恢复情况以及他们认为系统已经做过的事情。

仅仅一个更快的协助任务不足以称之为成功。如果无关任务变得更难，或者人们误解了系统所做的事情，规则就需要改进。这些是拟议的检查，而非衡量的结果。

定义什么是保持稳定

在这些情况下，球队需要一个一致的界限，明确允许变化的范围。

保持核心稳定，限制允许适应的部分。

稳定核心是用户应能依赖的：导航、身份、关键控制、底层信息架构。自适应表面是经过批准的一组响应情况的事物：优先级动作、建议、警告、支持路径、临时捷径。

可以把它看作一箱已经设计、测试和批准的零件。智慧在于选择哪些现有部分、何时以及持续多久。

这为生成式用户界面设定了边界。它不能按自己的条件重新设计体验。它在一个定义的组件和规则系统内运作：在稳定的边界内进行受控适应。

作为设计单元的情境

流程是用户体验设计中熟悉的单元。我们绘制旅程图，连接屏幕，消除步骤间的摩擦。这些工作依然重要。

情境同样值得明确关注。情境会传递信号、不确定性、紧迫感，以及系统错误时的后果。这使设计者的工作范围从屏幕和流程扩展到决定哪些情境重要，哪些信号代表它们，如何被自信地解读，系统允许改变什么，以及当系统改变错误时如何恢复。

情境设计意味着制定何时转变合理化的规则。当这些规则缺失时，界面就会持续移动。

流程告诉你用户可以去哪里。情境告诉你他们到达后什么值得关注。

情境设计：超越预定义的流程。最初发表于训练营在Medium上，人们通过突出和回应这个故事，继续讨论。