编辑导语：在上一篇文章《关于异步任务的设计探索（1）》中，作者为我们解答了异步任务的设计逻辑是什么？有哪些需要注意的问题？在本篇文章中，作者又继续异步任务设计的故事，从代码层面上分享了关于异步任务的设计探索。

终于有时间归纳一下另外一个系统的问题了，之前想说的只是一个业务上的异步（关于异步任务的设计探索（1）），今天写的是真真正正的异步任务，是代码层面上的异步并非业务所要求的异步。

一、问题示例

这次的例子来源于我们做“商品导入”这个功能，先看看我们之前的做法：

• 用户可以选择导入某个平台的商品到我们的后台中，但是若想再导入需要等当前的导入任务全部结束才能进行第二次导入，而且还对商品进行了缓存，导致用户在淘宝更新了商品后，需要相隔12个小时才能再次导入更新了的商品到我们平台；

整店导入商品

• 在实践过程中，我们发现很多人停留在此页面，怕关掉此页面，导入任务会中断（虽然他关掉此页面，后台仍会继续导入）；为了处理这个问题，我们简单粗暴地加了一个提示框：

一个有三行文字的提示框?

• 我们默认会将用户的整个店铺的商品导进来，用户不能选择导什么商品，这就导致后来的两个问题：很难以导入次数去计费、消耗大量的服务器资源与成本；并且大多数用户因为导入时间等待过长而流失掉。

整店导入

总结一下以上问题：

• 导入任务不能多个开启，用户需要等待任务完成后才能再导入其他商品；
• 提示过长，并且没有能让用户知道导入进度的地方；
• 用户无法选择导入的商品，导致每次导入都消耗了大量的服务器资源和成本（有些店铺的商品达到3000件）。

二、开始思考

接下来开始思考究竟怎么样才能让这个功能变好用，“好用”可以具体分为以下几点：

• 用户控制：清晰知道进度，监控每个商品的导入情况，中断任务的权力甚至是中断某个商品导入的权力；
• 前馈指引：告诉用户这个功能是什么，可以做什么，功能有什么条件限制等等；
• 反馈提醒：执行导入任务后，让用户有安全感地关闭当前页面，具体为让用户知道他可以随时随地回来查看这个任务，这个任务完成时会立即通知到用户。

于是第一点：让用户能够选择导入什么商品（当然这个需要接口支持），用户用链接采集时并非立即执行导入任务，而是先采集好店铺的所有商品（未开始采集商品详情），让用户去选择需要导入的商品，当然也需要给出方便的交互让用户可以一键选择全部商品来进行导入（或者用户第一次导入时，不需要选择直接导入整店的商品）。

选择平台

采集店铺商品后，可以选择导入什么商品

执行导入后，并不在当前页显示导入的状态或结果，引入另一个页面来放置任务，所以引入了另一个专门放置导入任务的页面。

一个专门放置任务的页面，详情可以查看每个任务里商品导入的情况

但这样会引入一个新的问题，由于导入的页面与任务的页面是割裂的，为了不打破用户的“心流”，我们需要在用户导入完毕后自然引导用户进入任务查看，即“反馈提示”。

如下图：导入后告诉用户已经开始，并提供快捷入口让用户进入查看。

一个带有快捷入口的提示

当用户点击取消时，利用气泡框轻度提示用户可以从此入口查看任务：

气泡框的轻度提示

因为用户已经点了【取消】，说明用户：有其他流程需要处理；已经非常熟悉导入流程，不需要查看。所以此时为了不打扰用户，做一个轻度提示即可（甚至可以只在用户第一次导入时提示）。

导入完毕后，需要及时提醒用户导入任务已完成，这里有几种方法，由于用户不一定时刻在电脑前，所以可以取其中之一或全部用上。

• 短信：若用户注册时需要提供手机号，这是开发成本最低的一种做法，也是最快速，缺点是金钱成本会比较高；
• 公众号：若用户使用微信登录，并且关注公众号，可以调用公众号-消息模版能力，优点是0金钱成本，还能顺便提高公众号的粉丝，缺点是需要开发，并且消息模版只能使用微信的；
• 网页端直接弹出提示：优点是自己可以控制文案和样式，并且能够直接跳转查看对应的任务，缺点是需要开发通讯类功能（socks之类），用户离开后就收不到消息。

一个弹出通知

所以要与开发团队权衡好利弊，进行取舍。

三、总结

当初将异步的任务也设计成同步的交互，后来发现一团糟；经过几次与团队的探讨，看别人的文章与设计后，总结出几点：

1. 碰到异步的任务时，最好能在代码层面了解它是怎么运作的，包括但不限于调用了什么接口、接口调用的时长（这个决定了是否要同步处理还是异步处理）、接口返回的错误、任务是按照队列去执行还是能够并发执行；业务层面了解它需要的角色、流程、流程的时长、流程涉及到的场景。
2. 不要企图仅用文案去解决用户的不安以及等待，这个是我们犯过最大的错；以为提示可以解决一切；但用户会跟着流程走，流程设计出错的时候，用户会非常无助地停留在原地。
3. 多与开发沟通，很多时候，设计貌似只是产品或UI的事情，开发只是执行，但在我执行过的项目中，好的项目往往是开发一同参与设计部分的（并不是说执行，而是给出建议），因为有些方案是需要开发人员的知识才能想到（具体可以参考“增长黑客”一书中的案例）。

本文由 @蔡包 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议