概要文档明确某个功能模块下的功能介绍，一般是多个功能点的描述。需求概要一般由产品经理负责撰写，不包含功能细节描述。为了方便与产品设计师们沟通需求，可以将主要功能界面草稿加入该文档中，用原型草图能更好地描述主要功能。

　　腾讯视频PC版播放模块的需求概要文档

　　有了某个模块的需求概要文档后，研发项目经理组织团队沟通需求概要。产品经理首先介绍需求概要然后由其他团队成员提出自己关心的专业问题。会前产品经理提前分享文档，并收集准备大家的问题点。

　　会后主架构师根据需求概要做架构设计框架，研发工程师也可以针对自己负责的模块做技术预研。有经验的工程师，往往在这个阶段就开始试着做个Demo，把主体功能流程跑通，这样在正式进入研发时就会比较轻松，专注于细节完善和产品质量。

　　(5)输出需求详情文档

　　需求详情文档由产品设计师负责编写。需求概要中的需求点，每个都需要单独编写需求详情文档，而不是把所有的需求详情都写在一个文档里。这样会导致需求详情文档非常长，内容庞杂，这个会导致后续很多问题。需求点最好都能拆分到1周内能完成研发测试比较好，这样才能有效实现敏捷开发。

　　腾讯视频PC版自动登录需求文档

　　需求文档并不是产品设计师一个人闭门造车就能写出来的。产品设计师需要频繁与交互、运营、视觉、用户研究(UER)、架构师、测试经理、开发、运维等人员沟通。沟通的过程更多是产品设计师学习和融合各个角色思考的过程，同时也让各个角色的工作更加明确。

　　一般需求文档的编写分成以下步骤：

　　第1步：根据需求概要设计用户操作流程图。

　　第2步：根据用户操作流程拆分各个界面，绘制主界面草图加入文档，再分别描述每个界面的主要元素和功能点，再描述界面之间交互的逻辑，最后加上交互背后涉及的业务逻辑。

　　第3步：找运营沟通需求，根据运营人员的建议补充营销位、运营后台工具等内容。

　　第4步：找交互设计师沟通交互细节，根据交互设计师的疑问补充界面中的交互逻辑。交互设计师完成交互设计稿后，将交互稿截图并加入文档，并完善交互逻辑说明。

　　第5步：找视觉设计师沟通视觉细节，提醒视觉设计师突出重点。视觉设计师完成设计稿后，将设计稿截图并加入文档，并完善视觉界面说明。

　　第6步：找架构师沟通算法和技术逻辑，根据架构师提出的疑问完善业务逻辑。

　　第7步：找测试经理沟通测试用例，根据测试经理提出的疑问完善功能细节。因为测试经理需要写测试用例，测试用例是以需求文档为蓝本，如果需求文档不清楚必然会导致测试用例不完善，因此测试经理往往对产品设计师的帮助很大，甚至会比产品设计师更了解产品细节。

　　第8步：找UER做功能调研。UER将需求文档转化为调研文档，然后通过产品体验群、邀请客户当面体验等方式找出产品设计中的问题。然后UER反馈给产品经理，产品设计师合并优化成产品需求详情文档。有的公司UER调研也是由产品设计师承担，但是专业性上有可能难以保障。

　　第9步：找产品经理、研发项目经理、运维确认需求文档，并初步确定排期。

　　(6)需求评审

　　如果之前编写过程与每个角色都有了充分的沟通，需求评审就会变得很轻松愉快。否则，产品经理和产品设计师将会陷入无止境的辩论中，往往动辄就让整个团队消耗了几个小时还无法形成结论。

　　因此，需求评审的关键就是产品设计师事先做好评审会的一切准备。提前准备好所有资料并提前发给团队所有成员，并事先与所有角色都逐一确认过关键问题，而且得到了产品经理和研发项目经理的确认。在评审会上，先讲总体，再讲重要细节，再讲次重要细节，并层层确认。

　　对于会议上争议较大的问题点，5分钟后还没结论的马上记录下来，会后再单独讨论。如果问题点太多，就说明产品设计师还没考虑清楚，那就尽早结束会议，重新修改后再召开评审。这种情况会严重影响产品团队的声誉，因为耽误的是所有人的时间。为了减少这种风险，需求评审一定要提前1-2周召开，而不要等到开发前夕才进行评审。

　　3、交互设计