学会用例驱动设计，让你的设计更严谨！

背景

产业赋能如火如荼，B 端产品因其复杂的业务逻辑令人生畏，再加诸多角色的分层、平台化技术架构，俨然在构造一个复杂的系统。单纯基于角色现状的行为洞察、业务流程的梳理，仍不易完整把控其产品设计。从业务方传递到设计方的信息存在断层，含杂其中的体验设计则显得扑朔迷离，设计师较难“从外向内”摸到产品的核心逻辑，遑论其业务逻辑。面对既定的、不完美的“产品结构”爱莫能助，只能试图在框架层或表现层做缓解，长期下来，将失去对设计逻辑的控制。

复杂的 AutoCAD 与 Inventor 工具

我们需要一种能应对该局面的设计思路，有效的连接业务逻辑、产品逻辑，层层渗入对体验的考量，最终构造出既契合 B 端业务，又具有良好体验的产品服务，设计在此过程中有条不紊的推进和管理。

用例（Use Case）的概念早在 1986 年就已被提出，它是需求分析的好帮手，可有效的划定范围、锚定用户、区分关系、定义价值，通过不同颗粒度的抽象层次，不断瓦解复杂系统，使设计和管理有序化。本文基于早已发展成熟的用例驱动设计理念，试图从中找到一条适合体验设计师介入的小径，来应对复杂业务的产品设计。(备注：用例、参与者、UML 等详细的内容不在阐述范围内，本文仅探索一条可行的方式。)

什么是用例

定义：参与者与系统交互的一系列活动的集合。

可以发现，一个用例以一组活动集合来表现，集合中包含两个角色，参与者、系统。参与者是“活的”（不一定是人类），TA 的诉求驱动了这一系列活动，此诉求即用例的核心，也是价值的体现。一个参与者可以对系统有多个诉求，详见如下案例：

由用例驱动的体验设计过程，着重关注对“行为”的设计。与系统的互动“行为”被协调的、有组织的设计后，为界面表现设计建立坚实基础，避免因逻辑的变更使界面设计反复推倒重来。试图通过在界面设计的过程中寻找线索和灵感，反向的去设计背后逻辑是本末倒置的，个中原由在于我们更易于把控具象的视觉感知，较难把控抽象的行为。

系统用例和业务用例的关系

在划分用例前，有必要澄清系统用例和业务用例的关系。

业务用例是从客户当前的业务逻辑中抽象出的用例，与数字产品无关，即便没有该产品服务，客户的业务体系也可以流转。新的产品服务实际上是对传统业务体系的替换关系，而系统用例就是从该产品服务中抽象出来的，图示业务侧和产品侧的对接关系：

1. 用例驱动设计的案例

总述:

为清晰阐释我们是如何利用“用例“这个概念作为切入口，最终一步步驱动、解构、细化体验设计的，下面将完整展示一个注册登陆试用产品的案例进行讲解，本案例为虚拟案例，方便设计过程的串连。

step 1: 整理故事与确定用例

故事中包含了用户的行为及其所处情境，将更易于被理解、共情和传递，故事情节的内在联系，上下游的完整性也直指价值的辐射范畴。在开始设计前，我们能从各个渠道收集到相关、相似的诉求，整合这些信息后以“故事”的方式表达出来，非常重要。

本案例的注册登陆试用故事从”企业“、”用户“两个维度进行描述，能确保在用户诉求达成的情况下，也能达成商业诉求，和谐统一的以产品服务提供出去。

企业故事：

公司统一了 Platform 账号体系，在保证多设备产品端的一键畅通体验的同时，收集用户行为信息，以提供更精准的售后服务。同时与授权中心合作，通过网上商城定期开展活动，以下放试用天数，获得试用授权。产品经理与销售部门达成持续的合作，通过试用用户的手机号进行电话回访，提高购买转化率。同时软件的设计应能最大限度的提升客户自发购买行为，需要在合适的时机，合适的位置提供购买入口。

获取用例的方式：

sys_运营人员→获取用户信息

sys_运营人员→开展活动

用户故事：

