背景

产业赋能如火如荼,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 的建模语言是有效的辅助工具,两者的配合使这一切成为可能。

学会用例驱动设计,让你的设计更严谨!

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

学会用例驱动设计,让你的设计更严谨!

点赞 13
收藏 24

复制本文链接 文章为作者独立观点不代表优设网立场,未经允许不得转载。