编辑导语：在B端产品设计中，很多人觉得“状态”的设计非常简单，只不过是几个简短的词汇。但是知易行难，实际上是有很多注意要点的，也会有很多坑。本文作者对产品状态的设计进行了一些分析，希望对你有帮助。

一、基础知识

1. 定义

一个时间段内，对业务对象在业务流程中业务进展的概括性描述。

2. 特点

拆解定义，我们可以得到状态的3个特点。

1）持续性

状态会持续一段时间，并不是对一个瞬时动作的描述。

2）独立性

在一条业务流程中，一个具体的业务对象在一时间段内只会有一个状态。

3）概括性

状态应该用极度简洁的词语来描述业务进展。

例如下面某东的订单页面，我们按照上面的定义来拆解一下。

• 时间段：用户下单到收货
• 业务对象：商品订单
• 业务流程：商品订单流转
• 状态：待付款、待收货、已完成、已取消

图1 某东订单页面

可以看出，某东的商品订单状态，非常简洁，而且格式统一，用户的认知成本低。

3. 要素

了解完状态的定义，接下来我们一起研究研究状态的组成。状态由3个要素组成：输入条件、状态描述、终止条件。

图2 状态要素例子

1）输入条件

状态启动的开关，当输入条件被满足时，状态就会变更。如上图，当“用户付款成功”后，订单状态立即变为【待发货】，所以“用户付款成功”就是输入条件。

2）状态描述

说明这个状态是什么。

3）终止条件

状态关闭的开关，当终止条件被满足时，状态就会变更。如上图，“商家发货”就是终止条件。而且很多时候，一个状态的终止条件会是另一状态的输入条件，如此反复，直到业务流程结束。

图3 状态要素例子

这里还需要注意一点，无论是输入条件还是终止条件，都包含手动和自动两种。

• 手动，即需要用户手动触发，例如“商家发货”，商家手动点击“发货”按钮后，状态就会改为【已发货】
• 自动，即系统根据设置好的规则静默触发

当然，手动和自动是可以同时存在，或只存在任意一种。

例如【已取消】，可以是用户主动取消订单，或是在规定时间用户没有付款，系统自动取消该订单。平时我们在做产品设计时，在实际业务允许的前提条件下，应尽量增加系统静默操作，减少用户手动操作，甚至是全自动。

4. 作用

状态的作用，主要有3个。

1）展示进度

状态可以向用户展示当前业务流程的进度，缓解用户焦虑，给予用户确定性，进而提升用户体验。这点非常重要！想象一下，你计划用年假去旅游，在OA上提了一条请假流程，但苦等了一周，完成不知道流程走到哪了，这是一种什么感受？

2）统一规则

同一角色/对象在一个状态中的操作权限、规则都是相同的，这点无论是对于开发还是用户都非常有意义。

3）便于描述

如果日常沟通中，同一状态你说A，你的同事却说B……

二、设计原则

1. 连贯完整

在一条业务流程中，业务对象的前后状态是紧密衔接的，不应该出现任何真空期。

这也引出了第2点设计原则。

2. 唯一性

这是指一条业务流程中，业务对象在某个时间点有且仅有一个状态，就算是完全没被触发，也可以叫做【未启动】。

但是有一个坑，也许大家在做产品设计的时候会遇到：父子状态。当一个对象在某段业务流程中有很多不必要第一时间给用户展示的状态时，可以将几个相近的状态抽象归纳出一个父状态向用户进行展示。例如某东的商品订单有一个状态叫【待收货】，它其实有很多子状态（如下图），只是在订单列表页没有必要将一个订单所有的【待收货】子状态都展示出来。

图4 子状态例子

在这类场景中，有的人就会认为：这不是两个状态同时存在了吗？

非也，其实这里可以把子状态又看做一条新的业务流程，两个状态是存在不同的业务流程中的。像上面【待收货】的子状态，其实是用来描述商品送货流程的。

3. 区分视角

虽然在一个时间点，一条业务流程中业务对象只有一个状态，但不代表只有一个名称。

实际状态设计时，为了让不同角色的用户更好理解一个状态的含义，有时即便是同一状态，也会有不同叫法。

还是以某东的商品订单状态为例，用户确认收货后，订单状态有【已完成】和【待评价】两个可用，两个内涵上其实是一致的。

4. 统一规则

前文已经提及。

5. 粒度适中

很多朋友在梳理对象状态时，随着业务流程的细化，感觉这里可以加个状态，那里也需要加个状态。最后导致状态特别多，特别复杂，用户理解和开发成本直线增加。

所以我们在定义状态时，在满足实际业务场景和设计原则的大前提下，要尽量减少或抽象状态，控制粒度。

6. 通俗易懂（简洁明了）

时刻记住：别让用户思考。

7. 与业务流程同向

前面也说了很多，状态是描述业务进展的，其实也是对某个业务流程节点的概括。

所以状态和业务流程一定是同向的。

三、设计步骤

1. 梳理操作流程

为什么不是梳理业务流程？

因为梳理业务流程只能得到状态描述，而梳理操作流程，还可以得到状态的输入条件和终止条件。

在实际开发中，不管是手动还是自动，想要在系统中变更状态，就需要明确变更指令，而输入条件和终止条件就是变更指令。

图5 商品订单操作流程（简易图）

例如在电商的商品流转业务流程中，系统无法知道什么才是“物流配送”，必须要我们梳理出具体操作流程和明确业务规则，向系统发出精确指令。

图6 商品订单操作流程（泳道图）

2. 抽象、归纳状态

根据前面的设计原则和梳理出来的操作流程，提炼、抽象、归纳出对象在各个动作后应该有的状态。

3. 梳理状态流程

有了第2步归纳出来的各个状态，再顺着操作流程，就可以得到状态流程图了。

状态流程图也根据应用场景、受众大致分为3种。

1）纯状态流程图

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

图7 状态流程图（简易）

这种形式的流程图十分简洁，适合向老板、客户等不需要了解细节的业务方汇报。

2）与操作流程图结合——单泳道图

上面那个图是万万不可拿给开发同事看的，不信你可以试试。

最好使用下面这个图来讲解需求，或作为需求文件留档。

图8 状态流程图（单泳道图）

在状态输入条件后展示状态描述，到下一状态开始前，中间过程均属于此状态，也可以使用双泳道图来表示。

3）与操作流程图结合——双泳道图

图9 状态流程图（双泳道图）

但是这种在某些情况下可能有些难以理解，第2种和第3种和开发商量着用吧，看他们哪种比较好理解，毕竟流程是画给人看的，不是用来炫技或者收藏的。

4）整理状态定义表

为了让我们的开发同学和业务方都能更好的理解需求，除了流程图，最好再附上一个状态定义表。

图10 状态定义表

可根据自实际业务情况自定义。