产品状态设计,看这一篇就够了

在产品设计中,“状态”是非常重要的设计点,它看起来很简单,似乎只要定义好几个词就够了。

但实际上有很多注意要点,稍不留神就会掉坑里的,所以很多同学在梳理的过程中会感觉越理越复杂、越理越混乱。

这一篇我们就来详细聊聊产品状态的设计。

一、基础知识

1. 状态的定义

状态是什么?

状态是对某一对象一个时间段内业务进展的概括性描述。

我们将这个定义分解一下:

  • 某一对象:状态是用来描述业务中一个具体对象的,每个对象的状态是独立的,只属于它自己;
  • 一个时间段:状态表示的是一个时间段,而不是一个时间点,它不是一个瞬时动作;
  • 业务进展:状态说明的是对象在业务中的进展;
  • 概括性描述:状态具有概括性,是对对象的精简描述。

例如下图中淘宝的商品订单状态,描述对象是商品订单,每个状态都会持续一段时间,这些状态说明的是商品订单在流转过程中的进展,每个状态的描述都非常精简,格式也很统一。

【干货】产品状态设计,看这一篇就够了

图1 商品订单状态示例

2. 状态的三要素

状态是由输入条件、状态描述、终止条件三个要素组成。

【干货】产品状态设计,看这一篇就够了

图2 状态三要素示例

1)输入条件

输入条件是进入这个状态的触发开关,当条件被满足,就会执行一次状态的迁移,即进入此状态。如上图中,“用户付款成功”后,商品就会进入【待发货】状态,“用户付款成功”就是【待发货】的输入条件。

2)状态内容

即这个状态是什么。

3)终止条件

终止条件是这个状态结束的开关,当条件满足时,此状态就会终止。如上图中的“商家发货”,就是【待发货】状态的终止条件。

上一状态的终止条件,是下一状态的输入条件,例如下图中“商家发货”是【待发货】的终止条件,是下一状态【待收货】的输入条件。

【干货】产品状态设计,看这一篇就够了

图3 终止条件与输入条件

无论是输入条件还是终止条件,都包含手动和自动两种:

  • 手动:即需要用户手动触发,如“商家发货”,就需要商家手动点击“发货”按钮,或输入发货单号并手动提交成功,系统才可判断商品终止了【待发货】状态,进入【待收货】;
  • 自动:即无需用户手动操作,系统根据已设置好的规则,当规则满足后,自动执行状态迁移。

这两种类型的条件可同时存在,也可只存在其中一种。如商品从【待收货】流转到【待评价】状态,既可手动触发,又有自动触发机制:

  • 手动:用户主动点击“确认收货”按钮;
  • 自动:从状态流转到【待收货】起开始计算,10天后,系统会自动确认收货,状态变更为【待评价】。

我们在设计状态流转时,会尽量减少需要用户手动触发的条件,改为自动触发,但很多时候系统无法做到完全自动,有些环节只能通过用户操作来完成。

然鹅,众所周知,用户都是懒的,用户都是上帝。

我们无法强迫每个用户按照我们的要求去做,只要有需要手动触发的条件,就一定会有用户不主动做,这就会导致后续流程无法继续进行,所以对于状态流转比较重要的节点,我们大多会采用手动为主,自动为辅。

的原则,即预留一定的时间等待用户手动操作,当即将到达这个时间时,给予一定的预警提示,如若用户仍不操作,则在到达时间后由系统自动向更为常见的方向执行。

3. 状态的作用

状态的作用主要有三个。

1)展示进展

向用户展示此对象的当前进展,以缓解用户的焦虑,降低内心的不确定感,从而提升用户体验。

2)便于描述

将对象不同阶段进行归纳,便于日常沟通。

3)统一规则

对于同一角色,一个对象在一个状态中的规则、操作权限是相同的,不应出现状态前半段权限是A,后半段是B的情况,这一点无论是对用户还是开发都是有意义的。

4. 状态流程

将一个对象各个状态按时间线串联起来,得到的就是这个对象的状态流程。

【干货】产品状态设计,看这一篇就够了

图4 状态流程示例

二、设计原则

1. 完整连贯

一个对象的状态是贯穿这个对象整个生命周期的,前后两个状态是紧密衔接的,中间不应出现任何真空时期。

【干货】产品状态设计,看这一篇就够了

图5 完整连贯示例

