设计流程状态的5个注意事项
笔者刚转行做产品经理时,曾设计过一个话费充值业务的订单流程,订单状态只有“充值中、充值成功、充值失败”状态。
自认为完整,但这订单流程不仅缺失了“充值中”的前置状态“待提交充值”,也没有考虑可能存在的其他流程和状态,如支付流程的“未支付、支付中、支付成功、支付失败”状态;退款流程的“退款中、退款成功、退款失败”等状态。
而且,状态间的流转条件、话费订单状态与用户端原订单状态的映射关系等方面,考虑也有所欠缺,整个方案设计显然不能支撑业务的正常运转,在需求评审时,被无情的打回重新思考。
将业务流程产品化为系统流程,是B端产品经理的核心工作内容之一,而流程状态,则是系统流程设计的重要组成部分。
如果流程状态设计不合理,会影响使用人员对流程进度的把握,严重的话,可能会导致业务无法正常运转。
一、什么是流程状态?
截图是淘宝的物流详情,相信大家并不陌生,可以看到商品下单后,快件会经历“xx已收取快件、xx收件点装车、发往xx中转站、到达xx中转站、xx中转站装车、到达xx网点、xx在派送快件、本人签收/代签收”等物流过程,最终到达用户手中。
物流流程由一系列的物流过程构成,物流过程虽然详细,但大大降低了可读性,用户无法第一时间判断快件的现状。
淘宝为了提高物流流程的可读性和结构性,基于快件不同阶段、不同状况的表现形态,定义成为物流状态:已下单、已揽件、运输中、派送中、已签收。
- 已下单:商品已经下单
- 已揽件:已收取快件
- 运输中:收件点装车、发往中转站、到达中转站、中转站装车、到达网点
- 派送中:派送快件
- 已签收:本人签收/代签收
相对于物流过程,使用物流状态来描述物流流程的现状,更直观和简洁。
综上所述,流程状态是为了直观、简洁描述一个流程的现状,基于对象在流程内不同状况的表现形态,经过分析和提炼后,定义成具有业务特征的可视化形容词,是构成流程的核心因素。
二、流程状态有什么作用?
1. 准确把握流程进度,便于跟踪
业务在系统作业时(如下单、发货),会经历各种系统流程,而管理人员最关心的就是流程进度。如果系统流程没有流程状态,我们只能通过大量文字来描述当前流程的状况和流转顺序。
那么,当管理人员在面对成千上万条业务数据时,将要投入更多精力去跟踪业务的情况,而且无法准确把握流程进度。
通过“调拨状况”查看众多调拨单的调拨情况,看着都费劲。
但如果将“调拨状况”通过使用“调拨状态”的方式表达,管理人员可以一目了然的掌握调拨流程的当前进度、执行情况和转换顺序;再通过批量筛选同类型调拨状态,可提高跟踪效率。
2. 引导用户正确操作
如果系统流程缺少流程状态,我们将无法根据在什么状况下,提供相应的功能操作,只能把所有功能操作都展示出来,让管理人员自行判断和操作。
管理人员在面对复杂流程的交互操作时,将会不知所措,不清楚当前状况下应该做什么,很容易导致操作失误,影响流程的运转。
如果根据流程状态的标识,展示和隐藏对应的功能操作,将有效避免管理人员对交互操作的迷茫和操作失误。即通过流程状态限定对应的功能操作,从而达到引导用户操作的目的。
如当调拨流程处于“待采购入库”状态时,仅能进行【取消调拨、修改调拨、入库采购单】操作,不能进行【入库调拨单】或【上架入库商品】操作。
由流程状态限制功能操作的设计,是引导用户正确操作、防止误操作的常用手段。
三、设计流程状态时需要注意什么?
1. 流程状态的命名
流程状态的名称并不是一个简单符号,直接影响流程的状况能否准确传达给用户,本质是如何定义一个流程状况。让用户群体理解并接受的流程状态名称,是发挥其价值的第一步。那么,该如何给流程状态命名?
1)运用结构化方式命名
由于流程状况的描述方式,仅仅对信息要点进行罗列,各流程状况之间的信息是分散的,缺乏逻辑顺序,大大降低了用户的可读性。
通过结构化方式把流程状况的要点进行提炼,定义成流程状态名称,体现出各流程状态的结构关系,可提高可读性。
常用的结构化命名方式有以下2种:
副词+动作:用于修饰关键流程状况的动作
流程状况“货物在华南仓,还没装车调拨出库”,其中“调拨出库”为关键动作,通过副词“待”修饰动作,定义为“待调拨出库”,表示货物还没调拨出库;再如其他状态:待支付、待采购入库、已发货等。
动作+结果:用于描述流程状况动作与结果的关系
流程状况“用户通过支付宝支付成功”,其中“支付”是动作,“成功”是结果,定义为“支付成功”,表示支付动作的结果;再如其他状态:支付中、交易成功等。
2)名称要契合业务
TO B产品的流程状态往往与业务强相关,当管理人员看到状态名称时,能第一时间判断流程属于哪个业务,还能从当前的所处状态,推断业务已经过了哪些状态,之后还有哪些状态。
如果脱离业务随便命名,会增加用户的理解成本,严重的话,可能会导致用户作出错误的决策。
仓库管理系统的流程五花八门,当我们看到“待审核调拨单、待调拨出库、已调拨出库、已调拨入库”等状态时,能立马知道这是属于调拨流程的状态。
但如果仅显示“待审核、待出库、已出库、已入库”,我们可能就要思考这是属于物料出入库流程、成品出入库流程,或者是其他流程的状态,这无疑会增加理解成本和降低工作效率。
2. 流程状态之间的流转条件
流转条件指满足某个既定条件后,状态A才能流转至状态B,或者状态A会逆向返回前面某个状态,在未达到流转条件前,状态A不能往下走到下一个状态。
如果没有流转条件,意味着流程状态之间失去了建立联系的信号,系统将无法自动执行流转。
而管理人员在面对错综复杂的流程状态时,也只能自行判断和人为操作流程状态的走向,一旦流程状态流转方向有误,将直接影响业务的正常运行。
通过设定清晰的流转条件,可串联起独立分散的流程状态,确保系统流程的各流程状态有序、有方向的流转,支撑业务的运行。
当话费订单由于“充值结果为充值失败”时,充值状态由“充值中”流转为“充值失败”;当话费订单由于“充值失败而自动退款”条件时,充值状态由“充值失败”流转为“退款中”;当“网络异常、系统故障等原因”导致退款失败时,系统自动发起重新退款,充值状态由“退款失败”返回上一节点“退款中”。
通过“充值失败、自动退款、退款异常、正常退款”流转条件,将话费订单流程的“充值中、充值失败、退款中、退款失败、退款成功”状态建立了关联关系,如下图(已省略部分流程和细节)。
3. 流程状态的操作功能
一般情况下,流程状态在满足既定的流转条件后,可由系统自动执行流转,完成系统流程的闭环。
但也会存在一些不适合系统全自动流转,必须要人工干预和操作后才能执行的非标准化、高风险流程,如财务付款流程、短信群发流程等。
人工干预和决策的流程,需要操作功能的支撑。否则,系统流程会一直停留在某个流程状态无法推进。
不同的流程状态,所需的操作功能是不同的,操作功能会与流程状态产生作用,引起流程状态的流转,我们要考虑与流程状态对应的操作功能,将流程状态和操作功能相结合,引导用户操作。
如订单交易失败需要人工审核才能退款的情况下,“交易失败”状态要有与之对应【审核退款】的操作功能。管理人员点击【审核退款】操作后,订单流程才能从“交易失败”流转到“退款中”状态。
4. 流程状态的映射关系
一个业务从开始到结束会经历一系列的流程状态,在设计流程状态时,一般会把用户端可见的流程状态,与运营管理端的流程状态相互分离。
如果对用户开放所有运营管理端的流程状态,不仅增加用户对系统流程的理解成本,还会造成信息干扰。
电商平台为了便于用户理解订单流程,将用户端的订单流程设计为“待付款、待发货、待收货、待评价、退换/售后”状态。
站在运营管理的角度,一笔订单从产生到交易成功,可能会经过风控流程、支付流程、出库流程、物流流程、售后流程、异常流程等等,每个流程都存在多个流程状态,关系错综复杂。
但大部分的流程状态,用户并不关心,也无需让用户知晓。通过建立用户端和运营管理端流程状态的映射关系,能解决这方面的问题。
流程状态的映射关系,指不同系统流程之间的状态,相互对应的结构关系,即把一个流程的流程状态,对应到其他流程的流程状态。
常见的映射关系有以下2种:
1)一对一的映射关系
指系统流程A和系统流程B中,A的流程状态A1,在B中只有流程状态B1与之对应,状态A1与状态B1的关系,为一对一的映射关系。
以话费直充订单为例,用户端订单流程的“交易成功”状态,对应运营管理端充值流程的“充值成功”状态。
2)一对多的映射关系
指系统流程A和系统流程B中,A的流程状态A1、A2,与B的流程状态B1对应,状态A1、A2与状态B1的关系,为一对多的映射关系。
如用户端订单流程的“待发货”状态,对应WMS(仓储系统)发货流程的“订单分配、拣货、补货、复核、打包”等状态,形成一对多的对应结构关系。
流程状态的映射关系,能帮助我们协调和处理不同系统流程错综复杂的状态关系。
5. 流程状态的互斥关系
流程状态的互斥关系指在同一个系统流程中,不可能同时处于两个流程状态,状态之间相互排斥,具有唯一性和排他性。
即当系统流程正处于状态A,就不会同时处于其他任何状态,其他状态必须等待,只有状态A满足流转条件后,才能流转到其他状态。
状态互斥能确保系统流程每个节点只有一个状态在进行,保证业务数据有序的执行系统流程;否则状态之间可能会发生冲突和歧义,系统流程将无法执行。
在订单流程中,有“待付款、待发货和待收货”3种状态,当用户提交订单没有付款时,订单处于“待付款”状态,意味着订单不可发货(非货到付款),用户更不可能收货。
“待付款”与“待发货、待收货”状态不会同一时间发生。每个系统流程都会有多个状态,为了强调业务当前的所处状态,弱化其他状态,状态之间必须互斥。
四、总结
流程状态是系统流程的重要组成部分,我们设计流程状态时,可从流程状态的命名、流转条件、操作功能、映射关系、互斥关系5个方面多进行思考。
作者:青木,B端产品经理;公众号:青木产品笔记
本文作者 @青木
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!