一、前言

最近Mr汤进er在学习PRD的写作。直接的感触就是:写PRD是一个技术活,也是一个细心活。PRD的主要阅览用户就是开发工程师,为了能够和开放人员进行高效的沟通,一份优秀的PRD文档应该满足的基本要求包括:完整、准确、清晰、简洁和稳定。其中”完整”便是指考虑周全没有遗漏。完整的功能描述和用例,不但可以方便开发工程师快速了解完整的功能需求,同时也为产品上线前的产品测试提供必要的参考。完整的产品功能描述主要包括两方面:功能点无遗漏功能描述完整

为了方便自己项目中进行相关功能点及其描述自查,Mr汤进er整理了一套针对应用开发的产品功能点及其描述自查清单。个人感觉,这个自查清单对于四类人群都是有帮助的:

1、产品经理:可以通过产品功能描述自查清单来系统的梳理产品功能点和描述,PRD可以帮助产品经理更加透彻和完整的梳理产品,同时,产品经理可以通过PRD和其他人员进行高效的沟通。

2、交互设计师:可以通过功能点及其描述自查来检查自己的交互稿是否遗漏特殊情况、异常情况、极限情况等等

3、开发工程师:可以通过功能点及其描述自查清单来检查自己的程序开发是否符合PRD中的相关要求。

4、测试工程师:可以将PRD中的功能描述和用例转化为测试用例的一部分,进行产品可用性测试。

《 PRD怎么写 》观后笔记

MRD(市场需求文档):市场需求、市场机遇、产品概念

PRD表现形式:word、wiki、原型、PPT、图片

1.概要

文档变更记录(版本迭代、版块及功能说明、记录人等,其实就是简化版的功能需求清单)、全局规则说明(升级逻辑、异常逻辑、交互说明、输入限制…)、名词解释(积分、金币、白银会员…)

2.业务说明

产品功能主框架(功能/信息结构图、业务结构图/流程图、一级页面流转图)、权限说明表(角色权限、数据权限、功能权限)、页面交互/功能模块元素构成、规则说明

3.原型图

各页面的线框图、基本的交互形式、文本注释(缺省状态、字段名称、流程说明、等待时长说明…)

4.非功能性需求

会员登陆 1

二、原则

在整理自查清单之前,我自己先梳理了几条自查原则或者叫做逻辑(建议在自查前先用Xmind等软件梳理下自查逻辑
):

1、先总体,再细分:如果拿一棵大树举例,应该是按照树干→树枝→树叶的顺序去检查产品功能点,可以结合产品功能架构图来进行主要功能点的检查,在主要功能点完整的基础之上,再深入到主要功能点下的细节功能进行自查。

2、有顺序,依次检查:这个和撰写PRD中的功能点和描述是一致的,可以依据PRD功能描述撰写的标准综合运用以下顺序进行自查:

1)产品功能点需求:用户需求→后台需求(数据监控等)

2)功能在系统中的位置:前台界面→用户管理后台(个人中心)→官方管理后台;

3)业务流程:步骤1→步骤2→步骤3→步骤3.1→步骤3.2……

4)功能主次关系:主要功能(场景or流程)→次要功能(场景or流程);

5)功能点在页面布局中的位置:从上→下、从左→右;

6)按照软件状态:基本状态→特殊状态→异常状态;

3、随时关注,及时更新:很多遗漏的点不是自查一遍就可以检查出来的,说不定某个时间,就突然想起了某一个功能点的遗漏。同时PRD作为交流沟通的工具之一,需要跟进交流的结果,因此我们要随时关注,并做到及时更新。但别忘了PRD的稳定性哦,最好在正式交付其他人员时,完成功能点及其描述的梳理。

地理位置获取、Push推送机制、敏感词过滤、CDN缓存策略、本地文件存放策略…

之前做项目都是敏捷开发,只在交互稿旁边贴上交互说明,项目发展比较稳定后才慢慢补上PRD,写完后发现自己以前有些真的没考虑全面,写文档也是自我反省的过程。最近专门去学习整理了很多大佬的文章,为以后写PRD提供速查清单。

三、自查清单

Mr汤进er自己先用Xmind绘制了一张清单导图,详细清单列表见下方

PRD中产品功能点及其描述自查清单,绘制@Mr汤进er