新家装项目开展在即，大量的图纸设计使张经理感到困难。在受到同行推荐的 Platform 出图软件后，回到办公室，通过 Platform 官网找到软件信息，并利用现场 wifi 网络下载安装；迫不及待的启动软件，虽没有购买，但软件提供了试用入口，张经理提交 Platform 账号后开始试用软件。连续使用了两天，后面每次自动登录提高了试用的体验过程，产品一键自动化生成图纸初步解决了张经理的烦恼。经过和集团沟通后，张经理在界面上找到购买入口，并购买软件正版。他将软件推荐给朋友刘经理，他是 Platform 造价产品的老用户，且已购买过 Platform 加密锁，启动软件后，界面自动显示为正式版， 不用登录试用让张经理艳羡不已。

获取用例的方式：sys_采购经理→试用软件

step 2: 快速描摹流程图

用户和企业的“故事”是一种情节式的、场景式的描述，它易于想象、理解和整合。但为了更清晰的辅助设计，我们需要根据描述，进一步梳理出流程关系，将其具象化。在绘制流程图时，可不用关注角色的职责关系，旨在快速描摹出所涉及到几个业务点的关系，将企业和客户的诉求点包含进去，并在反复确认过程中思考、推敲，大体设计出其中的基本结构。过程中，可能需要补足新的故事描绘，或对既有的故事描述进行修正，以达成一个诉求与技术实现的平衡点。

step3: 泳道角色化

理清核心业务流程关系后，将进一步绘制其角色泳道图，每个泳道下对应参与的角色。泳道图仍然是分析过程的一步，它在这里的意义是可清晰的观察到各个模块间的协作互动，是细化过程，各个“对象”的职责不同，他们之间的交互关系存在进一步优化的可能，以保证整体行为的和谐，减低系统冗余。

step4: 业务实体的获取

事实上，带有角色的泳道图仅是在很粗的层面描述了业务所参与的对象，是单纯从流程图层面归纳出来的“对象角色”。在面对详细的功能分析时略显不足，可能缺失实际参与的“对象角色”，如不分析出来，将导致用户与系统的交互”行为“的缺失。我们需要进一步挖掘其中涉及的各个参与“角色”，完整的描绘出其交互行为过程，才能对该封闭系统做完整的设计。

从哪里可以获取到全部业务实体呢？当然还是故事。业务实体天然的包含在用户或企业故事中，才得以支撑故事的完整发生，这与故事描述的程度有关，我们第一步就需要填充完整的故事。

备注：什么是业务实体——用于达成业务目标的实体与过程中的记录信息。诸如“点餐”用例中的“打印单”就是一个实体，打印单上的手机号是记录信息。外卖员之所以能将外卖送到你的手上是通过打印单，查看上面的手机号和地址才能找到你。

下面是结合「故事」，进一步获取业务实体的案例，把所涉的可见的业务实体标识出来。

企业故事:

公司统一了 Platform 账号体系，在保证多设备产品端的一键畅通体验的同时，收集用户行为信息，以提供更精准的售后服务。同时与授权中心合作，通过网上商城定期开展活动，以下放试用天数，获得试用授权。产品经理与销售部门达成持续的合作，通过试用用户的手机号进行电话回访，提高购买转化率。同时软件的设计应能最大限度的提升客户自发购买行为，需要在何时的时机，合适的位置提供购买入口。

用户故事:

新家装项目开展在即，大量的图纸设计使张经理感到困难。在受到同行推荐的 Platform 出图软件后，回到办公室，通过 Platform 官网找到软件信息，并利用现场 wifi 网络下载安装；迫不及待的启动软件，虽没有购买，但软件提供了试用入口，张经理提交 Platform 账号后开始试用软件。连续使用了两天，后面每次自动登录提高了试用的体验过程，产品一键自动化生成图纸初步解决了张经理的烦恼。经过和集团沟通后，张经理在界面上找到购买入口，并购买软件正版。他将软件推荐给朋友刘经理，他是 Platform 产品的老用户，且已购买过 Platform 加密锁，启动软件后，界面自动显示为正式版， 不用登录试用让张经理艳羡不已。

step5: 时序图的绘制

接下来，我们将进行最重要的一步：基于已明确的核心业务流程和已拆分出的业务实体，构造出一整套完整的系统行为。将使用到 UML 语言的重要工具——时序图。时序图能天然的表达多个对象间的复杂行为关系，在产品研发领域应用广泛。（时序图的绘制有一整套完整的语法，本文不讲解该部分内容）时序图的“对象对话”形式，原生的契合了“交互”这一概念，游戏大师Chris Crawford和设计专家Jon Kolko都对此有所定义：

