在产品设计中，状态管理是产品经理不可或缺的技能之一，尤其是在处理复杂业务流程时。本文作为产品实操系列的一部分，聚焦于如何通过状态机的概念来优化产品设计。

今天，针对产品经理的后端设计，我们继续讲讲实操内容。

如同我上次说过的，流程、信息结构、状态、策略，算是产品经理进行后端设计的四个组成部分。

今天我们进展到了第三个。

希望这个系列讲完了，能够给创业团队的产品经理们，带来一些帮助。

0 产品or技术：状态设计的区别

在技术的日常开发中，有一个常用的名词叫状态机。

这和软件工程相关，也是非常基础的技术设计。

这方面的内容很专业，而且从技术角度出发，经常可以做出很复杂的模型，产品经理们简单了解一下就可以。

而产品经理在进行产品设计中，其实是有所不同的。

那么，产品经理把状态引入到产品设计中的目的是什么呢？

当然还是为了服务于业务。

就是为了处理一个业务在流程中分阶段的情况，而且可以在信息结构中来体现。

也就是因为此，我们先讲了流程和信息结构，再讲状态。

讲到这里，太过于枯燥了，所以我们直接上案例吧。

1 后端的状态：是和业务相关的

根据流程来梳理，体现到信息结构中

直接举个例子来说吧。

当时我们做民宿的时候，针对订单这个基础产品，从业务上可能会有如下几个流程：

1. 用户在民宿平台上筛选到了心仪的房源，并进行了下单，完成了支付；
2. 到了入住日期，用户进行入住；
3. 到了退房日期，用户离开；
4. 用户退房离开后，民宿平台或房东，会通知保洁进行房间清洁，等待迎接下一批用户。

就这样的一个过程中，从业务角度出发，订单出现了哪些的可标记的状态变化呢？

我们可以梳理一下：

1. 用户已预订

用户在民宿平台上下单，并且完成了入住时间、入住人信息等内容填写，生成了新的订单。

2. 用户已支付

订单生成后，会等待用户进行支付，这个时间根据不同平台，一般是在半小时或两个小时之内（时间不能太长，否则会恶意占用时段不支付，造成房东的损失）。

3. 用户未支付

因为某些原因，用户没有支付，订单被取消。

4. 用户已取消

在入住完成之前，用户没有来入住，用户就自行取消了。

5. 房东已取消

因为房东的原因取消了订单，此时一般就进入到了赔付流程。

6. 用户已退房

用户一直住宿到了退房时间，然后离开。

7. 保洁已清洁

保洁阿姨在用户离开了之后，进入民宿客房来完成打扫。

以上状态是不是也还是挺晕乎？

没关系，待我们慢慢讲~

至少上面的工作，达成了这样一点：

我们根据业务情况，梳理出来一个民宿订单的所有可能的状态。

这些状态会整理成枚举值，作为订单的信息结构的一部分。

注意，以上仅做举例，和我真正了解到的民宿平台的订单状态是不一致的，我也是有意为之，请不要借鉴到商业中。

用状态迁移图连接起状态

就拿这个例子来说，如果只是一串零散的订单状态，可能还不具备有足够强的工具性。

那么此时就需要通过状态迁移图，来把这些零散的状态进行连接。

这里就有点像技术所使用的状态机迁移图了，但还是通过业务角度来进行组织的，所以一般也会较简单。

如上所示。

注意，以上我仅做举例，和我真正了解到的民宿平台的订单状态是不一致的，我也是有意为之，请不要借鉴到商业中。

关于状态迁徙图，有如下几个要点：

1. 主状态的流程

最好从上到下贯穿，作为主干。

2. 特殊的状态、中断的状态

作为枝干在两侧，这里我把和用户相关的放在了左边，和房东相关的放到了右边；

3. 连接条件

状态和状态之间，通过是某种条件来进行连接，要注意使用单箭头，即便两个状态可以互相转换，那条件也是不一致的。

4. 到达最终状态

从业务角度出发，如果一个状态不是最终状态，那么一定要达到最终状态。

这句废话可以举个例子，就是如果用户已预订但没有支付，那从业务角度出发就一定不是最终状态，必须要达到支付时间超时，到达支付未完成才算结束。

5. 前后端不必统一

后端设计中所展现出来的状态，无论是名称还是更多内容，在前端给用户展示时不必是统一的。

举例而言，上图中的状态：支付未完成、用户已取消、房东已取消，前端都可以展示成订单已失效；用户已退房，前端就可以直接展示为订单已完成，因为保洁的后续工作已属于内部流程。

和技术如何对齐

还是老生常谈，跟技术如何对齐呢？

虽然在技术的实际开发中，并不一定会需要和业务关联比较紧密的状态设计，但是产品跟技术对齐之后，可以有如下几个好处：

1. 无论是产品还是技术，都不会完全脱离业务，知晓业务流程每一个环节应该是什么样的状态，便于开展对应的设计；
2. 技术开发中就可以避免不必要的分支，比如用户已取消，就不会再到用户已支付状态，对测试形成用例也会有一定帮助。

2 前端的状态：是和交互相关的

有时候除了后端的状态设计，还有前端的状态设计。

但从概念上来说，两者其实并不太一致。

如果后端的状态设计是和技术开发相关。

那么前端的状态设计是和交互设计相关。

举个简单的例子。

如果前端设计一个音乐播放器，但只有一个主按钮，根据交互，需要展示四个状态：

• 未播放
• 正在播放
• 播放暂停
• 播放完成

前端可能是需要这4个样式：

一般来说没有什么太复杂的状态迁移，所以也不需要画状态迁移图。

主要是便于和交互设计师来进行沟通，最终达成成熟的方案。