文档头


命名:[PRD]+产品名+产品版本 【PRD】Pruduct Hunt v1.0.1

规则: 文档版本+修订日期+修订内容+修订人

目录:建议用Word自动生成目录


1文档综述

1 用户体验自查:

这部分主要注意自查功能框架、业务流程和用户界面布局(如菜单、对话框、窗口和其它可规控件)以及页面内容描述等等是否完整。

产品概述


定义目标

  • 产品背景(why build it)

生 态(市场环境是怎么样、同类竞品怎么样)+
需求可靠性(数据验证比如dropbox最初没有产品只是通过市场验证)+
价值(对其他产品有什么帮助,如何变现)+ 成本(技术风险低)

会员登陆 2

屏幕快照 2017-07-13 上午9.49.41.png

  • 用户定位(who cares)

会员登陆 3

屏幕快照 2017-07-13 上午9.46.50.png

  • 产品目标(so what)

会员登陆 4

屏幕快照 2017-07-13 上午9.56.24.png


1.1PRD输出环境

交代文档和产品信息,方便为迭代做标记。
• 文档状态、产品版本、文档编号、编写人、编写日期。

会员登陆 5

1.1 流程和页面布局

功能性需求


  • 脑图

    会员登陆 6

    屏幕快照 2017-07-13 上午9.58.06.png

  • 流程图

会员登陆 7

屏幕快照 2017-07-13 上午10.01.29.png

  • 功能总表_优先级

会员登陆 8

屏幕快照 2017-07-13 上午10.04.21.png

  • 功能详情

会员登陆 9

屏幕快照 2017-07-13 上午10.07.16.png

用户界面:初期原型稿后期UI稿

会员登陆 10

屏幕快照 2017-07-13 上午10.10.04.png

界面描述:接口里面要有那些字段,哪些可以点,跳转关系

会员登陆 11

屏幕快照 2017-07-13 上午10.13.40.png

  • 说明

1.2修订记录

方便读者快速定位每次迭代的修改点。
• 版本号、修订人、修订日期、修订描述。

会员登陆 12

1.1.1 基本状态:

1)功能框架和流程的功能点是否完整?特别是注意流程中的主导航常驻or页面返回,是否是从哪来回哪去?不要出现一个页面点击某个BUTTON不知道去哪的问题!可以请交互设计师协同自查;

2)流程描述是否完整?这部分也可以请交互设计师协调完成,比如A→B页面跳转是否描述完整(包括交互触发方式:单击or长按or滑动;触发区域:整条Button
or
Button的某个区域;触发前中后状态:加载时间、动效、中间状态等等);再比如是否有不可点击的效果,如:你的按钮此时处于不可用状态,那么一定要灰掉,或者拿掉按钮,否则会给用户误导;

3)页面布局是否完整?比如页面标题栏、导航栏等否缺失?页面反馈(弹窗or加载状态进度提示等)是否缺失;

非功能需求


会员登陆 13

屏幕快照 2017-07-13 上午10.22.58.png

  • 统计需求

会员登陆 14

屏幕快照 2017-07-13 上午10.51.01.png

老板的需求:主功能 价值(预期收益)
对策: 结合功能的重要程序,而不仅仅是页面顺序,收益指标加入产品目标

设计师的需求:单页复杂度,页面数,风格要求
对策:在没有UI的情况下使用原型图作为用户界面
异常状态要有明确定义
对风格或者设计有任何特殊需求都应在界面描述中备注栏注明

PS:做原型图,尽量不用动态面板做到一页里面

开发的需求:。。。
对策:精简文字,用图与表格结构化描述需求
能用伪代码更好
多琢磨,想清楚再写
多考虑异常流程

测试:自己要写测试用例
对策:完善用户用例的非基本流程
开发过程中更新PRD
与测试仪器一起制定一份PRD描述自查(包含每个页面无网情况下什么样)


1.3文档介绍

1.1.2 特殊和异常状态:

1)特殊流程是否缺失?比如登陆流程中是否缺失忘记登陆密码的流程;启动页和用户引导页等;

2)页面布局是否考虑横竖屏问题

3)页面布局是否考虑不同屏幕尺寸自适应问题

4)不同模式下页面情况说明:夜间模式?编辑模式?无图模式?等

