在上一篇文章中——《交互设计 | 先分解后聚合，“权限申请及审批”的产品闭环》，笔者讲解了如何利用“先分解、后聚合” 的设计策略，完成“权限申请及审批”的产品闭环。同样，在该项目中，“待办”流程也可以采用相同的策略来开展设计，下文将详细说明如何设计一套B端产品的“待办”流程。
一、什么是“待办”
一项任务或事项等待办理就是“待办”，在企业内常见的“待办”工具是JIRA，用于项目与事务的跟踪。
在本产品中，主要功能是监控“异常数据”，为了使得“异常数据”能够形成一套跟踪流程，所以需要设计一套“待办”流程：如果用户认为某条“异常数据”需要被人为处理，就将其纳入“待办”。通过实时跟踪、管理该“异常数据”的处理进度，从而形成一套完整的“异常数据”处理机制。
二、角色及任务
1. 角色
一条“待办”的流转，必定有“创建方”和“承接方”，可分别定义为：发起者、接收者。
在“待办”流转过程中，由于“接收者”是被动选中的，因此可能存在以下两种场景：
在以上两种场景中，“接收者”需要将“待办”进行二次转发，此时TA的角色可定义为“转发者”。
据此，可对“待办”流程定义三种角色：发起者、接收者、转发者。
发起者：认为某条异常数据需要被人为跟踪、处理，于是主动创建一条“待办”的用户；
接收者：承接由“发起者”发起的一条“待办”，被选择来负责处理该“待办”的用户；
转发者：当接受者承接一条“待办”后，并将其进行二次转发的用户。
2. 任务
根据以上定义的角色，可以划分出“待办”流程中的4个主要环节：
确认：发起者确认“待办”的最终处理结果。
那下面就可以根据“待办”流程的4个主要环节开展交互设计。
三、待办的状态及操作
1. 状态
在“待办”流转过程中中，根据各个环节的任务，分别定义了“待办”的4种状态：待处理、处理中、已处理、已关闭。
待处理：待办被创建之后，还未被处理的状态；
已关闭：待办被认可完成或中途废弃的状态。
2. 操作
针对不同状态下的“待办”，不同角色的操作是存在差别的，那么可以给出如下“角色——操作”对照表：
“发起者”的用户：
不管待办此时处于任何状态，均不能进行操作。
“接收者”的用户：
当待办处于“待处理”时，可以对其操作“开始处理”或“分发”，参考下文4.2章节；
当待办处于“处理中”时，可以对其操作“完成”或“分发”，参考下文4.3章节。
“转发者”的用户：
当一条待办的接收者将其“分发”出去之后，那么TA的角色就变更为“转发者”，所以不管待办此时处于任何状态，均不能进行操作。
“发起者+接收者”的用户：
当一条由“发起者”创建的待办最终流转至TA名下时，此时TA的角色既是“发起者”，也是“接收者”。
当待办处于“待处理”或“处理中”时，可以对其操作“开始处理”、“分发”或“关闭”；
当待办处于“已处理”时，参考下文4.4章节；
四、待办的流程
1. 创建
在创建过程中，“发起者”首先需要选择“接收者”，其次还需输入本条待办的“标题”和“描述”，完成后即可创建一条“待办”。
此时待办状态为：待处理。
Q：针对“接收者”，要不要允许多选？
A：按照一般的设计逻辑，可以允许选择多个“接收者”。
经济学中有一个概念叫边际效应（Marginal utility），翻译成谚语就是：一个和尚挑水喝，两个和尚抬水喝，三个和尚没水喝。
针对“待办”，当具有N个“接收者”的时候，每个“接收者”会认为自己只需要承担1/N的责任，从而产生懈怠。
那么在该产品中，我们希望每一条“待办”都具有明确的、100%责任的“接收者”，从而保证每个“接收者”都能对之负责，因此“接收者”不允许多选。
2. 处理
当“待办”被创建之后，系统会将其流转给对应的“接收者”，此时作为“接收者”的用户会收到一条系统消息（承接待办）。
通过点击“消息”，可预览待办内容，包括：待办标题、待办状态、待办描述、待办的来源用户及时间。
待办的标题、来源及时间；
待办的流程快照，也就是每个流转环节的信息：参与者、操作、时间、描述；
当前待办可以进行的操作，以“待处理”状态的待办为例，其操作有：开始处理、分发、查看异常数据详情；
待办所在产品和编号，也就是这条待办是在哪个产品中流转，以及流转的编号；
这里有两种场景需要思考：
1. 作为“接收者”的用户需要对该待办负责，那么TA可以操作“开始处理”，并输入相关描述，表示开始对此条待办进行处理。
提交之后待办的状态变更为“处理中”。
2. 作为“接收者”的用户认为此待办不属于职责范围，那么TA可以操作“分发”，并输入相关描述，以将此条待办转发给其他用户，接收到此条待办的用户则继续循环本章节“处理”的内容。
3. 完成
1. 作为“接收者”的用户已经完成待办的全部内容，那么TA可以操作“完成”，并输入相关描述，表示此条待办已经处理完成，此条待办会流转至“发起者”。
提交之后待办的状态变更为“已处理”。
2. 作为“接收者”的用户只完成了部分内容，需要第三方继续参与处理，那么TA可以操作“分发”，并输入相关描述。
以将此条待办转发给其他用户，此时待办的状态仍是“处理中”，接收到此条待办的用户则继续循环第2步“处理”。
4. 关闭
当待办的状态变更为“已处理”时，此条待办会被流转至“发起者”，作为“发起者”的用户会收到一条待办消息。
发起者可以查看待办详情，通过流程快照确认是否认可处理结果，此时有两种场景需要考虑：
1. 发起者认可处理结果，那么TA可以操作“关闭”，并输入相关描述，表示此条待办已圆满得到解决。至此，此条待办完成；
提交之后待办的状态变更为“已关闭”。
2. 发起者不认可处理结果，那么TA可以操作“分发”，并输入相关描述，继续将该待办转发给其他用户；
提交之后待办的状态变更为“待处理”，此时作为新的接收者的用户会重复上文4.2章节的内容。
五、总结
至此，已完整建立“待办”流程，用户可以在产品实现任务、事项的跟踪和处理。
作为交互设计师，策略就是：“先分解、后聚合”。
首先，明确各环节的对象以及TA所面临的任务；
其次，针对各环节的任务展开分析，将任务拆解为一套流程；
然后，根据各环节的对象和任务，在产品内找出用户触点，并以此开展交互设计；
最后，将所有环节进行聚合，形成完成的闭环设计方案。
