在上一篇文章中——《交互设计 | 先分解后聚合，“权限申请及审批”的产品闭环》，笔者讲解了如何利用“先分解、后聚合” 的设计策略，完成“权限申请及审批”的产品闭环。同样，在该项目中，“待办”流程也可以采用相同的策略来开展设计，下文将详细说明如何设计一套B端产品的“待办”流程。

一、什么是“待办”

一项任务或事项等待办理就是“待办”，在企业内常见的“待办”工具是JIRA，用于项目与事务的跟踪。

在本产品中，主要功能是监控“异常数据”，为了使得“异常数据”能够形成一套跟踪流程，所以需要设计一套“待办”流程：如果用户认为某条“异常数据”需要被人为处理，就将其纳入“待办”。通过实时跟踪、管理该“异常数据”的处理进度，从而形成一套完整的“异常数据”处理机制。

二、角色及任务

1. 角色

一条“待办”的流转，必定有“创建方”和“承接方”，可分别定义为：发起者、接收者。

在“待办”流转过程中，由于“接收者”是被动选中的，因此可能存在以下两种场景：

1.  “接收者”无法独自处理待办，需要第三方参与处理；
2.  “接收者”认为该待办不属于职责范围，需要转移给第三方。

在以上两种场景中，“接收者”需要将“待办”进行二次转发，此时TA的角色可定义为“转发者”。

据此，可对“待办”流程定义三种角色：发起者、接收者、转发者。

1.  发起者：认为某条异常数据需要被人为跟踪、处理，于是主动创建一条“待办”的用户；
2.  接收者：承接由“发起者”发起的一条“待办”，被选择来负责处理该“待办”的用户；
3.  转发者：当接受者承接一条“待办”后，并将其进行二次转发的用户。

2. 任务

根据以上定义的角色，可以划分出“待办”流程中的4个主要环节：

1.  创建：由发起者创建一条“待办”给对应的接收者；
2.  处理：接收者开始针对“待办”进行处理；
3.  完成：接收者认为“待办”已经被处理完成；
4.  确认：发起者确认“待办”的最终处理结果。

那下面就可以根据“待办”流程的4个主要环节开展交互设计。

三、待办的状态及操作

1. 状态

在“待办”流转过程中中，根据各个环节的任务，分别定义了“待办”的4种状态：待处理、处理中、已处理、已关闭。

1.  待处理：待办被创建之后，还未被处理的状态；
2.  处理中：待办被接收者着手处理的状态；
3.  已处理：待办被接收者处理完成的状态；
4.  已关闭：待办被认可完成或中途废弃的状态。

2. 操作

针对不同状态下的“待办”，不同角色的操作是存在差别的，那么可以给出如下“角色——操作”对照表：

“发起者”的用户：

不管待办此时处于任何状态，均不能进行操作。

“接收者”的用户：

1.  当待办处于“待处理”时，可以对其操作“开始处理”或“分发”，参考下文4.2章节；
2.  当待办处于“处理中”时，可以对其操作“完成”或“分发”，参考下文4.3章节。

“转发者”的用户：

当一条待办的接收者将其“分发”出去之后，那么TA的角色就变更为“转发者”，所以不管待办此时处于任何状态，均不能进行操作。

“发起者+接收者”的用户：

当一条由“发起者”创建的待办最终流转至TA名下时，此时TA的角色既是“发起者”，也是“接收者”。

1.  当待办处于“待处理”或“处理中”时，可以对其操作“开始处理”、“分发”或“关闭”；
2.  当待办处于“已处理”时，参考下文4.4章节；

四、待办的流程

1. 创建

由发起者创建一条“待办”给对应的接收者，即为“创建”。

在创建过程中，“发起者”首先需要选择“接收者”，其次还需输入本条待办的“标题”和“描述”，完成后即可创建一条“待办”。

此时待办状态为：待处理。

Q：针对“接收者”，要不要允许多选？

A：按照一般的设计逻辑，可以允许选择多个“接收者”。

经济学中有一个概念叫边际效应（Marginal utility），翻译成谚语就是：一个和尚挑水喝，两个和尚抬水喝，三个和尚没水喝。

针对“待办”，当具有N个“接收者”的时候，每个“接收者”会认为自己只需要承担1/N的责任，从而产生懈怠。

那么在该产品中，我们希望每一条“待办”都具有明确的、100%责任的“接收者”，从而保证每个“接收者”都能对之负责，因此“接收者”不允许多选。

2. 处理

当“待办”被创建之后，系统会将其流转给对应的“接收者”，此时作为“接收者”的用户会收到一条系统消息（承接待办）。

通过点击“消息”，可预览待办内容，包括：待办标题、待办状态、待办描述、待办的来源用户及时间。

点击某条待办可查看待办详情，其中包括四部分：

1.  待办的标题、来源及时间；
2.  待办的流程快照，也就是每个流转环节的信息：参与者、操作、时间、描述；
3.  当前待办可以进行的操作，以“待处理”状态的待办为例，其操作有：开始处理、分发、查看异常数据详情；
4.  待办所在产品和编号，也就是这条待办是在哪个产品中流转，以及流转的编号；

这里有两种场景需要思考：

1. 作为“接收者”的用户需要对该待办负责，那么TA可以操作“开始处理”，并输入相关描述，表示开始对此条待办进行处理。

提交之后待办的状态变更为“处理中”。

2. 作为“接收者”的用户认为此待办不属于职责范围，那么TA可以操作“分发”，并输入相关描述，以将此条待办转发给其他用户，接收到此条待办的用户则继续循环本章节“处理”的内容。

3. 完成

当“接收者”完成待办的事项之后，有两种场景需要考虑：

1. 作为“接收者”的用户已经完成待办的全部内容，那么TA可以操作“完成”，并输入相关描述，表示此条待办已经处理完成，此条待办会流转至“发起者”。

提交之后待办的状态变更为“已处理”。

2. 作为“接收者”的用户只完成了部分内容，需要第三方继续参与处理，那么TA可以操作“分发”，并输入相关描述。

以将此条待办转发给其他用户，此时待办的状态仍是“处理中”，接收到此条待办的用户则继续循环第2步“处理”。

4. 关闭

当待办的状态变更为“已处理”时，此条待办会被流转至“发起者”，作为“发起者”的用户会收到一条待办消息。

发起者可以查看待办详情，通过流程快照确认是否认可处理结果，此时有两种场景需要考虑：

1. 发起者认可处理结果，那么TA可以操作“关闭”，并输入相关描述，表示此条待办已圆满得到解决。至此，此条待办完成；

提交之后待办的状态变更为“已关闭”。

2. 发起者不认可处理结果，那么TA可以操作“分发”，并输入相关描述，继续将该待办转发给其他用户；

提交之后待办的状态变更为“待处理”，此时作为新的接收者的用户会重复上文4.2章节的内容。

五、总结

至此，已完整建立“待办”流程，用户可以在产品实现任务、事项的跟踪和处理。

作为交互设计师，策略就是：“先分解、后聚合”。

首先，明确各环节的对象以及TA所面临的任务；

其次，针对各环节的任务展开分析，将任务拆解为一套流程；

然后，根据各环节的对象和任务，在产品内找出用户触点，并以此开展交互设计；

最后，将所有环节进行聚合，形成完成的闭环设计方案。

作者：胡欣欣，公众号：吹拉弹唱大师（ID：cltcds）

本文由@吹拉弹唱大师 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议