实践分享：带你设计消息管理后台

消息触达用户的手段有很多种，主流的手段包含：短信消息、应用的系统消息以及操作系统的通知消息。关于这些消息的前端展现、推送原理等相关内容已经有很多人讲解过，但鲜少有讲解后台消息管理模块的内容，在这里希望能与大家分享一些设计管理后台消息管理模块的心得与体会。短信消息、Android或iOS系统通知通常大部分产品都会借助于第三方实现，这里仅说明App应用的系统消息。

系统消息

了解系统消息发送的内容

在设计消息管理模块之前我们先要弄清楚，系统消息发送的内容主要有哪些，通过观察市场上的应用产品，我们不难发现，系统消息发送的内容主要包含：活动宣传、平台公告、广告以及一些系统站内信。系统站内信通常按照各产品的业务逻辑规则由程序通过接口自动触发，无需通过管理后台进行人为的干预，故不在本文的讨论范围之内。这里需要和大家讲解的是前3类消息是如何通过管理后台推送到应用端的。

创建系统消息，设定发送规则

通过观察App应用，我们可以看出通常一条系统消息通常包含了标题、内容、时间，有些消息还会有页面跳转。那么我们在设计系统消息创建的时候就有了一个大概的方向了，站在操作人员的角度来思考，我们还应该知道消息的发送时间、发送给谁。到这里我们心中已经有了清晰的思路，下面我们在逐个分析各元素的设计。

消息的标题与内容是需要运营人员编辑的，所以后台只需提供文本输入框。消息的标题通常一般不会太长，建议控制在20字以内，消息内容控制在50字以内。文字长短的控制既可以在App应用限制，也可以在管理后台限制，前后端的开发同事做好沟通协商就可以了。但一般建议在管理后台编辑消息内容的时候，进行限制。当编辑的文字超过上限时，进行提示并禁止用户继续输入。在这里，可能会有一点体验不太好的地方，通常编辑消息时，很少有人会去刻意数，输入了多少字。这时候如果我们设计的时候加入一个计数功能，告诉用户输入了多少字，还可以输入多少字，这样就显得很贴心了，编辑消息的运营同学也会对你有好感的。任何有字数限制的地方，都可以加入这个功能。

有些消息通常我们还要加入跳转链接，因此我们需要一个输入URL地址的文本框，这项内容只能作为选填项，不能作为创建消息的强制要求。

接下来，我们来解决消息发给谁？我们不仅需要满足默认的给全网用户发送，还需要能够支持给指定的批量用户发送，所以创建消息的时候，需要提供账号导入功能。导入文件的格式通常为文本格式，为了防止后台运营编辑人员导入错误格式，可以考虑在后台加入一个模板下载。操作人员直接在模板内录入账号。

最后，我们需要考虑这条消息的发送时间，运营的同学会有两种需求，紧急类的可能会选择立即发送，其他非紧急或者有固定要求的可以通过一个时间选择控件来让编辑人员设置定时发送，日历控件的时间颗粒度可以做到年月日时分秒，这样的设定也比较灵活。定时发送的消息将进入程序待发送队列中，到时间后系统自动下发消息。任何未发送的定时消息，都可以手动修改发送时间或选择手动立即发送。

创建消息

消息列表的显示、查询

每一条消息内容需要显示标题、内容、发送状态（未发送、已发送）、发送时间。未发送的消息应排列在已发送的上方，同一状态内的消息按照发送时间倒序排列。消息的操作包含了修改、删除、发布，不支持批量操作，只能逐个操作。需要说明的是处于未发送状态的消息可以进行任何操作，消息一旦发送则不允许进行修改和删除。用户一旦发现已查看的消息可以被系统随意修改和删除，会给用户留下不靠谱的印象，用户对平台的信任感也会随之降低。

当消息列表的消息越来越多的时候，我们想快速找到目标内容则会显得比较困难。所以需要提供一些快速查找筛选的条件，可以提供按照消息的发送状态、发送时间段以及消息标题的方式进行组合查询，这样可以快速方便的查找到历史消息。

消息列表

最后的寄语

本文在讲解消息管理模块的设计时，未考虑各公司的一些工作流程，比如消息发布之前有些公司会有一些线上审核流程，为了聚焦说明产品自身的规则与逻辑，所以在讲解时，过滤掉了一些事物性、工作流程类的干扰因素。最后，希望本文的讲解能够帮助到大家亦或打开设计时的思路，也算对自己有一个交代。

最后在文末给大家奉献上源文件：链接：https://pan.baidu.com/s/1dEYsywL 密码：p9f4