一个功能由多个页面组成，而撰写需求都是以页面展开。比如下面是PMTalk小程序「我的票圈」详情页，可以看到从上到下本页面分为4个红色矩形进行展开。

分别有导航栏、banner、票圈信息流、底部导航栏4个部分。

「我的票券」这个功能也是这个页面，产品经理撰写需求文档就会从上面4个方向开始写。

第一个矩形部分：导航栏

包含了返回按钮、小程序缩小按钮、小程序分析按钮3个操作。如果要撰写需求文档，实际上面3个按钮都可以展开功能描述。

可是微信小程序有官方自带的能力，小程序分享按钮就自带下面标准的8个入口（安卓）。而产品经理可以对这8个进行部分筛选或添加部分能力，比如小程序的朋友圈分享能力，但是由于目前该能力仅支持安卓机型，用户的使用数据特别低。

所以在需求文档撰写的时候，这一部分是可以省略的。同时导航栏返回图标已经明确表达了是返回上一层级操作，需求文档也可以不用撰写。

所以如果是产品新人，会纠结是否要撰写这部分的需求。而产品老鸟则不会撰写这部分了。

第二部分矩形：banner的需求描述

对于这部分需求，因为banner涉及手势操作，所以会有交互、和banner的展示逻辑2部分。

交互部分：

什么样的手势操作会触发banner变化，同时banner的速度、切换效果等。这都是可以在需求文档表达，去做开发的。

但实际上这是没有意义的

banner这类都是前端开发都会采用现有组件完成，就像产品经理在原型产品设计会用部件库完成一样。所以只需要告知banner的展示逻辑即可

banner的图片尺寸、banner允许展示的数量、banner是否有推荐算法、banner的埋点等，这类需求是产品经理需要撰写的。

第三部分矩形：我的票券信息流

这部分因为涉及到行为操作，同样会分为2部分，一个是交互、和信息流展示逻辑、还有信息流的跳转。

交互部分：

同样信息流到底是如何滚动的、滚动的速度是什么样、触发滚动的交互面积在哪里，这是可以撰写的。

可信息流有标准的规范和组件，这部分同样不需要产品经理撰写。

信息流展示逻辑：

这部分包含了信息流的标题、摘要展示逻辑、长度显示、同时展示顺序的约束。比如为了提升票券的使用率，对「我的票券」里对于即将过期、已经过期、还没有过期的票券展示顺序。

可是需求设计要求尽可能在第一版本保持简单，所以核心是提供我的票券查看能力。而不用撰写信息流展示顺序，把展示的标题长度说明清楚就好。

第四部分：小程序的tab

同样这部分也会包含交互和逻辑展示2个部分

交互部分：

是否支持长按、点击、轻触等手势操作；tab展示逻辑是否有前置条件，比如有的tab需要用户一定要登录注册账户后才能展示内容。

产品经理在需求文档只需要写出tab点击跳转的页面就行。而上面其他的要么是超出了常规开发的能力、要么是把需求做复杂了。

以上就是一个产品经理的需求文档撰写方式，你可以看到越是老鸟的产品经理越能把握需求的核心功能和逻辑，而去掉将需求变得越来越复杂，有版本计划的对需求进行扩展。同时知晓固定的组件和交互规范，减少在交互和动画效果的时间。

-END-

转载请注明：电商回忆录 » 写需求文档容易犯的错