状态定义做得好，用户体验更进一步

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

状态定义是产品设计的常客 ，不同的状态定义对应不同的系统功能和业务流程，最后会影响用户体验的好坏。状态定义不能无差别先堆砌，应当根据实际的使用场景进行设计，这才是符合场景基础、能够满足用户需求的产品设计。

作者：像西泽一样

题图来自 Unsplash，基于 CC0 协议

全文共 2940 字，阅读需要 6 分钟

—————— / BEGIN / ——————

在产品设计过程中，经常会遇到一些状态定义的场景。比如订单有待付款、待发货、待收货等，商品有上架、下架等，课程有待上课、上课中、已上课等。

有些状态可能只用于前端展示，而另一些状态，可能跟业务流程有很强的关联。

不同状态对应着不同的系统功能、业务流程。

合理定义状态，是好的产品体验和顺畅的业务流程的保障。

我做过算法工程师，现在是教育行业的后台产品经理。我觉得技术背景对于我在进行状态定义时，有一定的帮助。

本文根据自己遇到的状态定义的需求，来谈谈如何定义状态。

文章结构比较简单，包括背景、如何定义状态、实例，一共三部分。

如何定义状态的正文部分，会将理论和实例结合，实例部分则给出完整例子。

一、如何定义状态

1. 明确目的

当需要定义一个状态时，首先要问自己“为什么要定义这个状态？”——明确目的。

定义订单状态，是因为用户需要知道订单状态的信息，同时后台系统也需要订单状态来做不同的动作；

定义商品的上架、下架，是为了控制商品在商城里的展示、售卖；

定义课程状态，是为了数据统计、筛选等。

我发现一些产品有堆砌状态的现象，所谓堆砌状态，就是先把状态做了，然后去想这个状态能用在什么地方。

比如针对课程，设计了冻结操作，冻结后课程的状态会从正常切换到冻结状态。但冻结状态对应什么动作呢？并没有设计。

问其为什么这样设计，回答说大家都这么设计，先把这个状态定义了、把这个功能做了，将来肯定会用到。

当然，确实会存在一些常规设计，或者说不用多想就可以进行的设计。

但更多时候，应该是遇到一个问题、一个场景，需要用到一个状态来解决这个问题、处理这个场景的时候，我们再来定义状态、设计功能。

2. 状态定义、功能、展示

1）状态定义

首先要注意，状态分两类：

系统自动判定得到的状态，比如课程的待上课、上课中、已下课状态，系统可以通过比较当前时间和课程的开始、结束时间，自动判定得到；

人为操作得到的状态，比如课程的上架、下架，需要人为点击功能按钮，进行状态的切换。

系统判定的状态需要有明确的定义。

不同状态之间应该是互斥的，不应该出现某些情况下既可以判定为状态A，又可以判定为状态B。

比如课程待上课、上课中、已下课的状态定义：

当前时间小于课程开始时间是待上课；

系统时间大于课程开始时间、小于课程结束时间是上课中；

当前时间大于课程结束时间是已下课。

——三者互斥。

而人为操作得到的状态，与其说状态定义，不如说状态设定更合适一些。但为了统一描述，文中都称为状态定义。

人为操作得到的状态的设定，需要的不是定义，而是设定原则或者说依据，不能毫无章法，想到什么就是什么。

比如最简化的例子，商品的上架和下架，设置原则是商品是否要售卖：商品要售卖，则对应上架状态；商品不卖了，则对应下架状态。

2）状态对应功能

状态定义不是目的，只是手段。

通过定义状态，使得系统、用户可以根据不同的状态值，进行不同的系统动作、人为动作——这才是目的。

所以，每个状态除了有明确的定义，有设定原则，更要有相应的功能设计，这甚至比状态定义更重要。

状态的定义可能出现冗余，或者定义之后发现通用性欠佳，仅能用到极少数地方。但如果只定义了状态，没有相应的功能设计，等于舍本逐末；甚至可能因为功能设计不够严谨，状态间没有形成逻辑闭环，导致整体设计无效。

