PRD文档写作详细说明

你是否有过因为PRD文档写得不够好，而被开发怼的经历呢？这里一份详细的PRD文档写作说明，get这份说明，你的开发过程将会很顺利。接下来，就让笔者为我们讲述如何写好一份PRD文档吧。

PRD 文档写作详细说明

• 取值规则
  • 取值后台字段「xxx」
  • 取值用户点赞次数
  • 取值符合某些条件的多个字段的组合结果
  • 是否去重？
    • 若可以多次输入，是否需要去重？
  • 下架的/清算的/发行失败的等情况是否要取值？
  • 很多前端的内容，都有一个后端的内容与之对应。取值来源大致分为这几种
    • 公司内部
      • 后台字段
        • 可动态变化
      • 直接写上去（写死）
        • 静态页面
    • 用户
      • 如点赞次数、用户评论等
• 显示规则
  • 显示内容与排版
    • 基本通过原型图表达出来
      • 按钮、图标、文字、图标+文字……
    • 写清楚「文字内容」
      • 「按钮」的文字内容、「提示」的文字内容、页面各处的文字内容，尤其在设计稿与要求的文字内容不同时更应注明。
      • 文案、提示说明（填写说明）。例如增加功能，是叫“新增”还是“增加”还是“+”？
  • 取值数据为空时如何处理
    • 为空
      • 若数据为空是否用「xx」（如「--」）代替？还是隐藏？
        • 如果隐藏，是否要连字段一起隐藏
    • 不为空
  • 显示数量
    • 控制显示数量的作用： 1.用有限的空间显示恰当的数量； 2.保证页面性能； 3.其他。 1.用有限的空间显示恰当的数量 显示数量与空间大小息息相关。 例如限制字符数，就是因为空间限制，无法显示太多字符。 换句话说，控制显示数量，目的在于用有限的空间显示恰当数量的内容。当然，这个「恰当」由用户需求决定。 也就是说，这个逻辑链条是：用户需求-->显示空间与排版-->显示数量。 例如： 对于序号之类的标签，如果序号过大，就要考虑序号是否会超出标签现有大小的限制，要防止其超出限制。 2.保证页面性能。 例如产品列表页限制显示2500个产品，就是出于性能考虑。 3.其他 对输入框，常常会限制输入的字符数，这可能有很多考虑。 例如微博之前限制140字，是出于一种短阅读的考虑； 评论限制字数，可能也有这种考虑，也可能有性能的考虑。
    • 列表
      • 显示多少列表内容？是否使用分页？一页显示多少？不使用分页显示多少？
      • 显示多少数量才不影响性能？
        • 数量过多时可能影响性能
    • 字段
      • 显示多少字符？超过多少数量时是否以...或其他符号（如--）代替？被代替的部分是否在某种情况下显示（如鼠标悬浮时、显示在title中）？还是截断？
  • 显示格式
    • 数字显示格式
      • 只要有数字，都要限制显示格式。
      • 时间/距离/金额/百分数/小数点等数字的显示格式
    • 附带xx
      • 带单位？在前面加上xx？
    • 善用颜色
      • 可以用颜色来区分重点
      • 尽量涨跌只用一种颜色，保证一致性
  • 排序规则
    • 按照xx排序？xx相同如何排序？
    • 优先按照xx排序，其次按照yy排序
    • xx相同则随机排序，这个"随机排序"也要写出来
• 交互规则
  • 当前页打开，还是新开页面打开
  • 鼠标悬浮、点击、按压等时的颜色变化
  • 提示形式——toast? dialog? snackbar? 还是其他形式？
  • 弹窗形式
    • 模态视图？其他视图？
    • 如何关闭弹窗？能否点击弹窗外区域以关闭弹窗？
  • 可输入区域
    • 输入的方式是否限制（键盘输入？下拉框选择？点击标签自动添加等？）？输入的数据类型是否限制（数值型？字符型？）？输入的字符数是否限制（超出限制如何提示？）？是否必填？
  • 删除
    • 逻辑删除还是物理删除？
• 默认规则
  • 默认的取值规则
    • 默认取值xx，当xx为空则取值yy
  • 默认的显示规则
    • 默认显示xx，当....则显示yy
  • 默认的交互规则
    • 导航栏，默认选中某个标签
  • 当有多个规则时，会有默认的规则。这个不用单独列出，只需列在取值/交互/显示规则当中即可。
