























在产品设计过程中,区分同步和异步任务对于提供流畅的用户体验至关重要。本文通过一个客户签约业务的案例,分析了在设计异步任务时常见的错误,并提出了改进方案。

这是一个客户签约的业务,流程如下:
自己分析了一下之前的错误,发现虽然分析了整体的业务流程、角色的权限与上下游,但没有去分析这个任务是同步还是异步的,导致与开发同学也吵了很久,错误分析如下:
虽然我们有一整队实施团队去帮助集团中的所有使用者去了解业务,但作为一个产品,还是必须保持敬畏之心对待用户才可以。
什么是异步呢?
对于程序来说就是一个请求发出去了,但系统不会立刻处理,而是放在队列里,系统会按照队列方式去处理它,或者处理的时间非常长也可以归为异步任务。
反过来同步任务就是请求递交,几乎即时就有反馈。
以前我总是同步、异步的任务都用同样的设计,单纯地通过反馈弹窗告诉用户这个任务大概需要等多久,很多用户就傻傻在那里等着。
于是今天,我按照上边归类的问题,修改了原型:

为了让发起人知道总体的流程,提交签约之后,我们需要反馈一个结果且告诉发起人整体的流程,便于发起人与经办人交接(由于我们接入了企业微信的通知,【催一下】可以直接在企业微信通知经办人)。

第二个问题需要告诉发起人这个任务需要等待,这时候我们需要引入站内消息功能,并且告知用户可在哪里看到查看审核结果的通知。

若这个任务是比较重要的,可以考虑单独列一个任务列表,这样任务完成时,用户可立即知道。

最后,我们需要引导发起人先去完成其他任务,就要在结果页中对按钮做相关业务的跳转,改一下:

总结了一下,异步任务的设计逻辑:
另外之前做异步任务的设计时发现一个很严重的问题:用户不敢关闭当前窗口或切换到其它地方,他会很害怕任务会被中断。
所以我们要清楚地告知用户:“这个任务需要等待,有结果时我们会及时通知你,你可以进行其它业务的操作”
未完待续,后续文章请大家持续关注。
本文由 @蔡包 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。