补充


  • 维护PRD,及时通知他人
  • 用原型代替PRD(容易漏特殊情况)

1.3.1目的

  • 前期有助查漏补缺。原型图有利于走通流程,可视化展现需求点,而产品文档更加关注产品细节和规则,其实我觉得产品一体化文档的可读性更高,但是人们大多认为写在原型上的产品文档不叫PRD······
  • 中期降低沟通成本。产品经理将自己的要求写在文档中,对于多方合作的项目,可以大大降低沟通成本。
  • 后期方便工作存档。在工作交接中,一份完整的产品文档可以让接手的人快速全面了解项目。

1.2  内容自查

1.3.2范围

这篇文档为谁而写,不同角色想从文档中获取什么信息,则是需求文档要展现的内容。

  • 交互设计师:设计交互细节,评估用户体验。

  • UI设计师:设计具体样式,规范界面设计。

  • 项目经理:安排开发人员,进行开发排期。

  • 开发:明确开发内容,评估工作量。

  • 测试:建立测试用例,验收产品依据

1.2.1 基本状态:

1)描述内容是静态or动态数据调用?如静态的标题title,动态的文本内容调用等;

2)内容描述是否完整?顶部标题、按钮里的文字等;文本是否错误等;

3)内容加载方式描述是否完整?本地缓存or刷新加载网络新内容等;

4)输入框内容描述是否完整?是否有初始内容?输入后是否有联系功能(比如搜索);

1.3.3名词解释

对于产品中专业名词的解释,方便大家沟通中名词的统一,产品经理没有定义,大家各说各的容易混淆。而且对名词解释方便大家理解业务,图文并茂最佳。可以戳此示例查看

1.2.2 特殊和异常状态:

考虑等价、边界、负面、异常或非法等情况

1)数据内容为空如何处理?是否支持离线功能?是否有空数据界面设计,引导用户去执行操作;

2)内容长度是否有限制?比如内容展示是否限制字数,点击查看更多?昵称描述不得超出多少字?密码不得低于多少字符等等;

3)内容违禁如何处理?敏感词、违禁内容(如:涉及版权、专利、隐私等图片)等如何处理;

4)数据内容过期or删除or违禁后如何展示?比如某内容发布后因为违禁被编辑删除,那么用户再次点击后怎么展示等;

5)用户内容输入是否描述完整?比如输入框输入空格、特殊字符如何处理?用户输入是否保留历史记录?等等;

2产品概述

2  账号状态及用户权限自查

用户注册和账号管理功能都会涉及到用户不同登陆状态(登陆、非登陆、账号异常、账号被冻结等)和用户等级和权限(会员和非会员、付费和非付费用户等),因此要说明清楚不同账号状态及用户权限下显示的内容和功能。

2.1产品介绍

对产品进行介绍,也是让各方了解我们产品的整体形态以及未来规划。

2.1.1 基本状态:

1)不同账号状态说明:登陆状态、非登陆状态不同情况是否说明完整?

2)不同用户等级和权限说明:不同等级用户有哪些权限?在页面展示上有什么不同?

3)不同账号状态切换时是否有特殊展示?

2.2功能架构图

基于产品的逻辑及表现形式,结构化表现产品各个功能模块的 一种示意图。

2.1.2 特殊和异常状态:

1)是否说明清楚一个账号多终端登陆问题?是否允许多终端登陆同一账号?一般根据MTOP的现有规则,一个帐户只允许登录一台机器。检查一个帐户登录多台手机时,原手机里的用户需要被踢出,是否给予用户友好提示?

2)是否考虑了多账号切换问题?是否保留历史账号?

3)是否支持第三方账号登陆?登陆后如何绑定自有账号?

2.3信息架构图

用于表现产品的所有信息内容及内容分类的一种示意图。

3  硬件环境需求自查:

不同的终端水平涉及到包括硬件特性、网络状态等情况,需要在PRD中考虑清晰。

2.4交互流程图

表达是执行逻辑的路径,通俗地将是当用户点击某个按钮之后,程序执行命令的顺序。

3.1  硬件特性需求说明

1)横竖屏是否需要锁屏?

2)不同分辨率是否要适配?如何适配?

3)是否调用手机物理按键?什么情况下调用?如何调用?

