前言
产品的业务功能设计基本上都离不开业务状态的流转，比如订单状态会有：待付款、待发货（已付款）、已发货、已完成、已评价、已取消等等状态。随着业务的推进，一个业务对象会从一个状态转变到另一个状态，这种状态的流转就是状态机（State Machine）。状态机在业务流转的产品设计中非常重要，如果梳理清楚了业务的状态及其流转条件，那么整个产品的业务逻辑就会非常清晰。本篇我们来讲讲如何进行状态机设计。
什么是状态机
我们先来看下面的订单状态机图，然后再来讲状态机的具体定义。
从上面的图我们可以看到这是订单的业务状态流转图。这里有一个起始状态，就是待付款，这是在用户下单后形成的。然后有三个结束状态，已取消、已完成和已评价。为什么已完成也是结束状态，是因为用户评价不是必要的环节。这里我们就得到了状态机的第一个关键要素：状态机由若干个不重叠的状态组成，状态机中至少有一个起始状态和一个结束状态。
然后我们也会看到，状态和状态之间是通过一条单向的线条连接的，这里引出了状态机的一个特征：状态机是有个有向图。
最后，线条上注明了一个动作，这是促发状态改变的动作，也就是状态的改变是由外部的动作促发的。
结合上面的例子，我们就得到了状态机的定义：
状态机是一个有向图形，由一组状态和一组相应的动作组成。状态机通过响应一系列动作而运行。
如何在产品设计中使用状态机
了解到状态机的定义，我们来看看如何在产品设计中使用它。这里分下面几个步骤：
列举某个业务对象的状态，这里需要使用 MECE 原则，即穷尽而不重复，将业务对象的所有状态都列举出来。比如上面的订单状态图，其实我们就遗漏了已退款、部分退款这两个状态。
梳理哪些状态是起始状态，哪些状态是结束状态，以确定业务的开始和结束。
确定状态直接的流转次序，并且列出促使状态流转的动作，也就是具体的业务行为。
确定每个具体业务行为需要提交的数据和产生的数据，即业务行为的输入输出。
实际简化出来就是“定状态、理流程、明数据”三个要点。我们再举一个我们产品开发的任务管理的例子。对于产品开发任某个需求点，通常会经过需求评审到上线的过程。我们按照上面的步骤进行一下状态机的分析：
状态列举：整个过程有待评审、被驳回、待开发、开发中、待测试、待验收、已上线7个状态。
待评审属于起始状态，被驳回、已上线属于结束状态。
状态的流转图如下：
每个业务行为的输入输出如下表所示。
状态机与流程图的区别
我们看上面的产品开发的任务管理状态机图其实并不是特别合理，不同的状态的流转其实的业务动作是一样的，比如评审不通过和通过实际上的行为应该是评审。之所以会出现这个情况，是因为实际上这里揉和了多个业务对象：需求、开发任务、测试任务等等。这种需要描述多个对象的状态机的情况，那么应该结合流程图来做，如下图所示。这种方式可以将业务对象的状态变化和业务流程串联起来，会更好地知道哪些状态受关联的业务环节影响，比如需求的开发中状态就依赖开发任务的确认开始动作。
可以看到，状态机和流程图某些方面是类似的，都是用来描述业务流转，但是二者也存在明显的不同，状态机更关注的业务环节中某个对象自身的状态变化，而流程图更适合描述整个业务的环节的不同行为如何衔接各个业务对象。也就是，状态机关注的范围相对会更小一些。如果一个业务对象的状态流转无法通过作用于自身的业务行为表示，就可以引入相关业务对象的状态机和流程图来共同绘图表示。由于同时绘制多个业务对象的状态机图可能会很复杂，因此建议将主路径用强调出来，这样可以很清晰地知道主流程如何流转。
总结
本篇介绍了状态机在产品设计中的应用，通过状态机可以很好地梳理单个业务对象业务状态如何流转。同时，对于多个关联的业务对象，也可以使用状态机和流程图结合的方式，梳理业务环节上的多个业务对象的状态流转以及他们之间如何相互影响。实际我们产品设计过程中就可以采取“定状态、理流程、明数据”的方式去梳理业务。
关于产品海豚湾
号主从事过 C 端产品和 B 端产品设计，擅长 SaaS 产品、产品架构设计和需求分析。其中C 端产品在 App Store分类排行榜进入榜单前30， B 端产品完成了完整的从0到1，从1到 N 的过程。
本号主要分享产品干货，尤其是 B 端产品的规划设计、商业洞察、运营支撑、用户体验等相关内容。
