面向B端的企业产品设计，让我为之一振，久违的认证劲再次回来了！之前产品工作主要内容集中面向C端用户的大众消费品，知识体系范畴自然也与C端产品的交叉很大，而我非常珍惜这段时间的产品经历，因为确实完善了个人知识库对另一种形态（B端）产品的知识与技能。

产品设计规划之初，涉及到站内信模块时，我还是心有余悸的、保持一份谨慎的态度。在大多数人眼中，站内信可能只是一个简单的辅助功能，在一款功能全面的产品中更是显得微乎其微、不值一提。如果搁在以前我刚接触产品那会——直接一鼓作气画原型、搞文档，并不会有前瞻性的评估和规划。

我相信：每一个产品设计的背后必须被赋予某种具体的意义！

背景意义

1. 运营成本：初期版本系统（V1.0）依赖运营商短信模板直接搭建与用户之间的沟通渠道，主要通过发送短信告知用户关键时间节点上的结论性结果，而高频次地发送短信必然带来高昂的成本性支出。

2. 功能局限：运营商短信只能提供单一的固定短信模板，每一条的短信模板都必须经过运营商相关部门的审核，缺乏良好的灵活性和定制性可能性，对业务形态多样的产品尤为不利。

3. 迭代规划：产品规划过程中，周期性迭代升级是一种良好产品运营模式下的宠儿。初期产品重点关注基础和核心功能，相对结构复杂且优先级不高的站内信功能，适当地下放至后期的迭代完，过程上肯定是合理的，主次分明也有助于业务的清晰明了。

4. 业务驱动：降低运营成本固然重要，而减少产品对外部服务的依赖性也不容小觑，逐步完善产品内部功能，增强用户的产品粘性，迫使用户自然延长产品的使用/停留时间。站内信息的发送和接收，形成一个完善的产品正向反馈闭环。

产品分析

1.站内信是什么？

产品体系内的用户与用户之间、用户与产品之间、用户与管理人员之间传达信息的一种通讯方式。

2.如何设计站内信？

2.1 相关平台：[WEB]前端和后台

2.2 功能解构

业务流程：产品各个业务流程中，产生的业务流在每一个阶段都应该给予特定的交互，闭合用户行为的正向反馈。用户行为路径的关键节点，或许正是由于一个不起眼的站内信功能而点亮一款产品。

产品运营：提升产品注册用户的活跃度，增强产品的用户粘性，这两个要点应该是每一个运营人员无法忽视的关键数据指标。产品框架体系内，站内信承担着”营销工具“的重任，通过站内信向已经沉睡、静默的用户推送精心准备的高价值/大热门的内容，可以唤醒沉默用户，一定程度提升产品的活跃度。

2.3 前台功能

1.接收消息：借助站内消息通知，及时了解某个任务/行为的进程，是一种产品设计策略性的方针。接收方式有多种：

• 消息提醒功能：语音和图标
• 关键消息提醒：双重提醒

大幅缩短用户与信息之间的路径，降低满足用户需求的成本，直截了当地将结果送达至用户眼皮底下。这方面的设计下文《产品需求文档》中是有体现的，务必用心感受。

2. 打开方式：消息的呈现形式很大程度决定了——用户是否愿意查阅推送的系统消息，策略性的重度重复通知消息，只是一种策略并不是目的。

• 消息列表：站内消息仓库
• 查看详情：消息通知详情

3. 功能设计：通知、查看、删除（单一/批量）、详情，简单的操作和思路让用户自主式地优化信息，使其更加清晰地呈现在用户面前。基础功能决定产品上层结构，重视前期的基础建设，为后期完善产品细节和逻辑将会有莫大的益处。

4. 消息类别：以消息状态或消息类型划分类别，两种维度的信息归类各有权衡利弊与得失的必要。

• 消息状态：已阅读、未阅读（默认全部）
• 消息类型：系统通知、网站公告、订单消息、活动消息（其他类别）

消息类型可能存在扩容，而消息的状态相对固定/稳定，包括：已阅读、未阅读，完整诠释了事物的两个方面。良好的产品必定一开始就为后期的扩展预留了足够的空间，这也是一款优秀产品的开始。

2.4 后台功能

因果循环，深深不息！站内信本质上是——某一特定场景之下触发的某一条通知性消息。大致分为：系统消息，主要是行为信息流的关键节点类通知；运营类消息自定义手动发送运营消息，主要是运营人员依据实际的业务需求手动推送的指向性信息。

• 系统消息：由系统业务流触发不同场景下的消息提醒，极具过程性，将每一个结果融于有意义的过程中。下文PRD案例中将会详细描述不同应用场景下的站内消息。
• 人工消息：由运营人员在后台CMS内容管理直接投入到前台内容的生产和管理，俨然一副商业化营销和运营工具的样子。有时候，人恰恰才是最不可靠的！对人员的束缚就被提到了一个更高的道德层面。

2.5 跨产品线

互联网发展趋向多样，单一产品跨平台、多场景的也是大势所趋、人心所向。产品路线规划图体现着公司发展的意志和资源性投入的重要参考。跨平台产品设计存在多难点，数据、账户、存储都值得付出和努力。站内信推送就是一个典型的例子，而这一点在面向C端的产品上体现的更加明显。以下为多产品线并行的一些值得思考的价值点：

• 产品形态：WEB消息推送时，是否同步推送H5/APP移动终端？
• 推送形式:（PC/手机）产品，消息推送的形式存在差异；
• 推送时机：不同形式（WEB/H5/APP）的产品推送消息的时段都有各自的特点；
• 运营内容：消息的触发场景存在差异，即并不是所有推送站内推送都适合全平台推送；

以博客的形式直播《站内信体系》的产品逻辑设计，其实最主要的用意是回顾自己还原《站内信体系》设计的每一个脉络和细节。

下方链接为 《站内信体系》的产品需求文档（PRD）

作者：王伟（微信号：Daviiwong），@简书-互联网产品小王。专注工具和内容型产品，关注互联网金融和财经领域。从事互联网征信产品设计，喜欢看书、乐于思考。

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