• 边界情况
  • 取值规则
    • 字段为空
  • 显示规则
    • 当没有时如何处理？
      • 列表
        • 无数据时显示什么
      • 单个字段/模块
        • 无数据时显示什么
    • 当数量巨大时如何处理？
      • 列表显示数量过大时可能影响性能，要与开发协商处理措施
      • 避免影响性能、网页加载速度
    • 时间显示格式
      • 显示时间区间格式：若开始时间和结束时间为同一天，那么是否只显示一个时间即可？这样更简洁，也更容易阅读。
  • 交互规则
    • 操作次数限制
      • 是否要限制？如要限制，限制多少次？达到上限后如何提醒？
    • 输入内容限制
      • 是否要限制？如要限制，限制多少次？达到上限后如何提醒？
    • 返回按钮
      • 若上一个页面为空，则返回哪里？
    • 评论
      • 刚评论成功时，评论显示在最上方。刷新后，再按照排序规则显示
    • 点赞
      • 未登录状态下如能点赞，则可能因为未记录点赞用户而导致刷新后能继续点赞，即点赞次数无上限。而且，未登录状态下的点赞次数的接口容易被人调用从而导致恶意点赞。
    • 筛选标签
      • 能否同时选中多个？如能同时选中多个，页面显示什么内容？按照什么规则显示？
    • 是否必填
      • 必填提示、未填写的提示等
    • 提示
      • 提示多久消失？
        • 比如toast提示，是否3s后消失？
    • 编辑
      • 是否可编辑
      • 涉及到编辑时，要描述清楚编辑成功后的交互。比如保存后是否要刷新页面
  • 异常情况
    • 出现异常情况时如何处理？
      • 没有网络/网络异常
        • 显示什么？
      • 服务器忙
        • 显示什么？
      • 产品下架/页面被删除等
        • 显示404？还是其他？
      • 比如恶意评论、恶意刷分等
  • 几个不同状态
    • 例如： 1.点赞 未登录状态下如能点赞，则可能因为未记录点赞用户而导致刷新后能继续点赞，即点赞次数无上限。而且，未登录状态下的点赞次数的接口容易被人调用从而导致恶意点赞。 2.评论 未登录状态下能否评论？如果不能，点击输入框/回复按钮，如何交互？
    • 登录/未登录
    • 认证/未认证
    • 有权限/无权限
    • 报名中/进行中/已结束
      • 对于活动的3种状态——报名中、进行中、已结束，一般而言，应该将「报名中」、「进行中」高亮显示，以突出它们的位置，也便于用户查看和使用，也利于产品宣传。同样地，在排序时，应该将「进行中」的排在最前，其次是「报名中」，最后是「已结束」。
  • 一般不用单独列出，只需列在取值/交互/显示规则当中即可，当然可以通过加粗等方式说明，以提醒读者
• APP PRD注意点
  • 需求列举需区分各端
    • 原生页面
      • IOS/Android/Windows
    • H5页面
      • 站内H5页面
      • 站外H5页面
    • 后端
  • H5页面
    • 站内H5页面
    • 站外H5页面
      • 分享页点击跳转
      • 是否要二次转发
      • 哪些页面有，哪些页面没有要确认清楚。有些页面没有站外分享页面。
      • 点击哪些区域进入哪些位置要确认清楚
        • 跳转站外哪个分享页
        • 跳linkme到站内哪个页面
      • 边界情况要确认清楚，比如无数据了是否显示某些按钮等等。
    • 站内站外的不同也要列举出来——针对H5页面
  • 版本兼容
    • 原生页面无法向下兼容
    • H5页面
      • 是否做版本管理的区别
        • 如果做了版本管理，则新旧版本可以独立
        • 如果没做版本管理，则只有一种页面——新版本页面
      • 站内、站外H5页面的区别
        • 站外H5页面无法区分旧版本APP，只能统一用一种方式处理。
        • 站内H5页面可以区分新旧版本APP，可以针对不同版本APP做不同处理。
  • 分享
    • 分享图标
    • 分享标语
    • 分享内容
    • 分享渠道
      • 通用分享渠道就是各个APP常用的那几个，比如微信、朋友圈、微博等等。如果需要特殊分享的，需要标注出来，特殊分享如点击后生成图片分享之类的。
    • 有分享功能的页面，都要带上「分享」按钮
  • 通知类
    • 通知标题
    • 通知内容
    • 点击跳转页面
    • push确认——是否需要push，点击push后跳转的页面，push的时间、样式等
  • 其他
    • 大的需求不要写"优化"
    • 每个版本都涉及APP启动页更新
    • 键盘按钮
      • 比如键盘右下角的回车按钮，在搜索时，点击后可以搜索
