如何写一篇及格的需求文档

什么是需求文档?

需求文档一般是描述产品项目由“概念化”到“图纸化”过程的重要载体。而互联网产品文档更致力于“定义问题”和“阐述解决方案”两个方面,目标感更强。

需求文档由产品经理撰写,面向研发人员、测试人员和设计人员,更复杂文档也会兼顾业务运营人员。文档是各方沟通写作最可靠的工具。

一般来说,研发人员能从文档中全面且清晰的明确产品功能逻辑,设计人员能够从文档中了解设计方向和交互诉求,测试人员能够根据文档创建测试用例。

一言蔽之,需求文档贯穿项目周期始终,是产品立项到开发再到上线实施过程中的关键文件。

什么是及格的文档

撰写原则:需求文档关系协作各方,也对后续产品发展起着重要作用,因此一篇需求文档应该是产品经理深入思考沉淀的结晶。

易读:文档面向多重读者,因此要保证每个角色都有一个流畅的阅读体验,沉浸阅读中,这也是合格需求文档的基本要求。

  1. 行文;多用短句,少用长难句,写的清楚利落即可。平铺直叙,按顺序撰写,不要插叙倒叙,让读者产生困惑;
  2. 用词通俗;在一般性描述用词中,多采用通俗性词语,切勿造词、使用抽象难懂的词语;
  3. 用词专业;研发、设计等不同领域中,有着领域内的专业词汇,这时应尽量用专业性的标准词汇,一个专业词汇抵得上一万句啰嗦。

结构化:最重要的思维技巧,复杂问题拆解成明确的分类,可以使复杂问题变得简单明确。相似分类尽量抽象统一,便于降低读者后续的阅读成本。

细腻/全面:所有展现的页面、空间、元素、内容和操作结果都应在文档中准确描述。所有非理想的、异常的处理也要在文档中明确说明。忌用模糊化、不确定性或省略性的描述。这也是对自己、对相关方负责的体现。

文档的撰写思路

一般来说,我习惯将文档拆分成四个模块:1.背景与目标 2.范围与流程 3.需求主体 4.筛查与回顾

一、背景与目标

需求文档本质是对现状提供一种解决方案,而背景与目标部分就是基于现状的详细描述和深刻理解,文档主体也由此展开。因此一个合格的产品经理,应该认真对待背景和目标。

背景:尝试回答这几个问题:当前的问题是什么?问题带来的影响是什么?问题产生原因是什么?准备如何解决这个问题?

目标:概括性描述此项目的预期目标是什么,一般从需求结果和时间角度描述。据此文档,读者能清楚的了解到,我们将对问题解决到什么程度,上线 deadline 是什么时间?

二、范围与流程

涉及到复杂项目,应该将此需求的所有关联方和涉及内容写明,使读者对此需求中,自己的任务和从属关系形成基本轮廓。

逻辑流程复杂时,应提供流程图、时序图等,帮助读者方便理解功能、数据流、现金流、信息流的交互方式。

三、需求主体部分

  • 结构化思路使理清思路最常用的工具。问题越复杂,结构化的收益越明显。
  • 结构化的文档,便于一目了然地发现某方面必要信息的缺失(忘了埋点?丢失一个环节?没说清楚一个按钮点击去哪儿?)

从画格子开始

随着语雀、飞书文档、confluence等优秀的文档工具出现,推荐使用表格的形式描述需求细节。

我们将表格拆分为四部分,序号、交互、需求说明、埋点四部分;

img

撰写体验而不是功能

体验是按照时间顺序发生的一串时间;

按照事情发生的顺序,是读者最容易理解的叙述方式,同时,也能帮助作者考虑到时间对用户造成的影响(时间长短?是否需要loading?再次访问此功能是否需要设计?……)特别是端内外联动的需求(分享、裂变),按照时间顺序撰写会让流程更清晰。

img

