记得刚开始做产品出需求方案的时候，上来就开始画原型写文档，在写的过程中发现某个交互没想明白或者漏了一部分逻辑，然后回过头来再修改或者补漏，这样前前后后折腾好长时间，终于做完了一份完整的方案，等重新检查的时候，发现又漏了某个地方流程有问题，于是又改，反复折腾之后终于完成了初版。
然后等到需求评审的时候，面对技术爸爸们的各种疑问如坐针毡，发现又漏了好多的逻辑和细节，等到需求评审结束的时候，已经被需求折磨的死去活来。
出现这样的问题，一是因为刚开始做产品方案设计，基础产品交互规范的熟练度不够。还有就是急于完成任务，对于需求或功能的整个没有思考的很明白，太过于专注方案以及功能本身的实现。
后来做的需求多了（踩的坑多了），慢慢的修正自己过去在做产品方案的中一些问题，也跟身边同事交流，整理了一套比较符合自己的产品设计流程，可能不适用所有的场景，是我目前用的比较多的一套流程。
一、“看”竞品
说到看竞品，很多人的第一反应是要抄么？我们一般刚开做需求方案的时候，常见的套路就是选几个相关的竞品或产品，对着某个功能抄一遍，然后形成自己最终的方案。
这时候我们的注意力还是方案或功能实现本身，并没有深入的思考内在的逻辑以及背后的动机等等。就像上学的时候，交作业前拿过来同学的作业对着答案直接抄了上去，并不会再去想答案背后的演算流程。但是也有老师会说，同学们你们抄作业可以，但是你们一定要弄明白抄的答案为什么是这样。
看竞品也是同样的道理，在开始策划一个需求方案的时候，我会找到竞品功能或者相关的功能，深度的体验相关的功能，弄明白整个功能的逻辑以及流程，体验功能交互上手的感觉，对功能的效果有个初步的判断。
同时要做好记录，对于竞品做的好的点以及关键点的实现逻辑做好收集记录，然后对同一功能或模块在不同平台的实现方式或者关键点的差异尽可能的收集资料，尽可能作出符合逻辑的思考和解释。做完这一步对需求整体的实现逻辑以及流程有了初步的掌握，可以开始下一步。
举个简单的例子：策划登录注册功能，同样的登录注册功能可能在不同的产品上具体实现的业务逻辑或流程都会有不同，注册门槛的差异、注册流程的不同、注册信息的、登录场景的不同等等，都跟具体产品的需求场景和特性有关。
二、理思路
做完竞品调研后，就可以着手开始自己需求的策划。在对业务逻辑以及功能流程有一个大概把握的前提下，再结合自己产品当前的现状以及实际场景从整体到局部开始进行（说到整体到局部的系统化思维，推荐一本很多人都看过的书《金字塔思维》）。
从需求背景、需求目的、功能流程、功能list、关联需求等等，开始整体思路的梳理。功能list以及功能流程，在竞品调研的基础上是最容易出整体思路的模块，也是产品功能设计本身，但是需要注意的是，产品功能本身只是需求策划其中的一部分，不是需求全部。
我经常踩坑是，关注需求流程和实现本身，而忽略和需求相关联的其他需求点和事项。比如，新的需求方案对于已有需求影响、新老版本兼容的问题、涉及的财务、运营等各个流程的变动问题、功能的推广问题等等，以上都是需要根据需求的实际背景事先进行考虑以及规划的。
还有经常被忽略的一点就是需求价值以及效果的衡量，我刚开始做产品经常有的问题就是埋头于如何实现整个需求，对于需求的价值以及效果很少考虑，做了很多东西但是并没有好好回顾其中的价值，对于工作的回顾和产品的认知是很不利的。
等梳理完框架以及流程之后就可以先跟boss或相关同事提前进行沟通，在大方向以及思路一致的情况下再开始撸需求文档，如果在思路框架都没有保持一致的情况下，就直接上手开始画原型撸文档，后面如果一旦思路或者框架需要调整，可以快速的进行修正。
接上面的例子：关于登录注册模块需求的实现，做完竞品调研，根据自身产品特性可以确定功能模块以及流程，比如内容型产品，前期降低登录门槛，可以直接使用第三方登录，同时获取用户的基础信息以及注册账号。
三、扣细节
框架流程有了，就可以开始第三步最终交互设计的完成和需求文档的撰写，在前面思路以及流程梳理清楚的基础上，开始画原型写文档，整个过程会相对顺畅很多，避免走很多弯路。
交互设计以及需求文档撰写算是产品基本功，在框架流程完善的基础上，再开始画原型撸需求。可能很多人最开始做需求文档的时候会纠结于用什么画原型、原型要不要高保真、文档的格式是怎么样的？
在最开始撸需求文档的时候，我也会纠结要用什么原型工具，Axure用很多了，要不要尝试一下墨刀？原型太丑了，是不是做的更好看一些？需求文档应该怎么输出：直接在原型标注输出还是输出标准的文档？也会网上搜各种类型的文档进行借鉴模仿。
后来在不同的团队输出过各种样式的需求文档，不再纠结于原型以及文档的格式。文档只是用来承载你的思路和方案的载体，用来跟开发测试团队沟通的媒介，还有很重要的一点就是留底（谁应该来背锅）。至于输出的格式以及文档的风格，还是看团队风格以及个人习惯，在符合团队风格的基础上，怎么高效怎么来。
需求文档也是一个持续迭代优化的过程，就实际经验来说，不可能一次性写出一个完美的需求文档，在需求推进的过程中，随着需求评审、开发、测试，需要不断的进行优化调整，要做及时好变更记录，快速的同步相关的同事，以免因为信息不同步导致功能出现误差。
到这里你总算撸完了一套需求文档，可以稍微松一口气，开始进入进行需求PK环（撕逼环节），在撕逼和背锅的路上开始狂奔。最后需求终于上线了，你想着可以松一口气了，然而等着你的是更多的需求以及文档……