站内信设计思路

　　站内信可以实现两个基本功能：点到点的消息传送：用户给用户发送站内信，管理员给用户发送站内信；点到面的消息传送：管理员给用户群发消息。
　　消息通知的几种形式
　　消息通知，通常来说包括以下几种形式：
　　形式一：系统PUSH，极高的曝光率极低的打开率
　　IM消息提醒、评论互动、运营通常采用这一方式。IM消息提醒如微信、QQ、钉钉的聊天消息，对及时性的要求极高。互动评论常见于社交类应用，比如微博。
　　用户对这两者的容忍度相对较高，且IM消息评论互动。
　　系统PUSH的优点在于它的到达率和曝光率，只要没有被关闭通知权限，几乎能够100让用户看见。
　　这样的后果是打开率极低，并且一旦频繁推送，就面临着被用户关闭通知权限、甚至直接被卸载的后果。
　　形式二：应用内弹窗，重要的版本更新提示通常采用这种方式
　　京东的版本更新提示，饿了么每天首次打开时的红包，Uber的活动推广都会采用应用内弹窗。应用内弹窗的曝光率极高，但破坏性也极强，因为它打断了用户的正常使用流程，并且必须按关闭确认才能关掉弹窗（更优雅的交互方式是点击屏幕空白处）。
　　方式三：站内信通知，取决产品本身的架构，通常由官方账号发出
　　站内信通知，是更为普遍的一种活动运营方式。
　　而app的日常运营，也是靠该账号推送内容，比如网易云音乐的小秘书、知乎的知乎团队知乎Live团队。
　　方式四：小红点浅灰色文字，通常标记在入口处
　　在功能入口上加小红点，在列表式的功能入口上加小红点右侧浅灰色文字，是更常见的一种方式，比如微信默认朋友后有更新时会在发现栏上出现红点提示，以及微信读书的版本更新会在相应的入口处都添加小红点。
　　其他：手机短信通知、邮件订阅
　　这两种方式不再赘述。
　　本文重点阐述站内信的前后端设计逻辑。
　　什么是站内信
　　站内信不同于电子邮件，电子邮件通过专门的邮件服务器发送、保存，而站内信是系统内的消息，其实就是通过数据库插入记录来实现的。站内信有两个基本功能：
　　点到点的消息传送。用户给用户发送站内信，管理员给用户发送站内信。
　　点到面的消息传送。管理员给用户（指定满足某一条件的用户群）群发消息。
　　站内信怎么设计
　　1。站内信
　　关于用户的资产信息，商品物流等动态更新通知。
　　如交易、物流、收发货等通知，一方面用户能及时知晓商品的第一动向，另外也能在一定程度上较少企业的短信成本；
　　如积分变动、优惠券到期前通知，凸显用户资产信息重要性的同时，又唤醒沉默用户进行消费优惠券，从而促进订单转化。
　　一般用户只有阅读和删除权限；
　　发送是由系统设置的触发条件或者运营人员在用户营销时手动发送；
　　只能用户自己看到；
　　在WEB端在个人中心一般为站内信形式；移动端个人中心页面的消息图标并附带未读的条数；
　　站内信内容不多，点击标题下拉收缩展开。
　　2。公告
　　应用场景较广，便捷性较强，当企业存在公告类内容，可及时进行全量或定量推送，让平台内的用户知悉。
　　一般放在网站首页顶部区域，
　　游客模式下也可看；
　　只有网站管理员才可编辑删除；
　　内容较多，点击跳转新页面。
　　3。设计思路
　　我们希望用户收到个性化的营销信息，唤醒沉默用户，而有的信息我们希望有游客也可以看到，便于未注册用户的注册转化。
　　笔者在互金公司做产品狗时，平台的运营活动较多，每个月有一固定大活动，两三个小活动，并针对这些活动发布站内活动通告，针对待收少于的用户做单独的活动推送，可否将两者的通知渠道整合一下，优化下空间资源。
　　之前在首页右侧有公告图标，点击打开是公告列表，在个人中心页面右侧有个人消息，点击为个人的信息变动情况。
　　笔者在改版过程中，将公告通知模块与站内信模块设计在一起。
　　消息中心板块
　　顶部导航栏公告与站内信在导航栏页面，点击相互切换；
　　点击通知消息，为企业公告消息，可二级菜单可具体细分为公告与活动消息；
　　底板标签栏为操作栏，在公告页面，都为禁用状态，只有管理员才可删除公告信息；
　　顶部点击我的消息，为个人信息页面；
　　必须要登录状态，未登录则登录页面；
　　底部标签栏三个操作按钮都可点击状态：
　　小红点表示未读，阅读之后，小红点消失，点击标题栏，可展开查看具体内容（如下图）：
　　选中某消息，点击底部标签栏已读或者删除，可进行对应的删除或者已查看操作。
　　4。后台设计
　　后台在设计时，功能要区分开。
　　1。公告或者重大通知，一般篇幅较大，类似发布文章功能，也可用文章模块配置发送，都为管理员发布，某些内容需要事前审核；
　　点击新增通知，进行公告内容的编写发布：
　　2。站内信发送功能由系统触发后自动发送，或者管理员手动发送，内容较短；
　　一般为系统定好的规则执行，当需单独对某用户发送时，可点击手动添加按钮，按级别，类型或者其他条件筛选，并填写发送内容推送；