消息管理类的产品怎样设计？

消息系统简述

消息系统主要是为了满足是企业在想要触达用户的时候能够通过有效的方式将想要传达给用户的消息及时的传达给用户，达到原本的期望。简单来说，任何一个消息系统目的都是为了完成这样一句话：基于业务的需要，在特定的情况和指定的时间下，能够通过合适的方式将一些内容传达给到指定的人员。因此当我们在构建消息系统的时候至少需要考虑到两个角色和5个元素：

用户端的功能相对来说比较简单，主要在于如果是通过站内信的方式需要提供消息列表和消息详情，其余的方式都不需要提供具体功能。

而对于运营后台来说，主要跟大家聊一下“条件”，基于“条件”的区别会导致后台搭建不一样。条件指的是什么情况下给用户发送消息，这里面要注意的是给用户发送消息有两种，一个是基于业务规则制定的自动触发条件;另一种是人为手动的，根据自己的实际需要去制定消息推送，这种主要是提供给公司的运营人员使用。因此从整体上，我们可以进一步把消息系统的搭建细化成这样的产品架构：

触发型消息管理的产品设计

所谓触发型消息，就是这些消息发送的逻辑是先由代码进行编辑，写在指定的业务逻辑中，当用户满足相应的业务逻辑，就会触发该业务逻辑中的消息进行发送。因此需要注意的是这些消息并不是可以由人为的新增，每次必须是提需求给开发进行发布上线才能使用，我们只能针对开发好的呈现在指定列表中的各种消息进行管理。因此从设计上来说，触发型消息管理的产品原型大致会有这样的内容：

1.查询区域可以根据自己的实际业务需要提供相应的查询条件

2.消息列表中，有几个信息需要注意下

1)消息名称指的是模板名称。如关注发送通知。并不是用户看到的消息标题

2)推送人数和推送次数的区别：推送人数指累计至今该消息推送给多少人，而推送次数是该消息触发的次数。

3)注意状态为停用时，意味着该逻辑规则暂时不会被触发

4)操作中，提供了修改消息内容入口，但要注意，基本上只能修改消息的名称和发送消息的具体文案内容，其他涉及逻辑或规则的都不能随意修改

5)另外注意需要提供推送记录的入口，才能去查看每次触发推送的情况是怎样的

手动型消息管理的产品设计

手动型消息管理，大家可以理解为做成一个标准化组件。任何需要的人，根据自己的需要自己去发布消息即可，不需要预先进行业务逻辑的处理。因此自主性更高些。相较而言手动型是人为去创建一条条消息。因此在实际的产品设计时，主要是比触发型的会多一个创建相关的功能：

1.查询区域跟触发型类同就不赘述

2.创建推送时，提供了渠道和推送时间的自主选择功能

1)选择渠道要注意不同渠道输入的内容有区别，push和邮件需要输入标题和正文内容;而短信可以只输入正文内容即可

2)选择时间方面注意选择不同时间方式，细节功能设计有区别，例如定时，需要提供未来选择时间;如果是一次性则不需要选择时间，立即发布即可;如果选中周期性，则需要提供选择周期时间(如每周六，12点)

3.保存方面考虑有可能公司业务复杂，创建一次推送不是一次能搞定，因此给了草稿功能(也可以去掉)

4.消息列表中要注意两个字段的区别“消息名称”“消息标题”，消息名称是给运营人员自己查看了解之前推送的是什么;而消息标题是用户接收的消息展示的标题内容

5.操作中要注意如果消息已发送，一般只提供查看功能