编辑导语:在产品设计过程中，B端系统与用户的信息交互非常重要。在这篇文章中，作者根据自己的工作经验，将告诉你如何设计B端通知提醒功能，一起来学习吧。

在产品设计的过程中，B端系统需要与用户进行交互。

网上已经有很多关于C端消息通知系统设计的文章，但是B端消息通知系统的设计和C端还是有一些区别的。

本文结合作者自身的工作经验，介绍了作者对B端系统通知提醒功能设计的思考。

在开始B端通知提醒系统的设计之前，我们有必要用UML来思考，将通知提醒抽象成一个用例，方便后续的具体功能设计。

一个完整的用例定义由参与者、前提条件、场景和后置条件组成。

为了方便大家理解，我们用做饭的用例来解释用例中的参与者、前置条件、场景和后置条件。

那么通知是否提醒这个用例参与者或业务参与者是OMS系统的用户呢？

在通知提醒的用例下，显然不是。业务主角应满足以下三个条件:

同时，我们通过一个指令、一个订单或者一个可以输入的产品信息，知道一个参与者不一定是一个活生生的人。

然后，在通知和提醒的用例中，我们发现用户只是业务工作者，他们被动地完成业务模型中主角的目标。

那么，根据上述条件，我们可以抽象出指令“通知与提醒”作为业务主角，其愿望或目的是保证业务的正常开展。

系统是为主角服务的，业务主角的确认深刻影响着功能设计的取舍，后面会详细介绍。

那么在这个用例中，如何理解前提条件、场景和后置条件呢？

提醒事件

一个提醒事件可以表述为:“当某件事满足什么条件，需要通知提醒”。

人驱动的系统，事件体现过程，事件记录结果，规则控制操作，提醒是上游用例的结果或输出。

所有的提醒事件都是围绕“物”这个实体类来进行的。

那么，B端系统都有哪些种类的提醒事件呢？

1。系统正常运行期间需要业务人员参与的事件

2。系统运行异常时需要业务人员处理的事件

3。系统服务异常时需要业务人员干预的事件

4。产品运营/客户运营手工发布的信息需要业务人员知晓

当然，还有一些操作时的即时提醒，只是用户操作案例中的一个需求点，并不包含在B端通知提醒案例中，所以本文暂不涉及。

触摸方式

一个达成的手段可以表述为:“在哪里，什么时候，怎么，谁，怎么花”。

B端系统和C端系统在触达手段上有一些区别。区别如下:

1。业务人员有许多细分的角色，需要实施差异化的延伸战略

不同的业务工作者在企业内部的角色和组织结构不同，信息焦点所属的载体也不同。

比如运营商可能不会一直盯着OMS系统，但是必须保持企业微信登录，所以可以选择使用企业微信进行信息访问。

再比如，店员可能不会一直守在收银台旁，但也不会离开商店。这时候可以用语音提醒。

不同业务的工作人员侧重点不同，店员更关注哪些订单需要拣货，运维人员更关注系统运行是否稳定，因此要对相应的角色给予不同的提醒；

2。基于SAAS的B端业务比较复杂，有几千人，需要支持触摸式的配置

使用同一系统的客户，由于业态和组织架构不同，业务人员接收信息传递载体和提醒的方式也不同，因此需要支持配置以适应成千上万的业务场景。

配置设计可参考作者文章:干货总结:我对B端系统配置功能设计的思考|人人都是产品经理(woshipm.com)

3。一切都是为了业务的正常发展

在B端系统中，B端的用户在核心业务用例中扮演业务工作者的角色，比如门店人员必须及时提货，否则系统无法完成订单履行业务。

为了满足业务的正常发展，我们可以采用以下设计思路，即使有些工具在C端产品中会被视为用户体验差:

当然，以上手段并不是绝对的，需要我们根据具体的提醒，灵活的量身定制设计思路。

那么，我们可以知道，到达B端的手段有以下特点:

4。注意平衡消息的数量

在保证提醒效果的前提下，需要平衡好消息的提醒量。有以下几种方法:

1)消息分类和降级提醒

2)消息合并提醒

那么，B端的润色手段有哪些？笔者整理了我们现行制度中的润色手段，可能不全，供大家参考:

那么在文章的最后，我给大家分享一下我在发票系统中做提醒功能时的设计过程。

1。组织业务流程

通过一个简单的流程图，可以梳理出通知和提醒的预期效果。

2。接下来可以根据标准化的文档，收集整理需求点。这里有一个我正在使用的排序模板:

3。解释提醒文本的设计:

4.当然，接下来，我们需要整理相关页面，优化交互体验。

注意功能开发完成后的交付-跟进-重复-迭代，不再赘述。

B端系统的消息通知设计和C端系统有很多共同之处。

但也有一些不同，在设计过程中要注意判断，不能生搬硬套。

本文由@kathic原创发布。每个人都是产品经理。未经许可，禁止转载。

图片来自Unsplash，基于CC0协议。