看见了,写明

  • 一一对应原则 页面上所有可见元素,都要单独明确说明。如返回按钮、标题、元素1、元素2、元素3…。不应该出现第二列图上的可见元素,在第三列没有说明文字的情况
  • 有交互的部分,需要拆分说明:展现部分xxx,交互部分xxxx。其中展现部分如果有状态变化,应一并写明(如默认、选中、非选中.etc)
  • 前置条件和后置条件 如果交互后,需要变化状态/跳转页面,需要明确说明下一个状态/页面。如果基于不同的情况,有不同的处理方式,应分条目说明(不要写成一个巨大的自然段)
img

从哪里来,到哪里去

  • 序号的必要性:功能的名字时不稳定的,数字需要才是不变的。
  • 每个状态变化/页面跳转的操作都应该写明下个状态/页面的序号。
  • 如果时简单的状态变化,可以直接插图放入第三列说明,缩短文档,提高可读性。图片定宽150px。
  • 删除页面是,不必修改其他序号
  • 插入页面是,使用小数点即可,如2、3之间,插入2.1。不必修改其他序号
img

插图尺寸也要统一

  • 所有APP UX UI 图,应该定为统一的尺寸。比如 200px
  • 如果还有时间,在需求细审前将 ui 图替换到 prd 中。实际 ui 图与 PRD 文档完全对应能够避免很多沟通的误会。
img

不要漏掉埋点

  • 一一对应原则 与前文所有交互都撰写需求说明一样,埋点也需要一一对应撰写
  • 把交互图、需求、埋点写在同一行,能够降低不必要的沟通成本
  • 注意不要忘了访问页面本身这个事件
img

不要忘了后台

  • 前端每一个可人工配置/修改的元素,都要撰写对应的后台需求
  • 后台需要按照 增、删、改、查 四个部分去写,避免遗漏。不能只写关键流程
  • 后台需求不需要埋点一列,其他规范与前端需求一致
img

需求发生了变更

  • 变更时不可避免的。不要让变更前后的文档并存。文档上永远只保留正确的状态
  • 删除原段落,更换成新的段落。并加粗变更字体颜色,便于研发、UI识别变更
  • 不要担心之前的设计丢失,confluence、语雀都提供了自动永久保留操作历史的功能
img

策略类需求

  • 仍然保持结构化思路
  • 各类内容 push、推荐、机器人、小红点展现、内容策略、排序策略等。不要写成左图样式。应该提取出策略的共性元素,以这些元素为横向表头,拆解为表格。
img

回顾与筛查

展现类

  • 是否可能此元素内容超出预期导致放不下/不能正常展现?
  • 是否需要限制字数?是否需要切断处理?
  • 是否可能此元素无内容?无内容怎么展现?
  • 文案是否跟业务方确认过?是否符合需求方预期?

交互类

  • 按钮状态:默认、点击、置灰各自的定义是什么?
  • 选择组件:单选还是多选?是否由默认选中项?
  • 输入框:是否需要校验?是否有最大输入字数?是否自动保存?
  • 触发区域:面积够大吗?会不会误操作?
  • 交互结果:点完会怎么样?是否每个交互都有明确的去向?
  • 交互反馈:是否有反馈、Toast、弹窗、变色?是否考虑了失败状态?
  • 加载状态:过程需要多久?超过 2 秒需要设计 loading 状态?
  • 负面操作:删除、取消等,是否需要弹窗确认?
  • 刷新:页面是否支持刷新?刷新之后哪些元素需要更新?
  • 新手引导:是否需要新手引导?红点?浮层?气泡?

异常类

  • 版本兼容:是否影响老版本,是否需要兼容?
  • 流量保护:是否需要关注当前 WiFi 与否?比如视频播放、下载等
  • 断网处理:展现什么状态?是否自动重新加载?
  • 内容下线:是否需要登录操作?如果用户未登录怎么引导?
  • 冷启动:如果是新上线功能,外显数据看起来是否合理?

风险和影响点

最后的最后,要写明此需求上线可能存在的后续影响和风险。如果涉及业务运营介入,应提前通知并提供一份标准文档进行说明。


  • 一般情况下,日常我就按这个规范写需求文档,实际体验感觉比较高效且清楚
  • 有空会找一篇实际文档分享一下
  • 主要内容来自日常经验感受和同事分享

End

留下评论