比如商品的上架、下架，上架对应的功能可能有，用户在前端看到商品显示已下架，且没有购买入口按钮。

而在后台系统某些商品筛选结果列表中，不展示下架状态的商品；以及后台系统商品列表中，下架状态商品对应的操作中，应该有“上架”操作按钮，即可以通过点击上架按钮，将商品从下架状态切换至上架状态。

功能设计最重要的是考虑周全，这不容易，但有一定规律。

常见的与状态相关的功能设计有这么几类，包括前端展示、筛选、状态切换操作按钮、系统判定规则等，可以以此作为大的方向，结合自家系统的实情进行设计。

3）展示

状态对应的前端展示属于功能里设计中的一项，之所以独立成题，是因为展示是用户直接能看到的部分，所以需要考虑清楚每种状态下，各端应该如何展示。

比如商品下架后前端商品的展示，是在列表页展示商品，但进入详情页再提示商品下架；还是不在列表页中展示商品，这是需要明确设计的。

3. 状态的切换

不同的状态间会互相切换，如果是系统判断得到的状态，要明确状态切换的节点，即满足什么条件时，会从一个状态切换到另一个状态。

而人为操作得到的状态，要注意状态切换闭环的问题。

比如状态A、B、C三者之间可以互相切换，需要设计操作按钮，使得从A可以切换到B，从B可以切换到C，而且还可以从C切换到A；而不是从B切换到C之后，发现没法重新切换到A或者B了。

比如最简单的例子：操作人在后台系统中，通过点击上架按钮，将商品切换为上架状态后，上架按钮处应该显示下架按钮，这样操作人才能通过点击下架按钮将上架状态的商品切换为下架状态。

二、实例

这里举一个课程状态的例子：

教育行业中，课程即是商品，课程的状态类似商品的状态。这里我们按照前文中的讲解，一步步来定义课程状态。

注意：实例做了大量简化，仅用来说明状态定义过程。

1. 目的

通过课程状态，定义课程的整个生命周期，为不同生命周期对应的功能提供判定依据。

2. 状态定义、功能、展示

1）状态定义

课程的状态属于人为操作得到的状态，所以需要考虑好每个状态设定的原则。

待发布：课程内容已准备好，但售卖属性未准备好；

待上架：课程内容、售卖属性都准备好，但不展示给用户；

招生中：课程内容、售卖属性都准备好，并展示给用户；

停止招生：用户无法购买课程。

2）状态对应功能

注意：所有功能除了整体功能描述外，一定要给出具体功能设计。

比如，当整体功能描述为“可编辑内容属性”时，应该给出具体功能设计：课程标题编辑框可编辑，课程类型选择框可选择等。这里为了简化，只给出整体功能描述。

待发布：可编辑内容属性，但不可编辑销售属性，不可创建班级；

待上架：部分内容属性不可编辑，可编辑销售属性，可创建班级；

招生中：不可编辑销售属性，可创建班级，用户可购买；

停止招生：用户不可购买。

3）展示

待发布：前端商城不展示，通过售卖链接进入售卖页，给出错误提示；

待上架：前端商城不展示，通过售卖链接进入售卖页，根据售卖状态（另一个状态）做相应展示；

招生中：前端商城展示，通过售卖链接进入售卖页，根据售卖状态做相应展示；

停止招生：前端商城不展示，通过售卖链接进入售卖页，给出停售提示。

3. 状态的切换

待发布切换为待上架：发布按钮变更为上架按钮；

待上架切换为招生中：上架按钮切换为停售按钮；

招生中切换为停止招生：停售按钮切换为上架按钮。

注意：最后一个状态的切换，课程状态切换为停止招生后，操作按钮从停售按钮切换成了上架按钮；也就是说，可以点击上架按钮重新上架，这样就形成了状态切换的闭环。

—————— / END / ——————

每个「在看」，都是一次鼓励