一份PPT可以认为是一个产品，一个PRD文档也可以认为是一个产品，乃至于一张流程图、一封邮件都可以被当做是一个产品。
状态流转图是一种用于描述状态之间流转过程的需求文档，在电商类产品的订单流、审批流一类的需求中比较常见。
相对而言，状态流转图用得并不像业务流程图那么多，所有很多产品经理对这个类型的需求文档不太熟悉。为了更好地给大家分享这个类型的需求文档，火山YY了一个名为扫宝网的C2C海外代购电商平台，并以它的产品上架流程为例予以说明：
业务背景：为了降低平台的产品上架成本，平台为供应端开放了一个产品录入上架的后台，供海外留学生、空姐等人员上架产品;
业务需求：为了把控产品质量，产品需要平台审核通过之后才能上架销售。
根据以上场景及需求，大致绘制出如下业务流程图：
经过分析，此流程至少涉及到两个维度的7种产品状态，即：
审核维度：开发中、待审核、审核通过、审核驳回
上架状态：从未上架、已上架、已下架
那么，这些状态是怎么流转的呢?我们先试着用流程图把状态梳理一下，大致如下图：
乍一看还挺清晰的，但仔细一看，就不难发现其中的问题。
一、流转图的问题
有什么问题，思考1分钟……
问题一、状态缺失
已下架状态缺失，这个问题比较容易发现，但即便你发现了这个状态缺失估计也爱莫能助，因为这个流程中压根不涉及，所以这个状态即便考虑到了也放不进这个流程图!怎么解决?按照这个思路，可能的方案就是到下架流程中进行补充。
虽然这个方法可以解决状态标注的问题，但这并非一个最优的方法，因为解决问题的同时也导致了状态流转被分割到了不同的流程当中，不能在一个流程图当中清晰地呈现各状态之间的流转关系，开发GG、测试MM无法方便地进行查阅，需求文档阅读成本增加。
问题二、状态信息不准确
这个问题不仔细推敲不太容易发现。比如商家录入产品信息这个环节的状态被标记为开发中、从未上架，那么设想一下，如果一个产品在上架之后，由于种种原因，信息需要发生变更，这个时候可能需要重新审核之后才能生效，在商家变更产品信息的过程中，产品的上架状态应该是什么状态呢?显然，无论如何它的上架状态都不会是从未上架。如果说上一个问题带来的后果只是沟通成本增加的话，那么这一个问题带来的后果恐怕就是让自己成为一名实力挖坑的选手了。
问题三、扩展性不强
这个问题前期基本没有，一般到了中后期产品迭代的时候才会逐步暴露出来。为了说明这个问题，火山又YY一个场景，扫宝网的商家在运营一年以后发现后台充斥着大量的废弃商品分散它们的注意力，提高了他们的筛选成本，希望增加一个删除功能，这个时候需要增加一种删除状态，这个状态该如何流转?什么状态下能删，什么状态下不能删?未来还有可能再增加完整状态、有效状态、可售状态呢?还能理得清状态是如何流转的吗?是不是想想都有点头大……
那么，有没有更好的办法可以帮我们更加清晰地描述状态之间的流转关系呢?
二、五步绘制法
有!火山今天就给大家分享一个状态流转图的五步绘制法，希望能对大家有所启发。
第一步：拆分状态维度
由于此流程主要涉及审核、上架两个维度的状态，因此，我们先绘制两个维度的空白表格
火山点评：当业务流程比较复杂，涉及多个维度的状态时，这一步非常非常关键。因为无论一个流程多复杂，被拆分到多个维度之后，单看每一个维度都会变得简单很多。
第二步：绘制第一个维度的状态图