“发生在两个或多个活跃主体之间的循环过程，各方在此过程中交替地倾听、思考和发言，形成某种形式的对话（conversation）”
——《Chris Crawford on Interactive Storytelling, 2nd Edition》

“所谓交互设计，是指在人与产品、服务或系统之间创建一系列对话（dialogue）”
——《houghts on Interaction Design, Second Edition》

时序图重点强调了“行为”的发生与互动，使整体目标达成。一系列有边界的行为活动合集，就组成一个完成的、有意义的“用例”。让我们再次回到开头的“用例”上来，并将该用例系统化。

用例：

sys_运营人员→获取用户信息

sys_客户人员→试用软件

sys_客户人员→授权软件

除确保能服务于运营人员、客户外的核心逻辑能达成外，为带来更好的使用体验。我们需要从诸多体验维度考虑各个系统行为。“体验因子”将作为系统行为的一部分目标，使整个交互活动更易于理解和顺畅。可直接借鉴一些通用的体验因子来评估，对于不同形态、业务的产品，体验因子有所偏重，诸如工具类产品对“操作便捷度”、“工具易学性”、“工具帮助引导”有较高要求。

回到注册案例上来，考虑到“易学性”和“帮助引导”两个体验因子，可以对用户“输入手机账号”的行为进行优化设计，提前或实时对手机账号进行校验，避免出错后再提示，徒增挫败感。同时提供“获取验证码”的触发入口，引导用户执行该操作，很大程度上降低系统的理解负担。在行为设计过程中，存在颗粒度问题，复杂系统涉及到大量互动会话行为，可以有粗细的逐步细化。

step6: 触点行为的竞品调研

完成系统互动行为的设计后，可以开始正式的界面信息设计。“行为”的表达是极度精炼的，行为本身就是价值取向，并暗合用户的内心想法，由用例行为来驱动界面设计，才能真正做到按需设计。诸如“我感到肚子饿，第一想法是吃饭”、“早上该上班了，第一想法是走路去、打车去或坐地铁”。

在面对“输入手机号码”行为的界面设计时，除了个人创新外，也可调研市面上有哪些优秀的界面承载方式，作为一种“学习输入”，或者激发出新的创新行为。这种由内而外的驱动设计，能使设计过程变得更有序，且避免遗漏。

step7: 触点支线、异常、极限情况的排查

最后一步是对支线、异常、极限情况的排查，得益于时序图系统行为的可视化表达，我们可以清晰、有序的排查每一个对话过程中可能出现的异常或错误，诸如“验证码无法到达”、“信息返回错误”等异常，都将被有效地排查出来。同时，还能从行为对话结构中，洞察到新的设计优化机会点，诸如“提交账号信息”环节，必然需要网络的通畅，故断网环境下需要给出明确的反馈。如下示例：信息返回错误、异常流程高发地、页面跳转……

时序图会话的先后顺序也将直接影响到界面的表达，图示中“输入手机账号”与“填写验证码”是有先后时间顺序的，如果同时在界面中展示两个输入信息，无疑造成并列的误解。（可惜市面上几乎大多数注册环节都如此，大家早已习惯）

找到体验的最大撬动点

总结

所谓用例驱动体验设计，是借用例的概念来定义问题和范围，并使用 UML 来分析问题，使整个设计过程变得有序、系统、严谨，在应对复杂系统、多链路多角色的业务时较为有效。用例在整个设计过程中是核心的存在，一旦模糊就会出现偏差，引入无关内容，同时也会失去对用户价值的把控。用例的获取很不容易，而精准统一的用例更难，涉及到颗粒度、抽象层次、参与者、受众等等内容，本文未对“用例的获取”做详细阐述，仅专注在用例如何驱动设计过程，有兴趣者可移步学习。

撬动点

以用例为中心的体验设计，从业务逻辑出发，转化为系统逻辑，在构建这个过程时就持续考虑体验因素，是把控体验的有效办法，我们站在结构上思考体验，将彻底的优化系统的体验。单纯从界面表现和框架呈现上做体验优化，上限明显，只有扎得更深，才能从结构上找到优化的“最大”杠杆点，带来体验提升，并有可能直接对研发程序设计带来指导。而 UML 的建模语言是有效的辅助工具，两者的配合使这一切成为可能。

欢迎关注公众号「酷家乐用户体验设计」