从0到1,一套B端产品的待办流程设计实践

一、什么是“待办”

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

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

从0到1,一套B端产品的待办流程设计实践

二、角色及任务

1. 角色

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

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

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

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

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

从0到1,一套B端产品的待办流程设计实践

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

2. 任务

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

从0到1,一套B端产品的待办流程设计实践

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

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

三、待办的状态及操作

1. 状态

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

从0到1,一套B端产品的待办流程设计实践

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

2. 操作

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

从0到1,一套B端产品的待办流程设计实践

“发起者”的用户:

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

“接收者”的用户:

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

“转发者”的用户:

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

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

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

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

四、待办的流程

1. 创建

从0到1,一套B端产品的待办流程设计实践

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

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

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

从0到1,一套B端产品的待办流程设计实践

Q:针对“接收者”,要不要允许多选?

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

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

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

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

2. 处理

从0到1,一套B端产品的待办流程设计实践

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

从0到1,一套B端产品的待办流程设计实践

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

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

从0到1,一套B端产品的待办流程设计实践

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

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

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

从0到1,一套B端产品的待办流程设计实践

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

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

从0到1,一套B端产品的待办流程设计实践

3. 完成

从0到1,一套B端产品的待办流程设计实践

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

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

从0到1,一套B端产品的待办流程设计实践

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

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

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

从0到1,一套B端产品的待办流程设计实践

4. 关闭

从0到1,一套B端产品的待办流程设计实践

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

从0到1,一套B端产品的待办流程设计实践

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

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

从0到1,一套B端产品的待办流程设计实践

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

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

从0到1,一套B端产品的待办流程设计实践

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

五、总结

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

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

从0到1,一套B端产品的待办流程设计实践

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

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

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

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