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

2 评论 6279 浏览 5 收藏 21 分钟

编辑导语:设计师在业务流程中,若想对整体流程有所把控,推动产品方案的落地实现,则可以借用某种设计思路,达成统筹效果。用例驱动也许是一种不错的设计思路。本篇文章里,作者就对用户驱动设计的流程做了整体梳理,一起来看一下。

一、背景

产业赋能如火如荼,B端产品因其复杂的业务逻辑令人生畏,再加诸多角色的分层、平台化技术架构,俨然在构造一个复杂的系统。

单纯基于角色现状的行为洞察、业务流程的梳理,仍不易完整把控其产品设计。从业务方传递到设计方的信息存在断层,含杂其中的体验设计则显得扑朔迷离,设计师较难“从外向内”摸到产品的核心逻辑,遑论其业务逻辑。面对既定的、不完美的“产品结构”爱莫能助,只能试图在框架层或表现层做缓解,长期下来,将失去对设计逻辑的控制。

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

复杂的AutoCAD与Inventor工具

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

用例(Use Case)的概念早在1986年就已被提出,它是需求分析的好帮手,可有效地划定范围、锚定用户、区分关系、定义价值,通过不同颗粒度的抽象层次,不断瓦解复杂系统,使设计和管理有序化。

本文基于早已发展成熟的用例驱动设计理念,试图从中找到一条适合体验设计师介入的小径,来应对复杂业务的产品设计(备注:用例、参与者、UML等详细的内容不在阐述范围内,本文仅探索一条可行的方式)。

一、什么是用例

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

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

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

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

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

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

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

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

用例驱动设计的案例

总述:

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

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

step1:整理故事与确定用例

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

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

1)企业故事

公司统一了Platform账号体系,在保证多设备产品端的一键畅通体验的同时,收集用户行为信息,以提供更精准的售后服务。同时与授权中心合作,通过网上商城定期开展活动,以下放试用天数,获得试用授权。

产品经理与销售部门达成持续的合作,通过试用用户的手机号进行电话回访,提高购买转化率。同时软件的设计应能最大限度的提升客户自发购买行为,需要在何时的时机,合适的位置提供购买入口。

获取用例的方式:

  • sys_运营人员→获取用户信息;
  • sys_运营人员→开展活动。

2)用户故事

新家装项目开展在即,大量的图纸设计使张经理感到困难。

在受到同行推荐的Platform出图软件后,回到办公室,通过Platform官网找到软件信息,并利用现场wifi网络下载安装;迫不及待地启动软件,虽没有购买,但软件提供了试用入口,张经理提交Platform账号后开始试用软件。

连续使用了两天,后面每次自动登录提高了试用的体验过程,产品一键自动化生成图纸初步解决了张经理的烦恼。

经过和集团沟通后,张经理在界面上找到购买入口,并购买软件正版。

他将软件推荐给朋友刘经理,他是Platform造价产品的老用户,且已购买过Platform加密锁,启动软件后,界面自动显示为正式版, 不用登录试用让张经理艳羡不已。

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

step2:快速描摹流程图

用户和企业的“故事”是一种情节式的、场景式的描述,它易于想象、理解和整合。

但为了更清晰地辅助设计,我们需要根据描述,进一步梳理出流程关系,将其具象化。

在绘制流程图时,可不用关注角色的职责关系,旨在快速描摹出所涉及到几个业务点的关系,将企业和客户的诉求点包含进去,并在反复确认过程中思考、推敲,大体设计出其中的基本结构。

过程中,可能需要补足新的故事描绘,或对既有的故事描述进行修正,以达成一个诉求与技术实现的平衡点。

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

step3:泳道角色化

理清核心业务流程关系后,将进一步绘制其角色泳道图,每个泳道下对应参与的角色。

泳道图仍然是分析过程的一步,它在这里的意义是可清晰地观察到各个模块间的协作互动,是细化过程,各个“对象”的职责不同,他们之间的交互关系存在进一步优化的可能,以保证整体行为的和谐,减低系统冗余。

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

step4:业务实体的获取

事实上,带有角色的泳道图仅是在很粗的层面描述了业务所参与的对象,是单纯从流程图层面归纳出来的“对象角色”。

在面对详细的功能分析时略显不足,可能缺失实际参与的“对象角色”,如不分析出来,将导致用户与系统的交互“行为”的缺失。

我们需要进一步挖掘其中涉及的各个参与“角色”,完整地描绘出其交互行为过程,才能对该封闭系统做完整的设计。

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

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

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

1)企业故事

公司统一了Platform账号体系,在保证多设备产品端的一键畅通体验的同时,收集用户行为信息,以提供更精准的售后服务。同时与授权中心合作,通过网上商城定期开展活动,以下放试用天数,获得试用授权。

产品经理与销售部门达成持续的合作,通过试用用户的手机号进行电话回访,提高购买转化率。同时软件的设计应能最大限度的提升客户自发购买行为,需要在何时的时机,合适的位置提供购买入口。

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

2)用户故事

新家装项目开展在即,大量的图纸设计使张经理感到困难。在受到同行推荐的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的建模语言是有效的辅助工具,两者的配合使这一切成为可能。

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

 

作者:同舟;公众号:酷家乐用户体验设计

本文由 @酷家乐用户体验设计 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Pexels,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 步骤清晰,逻辑清楚很有帮助,只是有些理论过于深奥,还得慢慢钻研

    回复
  2. 写的专业性很强,可读性不高,太多名词深邃难以理解,文字语言也不够通俗,不太好类比和理解。总之是辛苦了,多多加油改进吧。

    回复