4)SD卡问题,文件导入本地时,没有SD卡、SD卡储存已满、储存位置等情况是否考虑并备注?

2.5业务流程图

一种描述管理系统内各单位、人员之间的业务关系,作业顺序和管理信息流向的示意图。

3.2 网络状态说明

1) 无网络时,显示什么内容?执行需要网络的操作,是否给予用户友好提示?

2)
在网络信号不好时,有无超时限制?是否说明了如何给予用户反馈?是否引导用户执行其他操作或退出?

3)缓存问题如何处理?什么情况下调用缓存?

2.6功能模块

会员登陆 15

3.3 服务器宕机或出现404、502等情况说明

后台服务牵涉到DNS、空间服务商的情况下会影响其稳定性,如:当出现域名解析故障时,你对后台API的请求很可能就会出现404错误,抛出异常。如何处理这些异常?

2.7全局说明

• 功能权限:登录、未登录;
• 状态:未选中、悬停、选中、幽灵;
• 反馈:
(1)提示信息:成功、失败、警告、通知、帮助;
(2)过程反馈:加载状态进度反馈、录入反馈;
(3)反馈方式:顶部全局提示反馈、对话框、气泡卡片、文字提示、徽标数;
(4)反馈效果:反馈动画、反馈时间;

4  后台交互及管理需求自查

后台交互和管理需求涉及到消息推送、数据更新方式、软件权限和后台监管等方面的需求。

3详细功能

4.1  PUSH消息说明

是否说明必要的push消息业务规则?什么情况需要push消息?push什么内容等等 

3.1页面介绍

• 用户场景
• 功能描述
• 优先级
• 输入/前置条件:不同方式和不同身份进入该页面
• 需求描述
• 输出/后置条件:不同方式和不同身份退出该页面
• 补充说明

会员登陆 16

4.2  数据更新说明

1)需要说明哪些地方需要用户手动刷新?哪些地方需要自动刷新?哪些地方是手动+自动刷新?

2) 说明哪些地方从后台切换回前台时需要进行数据更新?

3) 需要说明哪些内容需要实时更新,哪些需要定时更新?

4) 说明数据展示部分的处理逻辑,是每次从服务端请求,还是有缓存到本地?

3.2处理规则

4.3  软件权限及安全性:

1)软件权限说明是否完整?什么功能,在什么情况下,需要调用什么样的权限?位置or通讯录or联网or照片等等

2)数据安全性说明是否完整?输人的密码将不以明文形式进行显示,备份应该加密,
恢复数据应考虑恢复过程的异常通讯中断等

3)交叉事件安全性说明是否完整?在运行其软件过程中,
如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时,
是否能暂停程序,优先处理通信, 并在处理完毕后能正常恢复软件,
继续其原来的功能

3.2.1显示机制

• 内容来源:产品中某界面、标准字典表(需要产品或需求方提供)
• 内容数量
• 数据极限值:超出服务器性能的最大条数、影响展示效果的最大条数
• 文字极限值:换行、省略
• 展示范围:全量展示、分页显示
• 状态显示:空值、默认
• 计量单位:时间单位、货币单位

4.4 后台数据监控及管理需求:

1)后台有哪些数据检测点?需要监控哪些数据?

2)后台有哪些功能点,为前端提供哪些数据内容?敏感词、违禁内容如何屏蔽?等等

3)如何进行内容推荐和排序等等

3.2.2排序机制

• 排序规则:综合、按热度、按时间、按价格、按销量、按评分、按距离
• 排序更新频率:实时更新、定时更新

四、结语

PRD写作是一个细心的活,确保内容描述的完整性,有利于产品经理自己梳理产品本身,同时也有利于团队合作与沟通。产品功能点及其描述自查是为了保证内容描述的完整性。当然Mr汤进er整理的这套自查清单肯定是不够完整的,也不是普适的。重要的是,大家需要有这样的意识、细心和一定的标准去做自查。虽然看似增加了工作量,但Mr汤进er认为,事实上这样会大大减少时间成本,特别是在大团队多人或异地协调工作的情况下。欢迎大家针对“PRD”与@Mr汤进er交流讨论(微信公共号:chuangshe_space,个人博客:www.tangjinweb.com,知乎or简书or微博:@Mr汤进er),共同进步。