2. 唯一性

唯一性是指一个对象在一个时间点只有一个状态,不会同时存在多种同级状态,这是很多同学在设计时没有意识到的一点,其中有两个场景是大家容易混淆的:

1)父子状态

一个对象有父子状态是比较常见的场景,例如前文提到的【待收货】,是一个比较笼统的父状态,它其实包含了【已揽件】、【运输中】、【派送中】、【待取件】多个子状态。

【干货】产品状态设计,看这一篇就够了

图6 待收货的子状态

定义父子状态的目的,是因为有时候子状态过多,在向用户展现时不方便,这时就可以将几个相近的子状态归纳为一个父状态,并以父状态展示给用户。

在这类场景中,有的同学可能就会认为这个商品订单在一个时间点同时有两个状态,但实际上商品订单是以子状态来流转的,所以订单的真实状态是子状态,父状态只是套的一层壳。

2)多名称

多名称是另一个容易混淆的场景,因为有的同学会把多个名称误以为多个状态。

买家收到商品后,订单就应该从【待收货】向下一状态转移,这时我们有【已收货】、【待评价】两个名称可以用,内涵也是一样的。在这类场景中,虽然叫法不同,但其实还是同一个状态。

3. 区分视角

虽然一个对象在一个时间点只有一个状态,但不代表只有一个名称。

在实际状态设计中,为了让不同角色的用户更好的理解一个状态的含义,有时即使是同一状态,针对不同角色用户也会使用不同名称。

4. 统一规则

前面提到,定义状态很重要的一个作用是为了统一这个状态下对象的规则,但要想达到这一目的,就得在设计对象状态时遵守这一原则。

5. 粒度适中

很多同学在梳理对象状态时,随着对流程的细化,会发现这些状态越理越细、越理越多,感觉这里可以加个状态,那里也可以加个状态,最后导致这一对象的状态特别多,状态流特别复杂,徒增用户理解和实现成本。

我们在定义对象状态时,在满足前面原则的前提下,应尽量减少引入更多的状态,控制状态粒度。

6. 通俗易懂

状态名称需要精炼的表达出对象当前阶段的核心进展,并容易被大家所理解,如果实在找不到合适的通俗易懂的词,就要在状态旁边做好说明。

7. 与业务流同向

在状态的定义中,我们强调了状态描述的是业务进展,这里包含的另一层意思是状态流程其实是对业务流程的概括,状态流是在业务流程的基础上总结出来的。

所以状态流程与业务流程一定是同向的,即这个对象在业务上如何流转,它的状态就会以同样的方向流转。

三、设计流程

1. 第一步:梳理操作流程

在设计原则2.7中,我介绍了状态流程与业务流程的关系,那我们是不是有了业务流程就能梳理出状态流程呢?

答案当然是否定的,不然我为什么要问呢。

业务流程之所以不能帮助我们梳理出状态流程,是因为业务流程只能帮我们提炼出状态三要素中的“状态描述”,无法帮助我们精准的确定另外两个要素——“输入条件”和“终止条件”。

大家都知道,在代码实现中,状态要想在系统中流转,需要精确的指令才能进行下一步,这些指令就是状态的“输入条件”和“终止条件”,而业务流程的粒度显然无法满足系统对“精确”的要求,例如商品流转的业务流程是:

【干货】产品状态设计,看这一篇就够了

图7 业务流程示例

在这个流程中,系统无法知道什么算“商家发货”、什么叫“物流配送”。

所以业务流程无法直接指导系统进行状态流转,这时就需要我们梳理出对象在系统中的操作流程,通过系统中明确的操作或业务规则来向系统发出精准指令。

【干货】产品状态设计,看这一篇就够了

图8 操作流程示例(过程做了大量简化)

在这个操作流程中,对于系统自动处理的部分,可以通过增加一个名为“系统”的泳道,来体现系统自动完成的操作。

虽然状态流程是在操作流程的基础上梳理的,但操作流程却是在业务流程的基础上细化出来的,所以业务流程也是很重要的(要充分理解这一步,需要先理解业务流程和操作流程的含义和区别,不过这要扯很久,也偏题了,所以关于各种流程的介绍我们择日再聊)。

2. 第二步:归纳状态

在梳理的操作流程基础上,我们再依据前面提到的设计原则,提炼、总结出此对象的各个状态。