• 其他
  • 工作流程注意点
    • 策划/PRD
      • 在策划/写PRD时，要查看设计稿的原比例图而不要看其缩小后的图，以免影响判断
        • 在需求设计（包括PRD撰写）时，要查看设计稿的原比例图而不要看其缩小后的图（这可能也是乔布斯总喜欢看设计出的实物的原因，毕竟实物与设计效果是两种东西），这样可能导致需求设计考虑不周。
        • 尽量使用最终用户会用的，才能形成更正确的判断
      • 文不如表，表不如图，能用图的就用图
        • 用原型图表示所有可能出现的样式、形式
          • 要把页面上涉及的样式都补充完整，比如社区列表页，就会包括各种情况——长文、短文、红包、转发（分多种情况）……
        • 流程较复杂时，要用流程图梳理流程
        • 情况较多时，多用思维导图梳理
    • 设计
      • 需设计、前端参与的需要标注清楚
      • 给设计的PRD要尽量具体，尽量考虑到设计会问的问题
        • 例如超过部分用...替代，那么...就要体现出来
      • 给的文字内容需要便于复制，比如一些带交互的地方，可以在旁边备注好文字内容，便于设计复制
    • 开发
      • 如果有与线上功能类似的，就尽量保持一致，降低开发理解难度与开发成本
      • 多为开发考虑，提需求前要考虑清楚，并看看开发目前的排期，避免给开发造成太大压力
      • 增删查改最好都要标记
      • 现有产品有的最好能提供个URL之类的，便于开发查找
      • 对于以后可能会作为通用模块使用的，要备注出来，否则开发可能会忘记，导致后续效率降低
      • 对于关联性较强的数据，开发难度往往更大，此时应更多地考虑性能
      • 如果更改频率低，写死比在后台添加更好
      • 对于更改后与更改前相同的部分，最好写清楚是哪里（取值/显示/交互等）不变，便于开发找到代码
      • 发版
        • 对于web端，先前端发版，再后端发版，避免上线后样式出现问题
      • 更改任何需求，都要知会相关人员。最好是：版本负责人知道-->需求文档变更-->然后才是开发和测试同学知道
    • 测试
      • 争取在测试环境发现所有问题，以保持线上稳定、准时上线
    • 运营
      • 上线前要录入对应数据
      • 对运营而言，需要他们配置的字段，最好都能有一个排序功能
        • 这样他们可以快速比较，快速找出异常项/突出项，从而对这些内容进行更改
    • 数据统计需求
    • 法务需求
    • ……
  • 产品某些特征导致的注意点
    • 历史情况
      • 对于一款已有产品，都要考虑历史积累，几乎不可能完全推翻重来
      • 历史数据处理也很重要
    • 公司内部多端打通
      • 如PC、M端、APP端、前后台、数据中心等
      • 一端更改，可能涉及其他端，要考虑到，否则可能影响其他端的功能
    • 合规处理
    • 一对多、多对一之类的
    • M端
      • 关于微信
        • 微信自带头部，因此需要说明导航栏内容
        • 微信分享需要提供分享信息
      • 前端可以对标题等内容进行自动适配——根据手机屏幕大小进行自动适配，所以常常可以不用限制具体的字符数，而只需限制显示1行即可
    • 对于可编辑的字段，空格是否作为有效字符也需要考虑
      • 对于 [密码]，空格可以作为有效字符（如果技术上无法实现，也可以不作为有效字符）； 而对于一些普通字段，则要具体情况具体分析。例如：对于一个必填字段，填了空格后在页面上无法显示任何有效内容，则应该将其作为无效字符；反之则相反。
  • 后台字段
    • 需要考虑
      • 字段名
      • 数据类型
        • 字符型？数值型？等
      • 是否必填
      • 是否可修改
      • 下拉框选项
      • 备注等
      • 例如
    • 后台需注意的几个字段
      • 权重、状态（有效，无效，已删除）
        • 权重用于排序
        • 状态用于确认是否有效
    • 富文本编辑器还是普通文本编辑器要说清楚
    • 尽量保证一个字段只有一个编辑入口
      • 便于开发
      • 信息架构清晰、简单，便于使用者理解
  • 计算规则
    • 某个数字如何计算？如收益率