从到如何设计一套端产品的待办流程

　　在上一篇文章中——《交互设计 | 先分解后聚合，＂权限申请及审批＂的产品闭环》，笔者讲解了如何利用＂先分解、后聚合＂ 的设计策略，完成＂权限申请及审批＂的产品闭环。同样，在该项目中，＂待办＂流程也可以采用相同的策略来开展设计，下文将详细说明如何设计一套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所面临的任务；
　　其次，针对各环节的任务展开分析，将任务拆解为一套流程；
　　然后，根据各环节的对象和任务，在产品内找出用户触点，并以此开展交互设计；
　　最后，将所有环节进行聚合，形成完成的闭环设计方案。