流程图|用概念破解思路问题，三步教你绘制大厂标准状态图

编辑导语：状态图表述了一个对象所处的状态，以及导致该对象状态转变的操作链条，是产品经理工作中常接触到的事物。那么，状态图应该如何绘制？状态图和流程图又有什么区别？本篇文章里，作者就状态图的绘制策略等方面做了总结，不妨来看一下。

文章插图
本文是万字长文《三步教你绘制大厂标准状态图》系列文章的第二篇——状态图的误区。
第一篇文章是说状态图的绘制标准，其中提到高级产品经理画的「产品经理工作状态图」问题很多，该图既没搞清楚目的，更没搞清楚概念和画法，总之错误很多，画这样的状态图是会被研发打的。本文就来分析分析这类图的问题，顺便也说说状态图和流程图的区别。
一、状态图的问题状态图如果画错，其实就是没有理解第一篇文章中讲到的状态图的概念和画法，要阅读上文请。下面我们就依据标准说说状态图的常见问题。
1. 有对象才有状态状态是针对一个实际存在的事务而言的，这个事务就是一个对象，只有有了对象才有了状态。这是再自然不过的了，然而很多人却忽略了这个常识。
下面我们先说说对象是什么，再说问题所在。
简单地说，一个对象就是一个实际存在的事务。这个事务可以是某家的微波炉或某人的身份认证信息。而一个对象（一个事务）就会有若干状态，并且只有有了对象才有状态。比如，这台微波炉的状态是已关闭，这个身份认证状态是已审核通过，无论是微波炉还是身份认证都是实际存在的。
但却有人在身份审核状态图中，加入“已新建”这个状态。如下图所示，这是错误的！

文章插图
因为用户“单击新建申请”这个操作，是不会产生“已新建”状态的，这就是打开了身份审核的界面而已。如果用户单击关闭，系统不会保留该信息，也就是说这个对象不会被创建。对象不存在，那么“已新建”状态就是不存在的。
但凡事都不绝对，如果设计的系统是：只要用户单击进行身份认证，且用户填写了一点内容，就将信息保存成草稿，是会存在“草稿”状态的。保存成草稿后，用户退出后再次回来，还可看上次的信息，这时加入“草稿”状态就有必要。
通常，只有要填写的内容较多的时候，才会有草稿状态。有了这个状态，就能避免出现用户一次填不完信息，又保存不了的问题。
2. 表达“一个”对象状态图是用来表达对象的状态。并且，状态只能表达“一个对象”的状态，这也是很自然的。
比如，我们不能在一个状态图中，同时表达商品和订单的状态。如何画呢？我们根本无法在一个图中画出来。订单有“已发货状态”，这和这个商品是否下架没关系，而“商品已下架”就是商品的状态。
因此，为避免一个状态图中表达两个对象，我们建议在状态图中都写上对象名。如在身份审核状态图中，在每个状态名中都加入“身份信息”这个对象名。
虽然在状态中重复写了对象名，但是却好处很多。比如我们在上一篇中提到的「产品经理的工作状态图」如下。

文章插图
这个图的问题就是把多个对象放在了一个状态图中，其实这个状态图有两个对象。分别是：需求和身体。
首先，产品经理提交的需求就是一个对象。需求的状态有已提交、已拒绝和已通过。这样就可抽象出一个需求管理系统，该系统用来管理需求文档。
其次，产品经理的身体是另一个对象。身体的状态可以是健康、生病和死亡，这样就可抽象一个医院管理系统。
比如身体状态是重伤，就不要挂号了，而是直接住进ICU；但如果是轻伤状态，就要排队挂号等待就诊；如果很不幸，是死亡状态，那么也不用看病了，要直接进入太平间。
而如果把需求和文档画在一个图里，意义在哪里呢？没有任何意义。我们只是看到了一个逻辑混乱，让研发鄙视的产品经理。
产品经理即使生病也可以提交需求，即使不生病也可以不提交需求，生不生病和提交不提交需求就是两件事，混在一起就错了。
3. 不可有判断标志在有的书中状态图可加菱形的“判断标志”，但不是主流，本人也不建议加入。因为不加“判断标志”表达会更简洁和无歧义。而回顾身份审核的状态图，如果加入菱形的“判断标志”，就如下图所示。