站内信需求背景及需求分析的全过程

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

zhanneixing

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

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

背景意义

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),@简书-互联网产品小王。专注工具和内容型产品,关注互联网金融和财经领域。从事互联网征信产品设计,喜欢看书、乐于思考。

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

您的赞赏,是对我创作的最大鼓励。
1人打赏

评论( 0

登录后参与评论
加载中