关于B端状态流转的思考
最近接到了这样的需求：我们的业务后台是供业务方创建和维护业务内容的。业务方在创建、变更、完成和中止业务时，需要对不同的业务进展进行变更，由部门主管和其他部门人员协同进行审批。业务方希望在业务后台可以直接看到这项业务发起审批动作后的审批结果是否通过，并在业务后台显示这项业务当前进行到了哪个阶段。
比如张三创建了一个业务，点击了发起了审批的按钮后，这项业务会进入到审批系统，等待审批人员对这项业务的查看和审批。
当在审批人还没有进行审批时，他希望在业务后台中可以感知到这项业务当前处于“审批中”；当张审批人员点击了“审批通过”后，张三再进入到业务后台中，可以感知到这项业务“审批通过”了。
由于我们的业务规则是，只有审批通过后的业务才是正式的业务，才会开展这项业务的后续进度。所以张三还希望知道这项业务是否开始了。
从上面的需求中我们可以发现，无论是审批结果还是业务进展，用户想感知到的是一个环节当前所处的“结果”，感知到了结果才能有下一步的动作。就像我们在淘宝上购买了商品一样，我们希望感知到的是商家是否发货，商品是否在运输中，商品是否已经送到站点；商家希望感知到的是买家是否付款，商品是否签收。
向用户传达某种流程环节的“结果”，在产品设计中通常使用“状态”字段来提供“向用户反馈结果”的能力。
01 状态的定义
“状态”传达的是一种信息，这种信息反馈的是用户可以感知到的某种结果。状态是由于满足了某种条件而触发产生的，被触发的条件可能是由于用户操作了某种动作或是满足了某种规则。
打颗栗子：
我们都在淘宝上面买过东西，买完东西后最常进入的就是我的订单，查看我们购买的东西当前所处的状态。
在订单页我们可以看到不同的状态，我们的订单会置于这些状态下，对应不同状态的订单向用户传递着不同的信息，如下图所示，我将订单状态用红框框了出来：
“待付款”状态下的订单向用户传递的信息是：我提交了订单，但是我还没有付款；“待发货”是我付款后的订单；“待收货”是我的货物，快递公司已经揽收。
在订单页同一笔订单会伴随着不同条件的触发而流转到不同的状态下。其中订单从“待收货”流转到“待评价”状态下的触发条件有2种方式：一种是用户通过操作触发状态切换：用户主动点击了“确认收货”的按钮后状态会发生变更。另一种是通过满足了淘宝的规则触发状态切换：淘宝规则为自状态变更为“商家已发货”状态起，10天后，系统会自动确认收货。当满足该规则时，自动触发切换状态。
状态作为给用户反馈结果的字段，设计“状态”部分时，产品经理要对状态所对应的业务流程进行充分的调研，对“状态”的划分内容和不同状态的产生条件规则，做到准确的界定。因为状态对于用户来说是非常重要的感知字段，设计的状态与需求方达成共识，显示的状态才能便于用户理解和感知，不会造成理解上的歧义和偏差，用户理解起来不会感到困难。
02 状态的作用
1. 状态在产品中的主要作用是为了提升用户体验
产品中的进度状态，本质是体现业务中不同的进度情况，状态变更是按照业务进度变化的顺序分别进行切换的。用户通过状态的变更感知到进度的进展情况，对完成目标之间的距离有一个心理预期，能够及时掌握进度动态变化的信息，降低了用户因等待和无法及时把控进度而产生的焦虑，进而提升了用户体验。
产品的结果状态，本质是反馈一项业务流程最后的成功结果或失败结果。成功结果代表着一件事已经做完了，反馈结果目的是让用户感知到，事情已经完成可以做下一件事了。失败结果代表这件事情没有做完，做的不对，需要继续处理，目的是让用户解决问题。用户根据状态及时知晓结果反馈，帮助用户做出有效决策，提升用户体验。
2. 状态在产品中也有触发用户产生行为的作用
状态的本质是传递信息，在某些场景下也是触发用户产生行为的条件。
拼多多助力免费送商品的活动、12306助力抢票的场景中，我们能看到，免费送的商品和未到手的火车票，状态都是还差多少值（百分比、多少人）助力，就可以到手了。通过状态信息，引导用户产生在朋友圈分享的行为，以及让用户的朋友们产生助力的点击行为。
用户能够通过状态反馈出来的信息产生感受，触发用户产生行为。在设计状态的过程中我们需要推演设计的状态是否真正达到预期希望用户产生的感受和行为。
03 状态流转设计方法
关于状态的流转部分的设计，可以按照下图表格形式的方法进行3个方面的思考，将表格补充填写完毕后，状态流转也就基本搞定了。这张表一共有四个字段，分别是“任务状态”、“可用操作”、“迁移条件”和“状态说明”。
我们将状态名称按照流转的逻辑顺序写到“任务状态”里，状态下可以使用的用户操作写到“可用操作”中，状态流转的触发条件规则写到“迁移条件”里，状态的定义写到“状态说明”中。
1. 定义状态和不同状态下的可用操作枚举
上图任务状态部分是我们通过调研一项业务流程后，梳理出来的状态内容。
第一步：我们对一个业务的某个环节不同状态进行一个界定，列出互斥的状态有哪些。我们要列举的状态是根据不同的触发进行流转的、且互斥的，在列举中我们会去判断这些状态之间是否有上下游关联，是否互斥。
第二步：我们对不同状态的状态结合我们的义务进行定义，对这些状态进行定义的原因是它可以帮助我们二次校验这些状态的关联关系，也可以让我们与开发同学之间对状态的定义达成共识。
第三步：将所有底层的用户动作进行梳理，比如点击XXX按钮，先将全部的按钮都梳理出来，然后将不同状态可以做哪些动作，用蓝色展示，因为蓝色与B端后台的按钮更像，符合用户习惯，将无法操作的动作，用灰色展示，因为无法操作按钮显示出来一般置灰。都梳理出来是为了避免遗漏。
第四步：将这些动作梳理出来后，我们就可以去做迁移条件的界定了。迁移条件可能是触发了某个按钮，可能是根据某种状态触发的，也可能会更复杂一些，更具某个按钮，且某种状态发生了变化后才会触发迁移。但是当我们将动作和状态都梳理好后，再界定迁移条件，就不会有遗漏条件。
当遇到复杂逻辑的状态迁移时，比如状态1是初始状态，当在状态1时，这条数据被点击按钮1后， 状态1发生变化，同时触发了状态2的变化，但是状态1是根据按钮和状态2的变化来影响状态1的变化的。
2. 定义状态流转的顺序
一般我们会将状态的流转以状态转移图表形式进行绘制，避免逻辑缺失。状态机就是状态转移图。
状态机四要素
状态机可归纳为4个要素，即现态、条件、动作、次态。这样的归纳，主要是出于对状态机 的内在因果关系的考虑。“现态”和“条件”是因，“动作”和“次态”是果。
- 现态：是指当前所处的状态。
- 条件：又称为“事件”，当一个条件被满足，将会触发一个动作，或者执行一次状态的迁移。
- 动作：条件满足后执行的动作。动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。动作不是必需的，当条件满足后，也可以不执行任何动作，直接迁移到新状态。
- 次态：条件满足后要迁往的新状态。“次态”是相对于“现态”而言的，“次态”一旦被激活， 就转变成新的“现态”了。
状态机分为有限状态机和无限状态机。
- 有限状态机是指输出取决于过去输入部分和当前输入部分的时序逻辑电路，有限状态机可以确定状态的个数，比如人的某种状态。
- 无限状态机不知道是否正规的说法，从状态机上理解就是输出取决于输入与当前状态，但是当前状态是无限的，不能确定其个数，比如人所在的位置。一般不使用。
一般状态的始态是“待开始”，迁移状态变更为“进行中”，最终的状态为“完成/中止”。
当业务中有状态存在时，我们可以优先将业务状态做成有限状态机来描述，逻辑会很顺畅完整，避免因为状态复杂而丢失逻辑的情况，也会方便研发同学理解。
打颗栗子：
假如张大胖去饭店吃饭，进饭店“待用餐”是状态1，点餐是动作1，点餐动作触发后，触发了状态2：待烹饪-烹饪中-烹饪完成，当烹饪完成之后，状态1才会发生变化，“待用餐”变成“用餐中”，最后变为“用餐完成”。为了避免遗漏逻辑，可以再做一个多状态变化的迁移表。如下图：
总结
状态流转是一项业务某一个环节/任务的生命周期，状态流转逻辑是这个业务环节的底层逻辑，我们在输出原型前，将状态迁移表搭建好会避免状态和条件的遗漏。
状态迁移表建立后可以与业务方多去探讨和改善，在生命周期中达成更深的理解和共识。
当根据状态迁移表做完原型和交互后，自己需要进行校验，看看是否有遗漏的逻辑。
校验的标准就是将自己当成小白，使用实际的资料在自己的原型上跑一遍，自己过的没有问题后， 如果有条件，让业务方根据实际业务也帮助跑一遍看看是否有问题。
参考链接：
《深入浅出理解有限状态机》链接为https://zhuanlan.zhihu.com/p/46347732
#作者#
暮暮，公众号：财务产品人。拥有好奇心且极度认真的产品同学。拥有财务理论知识和财务产品经验，目前在医疗健康领域，擅长中台产品设计。
本文
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
