在产品设计中，状态管理是产品经理不可或缺的技能之一，尤其是在处理复杂业务流程时。本文作为产品实操系列的一部分，聚焦于如何通过状态机的概念来优化产品设计。
今天，针对产品经理的后端设计，我们继续讲讲实操内容。
如同我上次说过的，流程、信息结构、状态、策略，算是产品经理进行后端设计的四个组成部分。
今天我们进展到了第三个。
希望这个系列讲完了，能够给创业团队的产品经理们，带来一些帮助。
在技术的日常开发中，有一个常用的名词叫状态机。
这和软件工程相关，也是非常基础的技术设计。
这方面的内容很专业，而且从技术角度出发，经常可以做出很复杂的模型，产品经理们简单了解一下就可以。
而产品经理在进行产品设计中，其实是有所不同的。
那么，产品经理把状态引入到产品设计中的目的是什么呢？
当然还是为了服务于业务。
就是为了处理一个业务在流程中分阶段的情况，而且可以在信息结构中来体现。
也就是因为此，我们先讲了流程和信息结构，再讲状态。
讲到这里，太过于枯燥了，所以我们直接上案例吧。
直接举个例子来说吧。
当时我们做民宿的时候，针对订单这个基础产品，从业务上可能会有如下几个流程：
就这样的一个过程中，从业务角度出发，订单出现了哪些的可标记的状态变化呢？
我们可以梳理一下：
1. 用户已预订
用户在民宿平台上下单，并且完成了入住时间、入住人信息等内容填写，生成了新的订单。
2. 用户已支付
订单生成后，会等待用户进行支付，这个时间根据不同平台，一般是在半小时或两个小时之内（时间不能太长，否则会恶意占用时段不支付，造成房东的损失）。
3. 用户未支付
因为某些原因，用户没有支付，订单被取消。
4. 用户已取消
在入住完成之前，用户没有来入住，用户就自行取消了。
5. 房东已取消
因为房东的原因取消了订单，此时一般就进入到了赔付流程。
6. 用户已退房
用户一直住宿到了退房时间，然后离开。
7. 保洁已清洁
保洁阿姨在用户离开了之后，进入民宿客房来完成打扫。
以上状态是不是也还是挺晕乎？
没关系，待我们慢慢讲~
至少上面的工作，达成了这样一点：
我们根据业务情况，梳理出来一个民宿订单的所有可能的状态。
这些状态会整理成枚举值，作为订单的信息结构的一部分。
注意，以上仅做举例，和我真正了解到的民宿平台的订单状态是不一致的，我也是有意为之，请不要借鉴到商业中。
就拿这个例子来说，如果只是一串零散的订单状态，可能还不具备有足够强的工具性。
那么此时就需要通过状态迁移图，来把这些零散的状态进行连接。
这里就有点像技术所使用的状态机迁移图了，但还是通过业务角度来进行组织的，所以一般也会较简单。
如上所示。
注意，以上我仅做举例，和我真正了解到的民宿平台的订单状态是不一致的，我也是有意为之，请不要借鉴到商业中。
关于状态迁徙图，有如下几个要点：
1. 主状态的流程
最好从上到下贯穿，作为主干。
2. 特殊的状态、中断的状态
作为枝干在两侧，这里我把和用户相关的放在了左边，和房东相关的放到了右边；
3. 连接条件
状态和状态之间，通过是某种条件来进行连接，要注意使用单箭头，即便两个状态可以互相转换，那条件也是不一致的。
4. 到达最终状态
从业务角度出发，如果一个状态不是最终状态，那么一定要达到最终状态。
这句废话可以举个例子，就是如果用户已预订但没有支付，那从业务角度出发就一定不是最终状态，必须要达到支付时间超时，到达支付未完成才算结束。
5. 前后端不必统一
后端设计中所展现出来的状态，无论是名称还是更多内容，在前端给用户展示时不必是统一的。
举例而言，上图中的状态：支付未完成、用户已取消、房东已取消，前端都可以展示成订单已失效；用户已退房，前端就可以直接展示为订单已完成，因为保洁的后续工作已属于内部流程。
还是老生常谈，跟技术如何对齐呢？
虽然在技术的实际开发中，并不一定会需要和业务关联比较紧密的状态设计，但是产品跟技术对齐之后，可以有如下几个好处：
有时候除了后端的状态设计，还有前端的状态设计。
但从概念上来说，两者其实并不太一致。
如果后端的状态设计是和技术开发相关。
那么前端的状态设计是和交互设计相关。
举个简单的例子。
如果前端设计一个音乐播放器，但只有一个主按钮，根据交互，需要展示四个状态：
前端可能是需要这4个样式：
一般来说没有什么太复杂的状态迁移，所以也不需要画状态迁移图。
主要是便于和交互设计师来进行沟通，最终达成成熟的方案。
本文由 @觅云人 原创发布于人人都是产品经理。未经作者许可，禁止转载。
题图来自 Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。