PRD清单

写清单原因

为什么要有PRD清单,这是因为做项目都是敏捷开发或者迭代开发,只在原型稿旁边贴上交互说明,项目发展比较稳定后才慢慢补上PRD,写完后发现之前有些真的没考虑全面,写文档也是自我反省的过程,为以后写PRD提供速查清单

清单内容

1、文档综述

1.1PRD输出环境

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

 

1.2修订记录

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

 

1.3文档介绍

1.3.1目的

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

1.3.2范围

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

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

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

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

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

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

1.3.3名词解释

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

2、产品概述

2.1产品介绍

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

2.2功能架构图

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

2.3信息架构图

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

2.4交互流程图

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

2.5业务流程图

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

2.6功能模块

2.7全局说明

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

3、详细功能

3.1页面介绍

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

 

3.2处理规则

3.2.1显示机制

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

3.2.2排序机制

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

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、自定义时间参数、分类

 

4.2性能需求

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

 

4.3兼容性需求

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

 

4.4服务需求

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

 

4.5帮助需求

• FAQ、帮助文档

4.6风险描述

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

 

5、文档要求

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

  • 2
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值