如何写一份易用的产品需求文档
错误的观点有三个：
1、用Axure写移动端的文档，在旁边扯出来很多线头，本身让研发看起来就很麻烦。而且很容易漏东西，或者某处逻辑很复杂的时候，就会让整个页面特别乱。
试想一个特别大的画布上满是这样张牙舞爪的图片伸出来的狗皮膏药，既难看，又容易看漏掉。
如果每个原型页面就放一张图的话，要一个个点击，看着就很浪费团队的效率。
2、商业需求文档，也叫BRD（全称为：Business Requirement Document）讲的是商业相关的内容啊，比如市场分额，如何差异化，用户需求分析等内容。
绝不是PPT里头的逐项列的那些「版本说明」、「开发周期」、「版本历史」、「修订历史」之类的。
这些其实就是对需求文档起到一些「说明性」的辅助而已。压根就不能算BRD好吗？
3、交互原型
这一定是对交互原型有什么特别深入的误解！
交互原型，都是做出来的有动效的那种好吗？
看这里：（交互原型也可以在手机上打开，手指点击操作）
采用的是 墨刀原型工具，他们论坛上这样的还有很多，侵删。
其他两个就不说了：
用例文档，官方说法叫：测试用例。
一般由测试工程师用excel表格来梳理，把要测试的点，以及可能会有的异常点梳理清楚。小公司没有测试，有人会让产品经理来写。
需求卡片，完全可以用 Excel来管理。
最重要的是：
同志们，咱做产品经理的，做事情还是要务实，不要来炫技，不要搞一些胡里花哨来装高大上。
关键还是要让研发、让团队用的爽，这才是真正重要的事情呀！
那么一份易用性的需求文档到底应该怎么写呢？
第一步：项目介绍
▎要点：言简意赅，把核心事情交代清楚即可
这里头包含：
- 项目概述：这版需求文档解决一个什么问题？
- 需求修订记录：谁写的，什么时候，主要改动哪些？谁指导的？
- 本期需求概要：主要讲了哪几个大模块的需求？一个，还是两个？
2、文档正文：
▎要点：页面划分明确，排序规整&编号清晰，遵从功能描述的「6要素」
- 页面划分明确：
也就是说如果App有四个主Tab页面，那么右侧大的目录，就四个大画布。（如果详情页比较复杂的话，可以单拎出来）
比如这份需求文档，就有五个大画布页面：
1.0 首页
2.0 摄影师
3.0 预约
4.0 我的
5.0 摄影师详情页
- 排序规整&编号清晰：
1、同一大画布下只放置当前页面和其子功能
2、横排放置不同的功能，纵列放置同一功能的不同状态
3、编号按照：
横排：1.0 首页、1.1 城市切换....
纵列队按照： 1.1.1 选中其他城市....
- 遵从功能描述的「6要素」：
页面上的每个功能，从左到右，从上到下。逐一按照这「6要素」来逐一描述：
以这个Banner的需求文档描述为例：
3.banner滚动图
位置：位于约拍功能下方
点击状态：点击后首页收起，打开页面相关URL页面，链接可在后台设置；
图片数量：图 片共计4张；
图片来源：后台手工配置；
图片切换：每隔3秒切换下一张图，所在的图片的圆点变色，变重色突显区别于其他圆点，当最后一张结束时，循环第一张；用户向左/右滑动切换至下/上一张图片。
图片极值情况：若图片无法显示，调取原始默认图片，来源于UI第一期上传数据
对，这「6要素」就是：
1、位置
2、状态
3、数量
4、来源
5、交互
6、极值
每一个功能都要逐一用这个6个点来描述一遍，有些功能没有，就不用写。
尝试过在图片上标注箭头扯出来的那种描述方法，但确实不太好看，而且会让页面很乱，或者要点击多个页面才可以看到。
而用文中的方法写文档，研发打开一个页面就可以看完所有的了。
什么？担心看的对应不上？
拜托，写完文档，不是直接丢过去就好了伐！ 还要开需求宣讲会的呀，逐项要给研发同事讲清楚的哇！！！
来源：https://www.zhihu.com/question/29213027/answer/576056890
评论