同样的,归纳状态时要明确状态的三个要素分别是什么。

3. 第三步:梳理状态流程

有了第二步梳理的各个状态,顺着操作流程的方向,就能得到我们的状态流程了。为了沟通更方便,表达更清晰,状态流程图就是必不可少的,一般的状态流程图有三种表现形式。

1)纯状态流转

即流程图中仅体现状态的流转,不展示其他信息,如下图所示。

【干货】产品状态设计,看这一篇就够了

图9 纯状态流程图

这种形式很简单、干净,适用于向业务方、上级领导等不需要了解细节的关联方汇报,但对于开发同学来说肯定是不够的,这时就得采用后面两种形式了。

2)与操作流程结合

既然状态流程是在操作流程的基础上梳理的,这就说明这两个流程其实是可以合并处理的。

【干货】产品状态设计,看这一篇就够了

图10 状态流程与操作流程合并

如上图所示,在状态输入条件后展现状态名称,到下一状态开始前,中间过程均为属于此状态。

这种形式在操作流程较短时比较方便,可以用一张图体现两个流程,但当操作流程较长时,这张图的可读性就比较差了,不同信息间会产生干扰,这时就推荐用第三种方式了。

3)仅体现状态三要素

【干货】产品状态设计,看这一篇就够了

图11 仅展示状态三要素

如上图所示,这种形式是在上一形式的基础上,去掉中间无关操作,仅保留状态的三要素,这样既可以满足开发同学对触发条件明确的要求,也方便进行讲解汇报。

4. 第四步:整理状态定义表

如果整个状态及流程容易理解,这一步可以省略,但如果定义的状态和相应规则比较复杂,那最好整理一张状态表来说明各个状态的要素、具体含义和相应规则,以便统一各方认识。

产品经理,产品经理网站

表1 状态定义表模板

四、关联对象的状态设计

大多数情况下,能够梳理清楚业务流程和操作流程,清晰准确的定义状态三要素,那状态设计基本就不会有什么问题了。

不过在状态设计中有一类场景会稍微复杂一些——关联对象的状态关系如何处理。

这里的关联对象,是指两个流程进展上相互有影响的对象,例如父子订单,父订单的流程进展受子订单的影响。

举个具体例子,在某个需求管理工具中,假设需求的状态流程为:待处理——开发中——测试中——已完成。

这时小明创建了一个需求,同时在这个需求基础上拆分了两个子需求,那么父子需求的状态关系应该怎么处理呢?这里有几个常见的处理原则。

1. 一个对象仅有一个状态

父子对象虽然在业务上有父子关系,但各自状态是完全独立的,无论是业务角度还是实现角度都是这样,即便两者可能某些状态的命名都一样,但在逻辑上必须是互相独立。

所以虽然状态名称相同,但实际是不同的对象,实质是不同的。

2. 状态关系与对象流程关系相同

既然两个对象在流程上已经相互影响了,那么状态上也会存在一定的逻辑关系,因为状态流程是建立在对象业务(或操作)流程基础上,常见的几类关系有:

1)包含关系

即一个对象在多个状态间流转时,另一对象看到的仍是一个状态。

例如商品消费订单和这个商品的配送订单,就是一对父子关系,消费者看到的消费订单是【配送中】,但配送订单可能会经过【分拣中】、【运输中】等等很多状态,这就是状态的包含关系。

而之所以状态是包含关系,是因为这两个流程是包含关系,商品配送流程可以看作是商品完整流程中的子流程;

2)衔接关系

即一个对象先到某个状态,另一事项才会到某个状态。例如需求要想进入【已完成】状态,需要子任务进入【已完成】,父任务才允许【已完成】。

3)完全同步

即两个对象的状态是同步的,一个对象随另一对象状态变更而变更。

那有的同学会问了,在很多需求管理工具中,虽然父子需求存在父子关系,但为什么他们的状态是完全独立,相互之间不影响呢?

这其实也是体现了这一原则,因为在这些工具的定义中,父子需求的流程上相互没有影响,所以虽然他们存在逻辑关系,但相互间状态不影响。

到这里,关于产品状态的设计就介绍完了,如果各位读者朋友觉得写得还有点用,记得加我微信一起交流哦~~

 

作者:周翔;公众号:周翔Fly;个人微信:zhouxiangxgg

本文作者 @周翔 。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部