本文为原创,允许转载,但请注明作者信息和出处:

作者:Mr汤进er , 微信公共号“创设空间”:chuangshe_space

并附带本文简书链接:

原创产品文章持续更新ing,订阅文章推送,请微信关注:chuangshe_space

3.2.3输入机制

• 数据类型:布尔型、数值型、文本型
• 状态显示:空值、默认值
• 是否必填
• 是否限制内容:数字、字母、特殊符号
• 是否限制长度
• 是否校验唯一性
• 是否限制多次提交
• 刷新数据是否还在

3.2.4加载机制

• 加载数量
• 加载方式:手动加载、自动加载(再次进入该页面、定时加载)
• 状态显示:默认(整个页面、文字图片视频)、加载中、加载后、加载不出更多

3.2.5缓存机制

• 缓存对象
• 缓存数量
• 缓存位置:客户端、服务端
• 清理缓存:手动清理、自动清理

3.2.6推送机制

• 推送对象
• 推送内容
• 推送频率:实时推送、定时推送
• 点击推送跳转:正常跳转、异常跳转(页面不存在、页面无法访问)

3.2.7搜索机制

• 搜索对象:全局、部分字段
• 搜索精度:精确搜索、模糊搜索
• 搜索效率:实时搜索、点击搜索
• 支持缩写:拼音首字母、大小写

3.2.8删除机制

• 删除方式:物理删除(数据库层面彻底删除)、逻辑删除(表现层暂时删除)
• 依赖条件:前置条件、后置影响

3.3数据规则

• 取数规则:数据库表、所取字段、关联方式、主键、索引
• 时间规则:统计范围
• 计算规则:字段、计算公式

3.4操作控件

3.4.1触发源

• 触发时机:何时显示、何时隐藏
• 触发区域
• 触发形式:点击、拖动
• 触发频率

3.4.2触发时

• 加载
• 读取
• 缓冲

3.4.3触发后

• 操作进度显示
• 按钮发生变化
• 结果提示

3.5异常情况

3.5.1中断操作

• 中断类型:
(1)退至后台运行:继续原来的页面
(2)异常关闭、闪退、崩溃:启动页
(3)通知:不处理
• 造成影响:数据变化、页面跳转
• 应对措施:是否提示、是否备份

3.5.2网络情况

• 没网络、网络不良、网络超时

3.5.3账号相关

• 未登录

是否互斥:不同设备、不同浏览器、相同浏览器不同窗口、相同浏览器相同窗口不同标签页

3.5.4版本相关

• 命名规范、是否强制更新、是否影响老版本

4非功能性需求

4.1数据需求

• 埋点:模块、页面、页面分级、需记录数据
• 事件:页面、事件名称、事件ID、版本、自定义label、自定义时间参数、分类

会员登陆 17

4.2性能需求

• 模块、发生场景、成功率、响应时间、并发数、说明

会员登陆 18

4.3兼容性需求

• 设备、浏览器、版本号、应用、低版本兼容性

会员登陆 19

4.4服务需求


服务事件、服务频率、场景描述、解决方案、协助类型、需要协助方、服务成本
• 协助类型:客服、营销、法务、财务

会员登陆 20

4.5帮助需求

• FAQ、帮助文档

4.6风险描述

• 风险事件、风险来源、关联责任方、解决方案

会员登陆 21

5文档要求

• 标准:对业务名词的定义要统一,不然大家都是不同的口径。
• 规整:就像开发的代码要遵循代码规范一样,产品的PRD也要排版规整。
• 简洁:用最精炼的语言去表达重点。
• 易读:尽量使用可视化的方法,比如流程图,因为一图胜千言。
• 全面:功能描述全面,避免含糊不清的表述给开发造成误解,引起返工。

参考资料

产品经理整理PRD时,需要注意哪些点

倒推“饿了么”App产品需求文档(PRD)

我的三年产品基本功(PRD)|将交互、业务逻辑、需求字段撰入文档

一份靠谱的PRD文档,需要注重哪些细节?

写PRD怎样思考的更加全面

重点!速查清单地址请戳此

彩蛋:在微信公众号idatadesign后台回复“prd2018”(防止链接失效),可以得到
笔者自制PRD模板 和 笔者搜集的PRD资料~

相关文章