从需求分析到原型制作，到需求文档，产品经理会掉进哪些坑？

从最开始的对于产品经理这个职位不屑一顾，认为不接触代码、不做设计，工作主要建立在沟通打杂这件事上，工作室会比较轻松，但后来真正实现入门，在相继接触多年的产品工作后，发现以前的认知完全错误，一个需求分析或者写需求文档就足够让我深入学习很久。

在此，多年走过的坑，以及熟知不再犯，给大家一些参考意见。

需求分析

做需求分析的时候，不要总是用“我认为...“”我感觉...“这一类的语句来解释为什么需要做这个需求，这类解释是苍白无力的，有时间去做个用户访谈，可以参考腾讯的10/100/1000法则（每个月10个用户调查，关注100个用户博客，收集反馈1000个用户体验），只有全局了解用户需求，才能做出为人所用的产品。

在会议上进行需求分析的时候，随着头脑风暴的崛起，需求随之增多，满满几十条跃然纸上，这都是正常的，这时候作为产品经理，千万不要宣布会议结束，直接确定需求，这是非常愚蠢的做法。

我向来坚持一个观点：只会加需求的人不是产品经理，会减需求的人才称得上是产品经理。

我经历过一个产品经过数次需求评审会议，在我进行需求优先级排序后，后期临时增加需求，然后无限制卖命加班，最后做出的产品是个四不像，各种功能都有，没有主次之分，很乱。

一般来说，对于需求分析，个人认为比较正确的做法是：在需求分析会议上加了很多需求，进行记录下来，然后回到产品的定位上面，从这上面进行思考，不要出现你做一个和旅游APP，加个社交功能，各种关注私信，这就是画蛇添足了。

根据产品定位进行思考，将最主要的功能进行甄选出来，并且和参会人员进行谨慎地确认，包括老板的意见，询问项目经理是否可以实现等等问题，然后将主要的需求进行确定，会议后进行整理，发邮件给反馈进行确认。

将最主要的功能甄选出来进行开发，可以提高开发周期的效率，快速上线产品，用户使用可以快速试错，通过用户反馈做出更好的产品体验。

需求确定后，在之后的设计以及开发过程中，不要出现一个想法，临时加需求，这样影响产品最初的一些规划以及开发排期，以我个人经验来说，后期乱加需求往往意义不大。

原型制作

需求确定后，产品经理一般着手于原型制作了，现在大部分的产品经理需要懂交互，所以你必须懂，还需要专业。

1、根据信息架构进行原型制作，根据具体的产品，我还是建议用比较简单的原型图来进行表现。

• 原型图不可能一次性通过，需要进行评审以及各种更改，制作高保真原型图涉及到那些跳转链接，费时费力，那么都需要改，你需要花费很多时间，给出清晰的备注就好，提高效率。
• 各种颜色以及按钮形状出现在原型图上，会极大地干扰之后UI设计师的设计思路，会对思维产生干扰，专业的人做专业的事。

2、在制作原型图的过程中，建议先画出清晰的业务流程图，有个清晰的思路进行参考制作原型图，每一个功能都需要画出相应详细的流程图出来，为了确认流程走得通，这是必不可少的。

经常有产品经理在确定需求后，一股脑地直接画原型图，最后做完给开发，发现最简单的登录注册流程都走不通，那真的是贻笑大方。

切记每个功能画出相应的流程图。

3、在画原型图的过程中，对于功能描述尽量使用确定肯定的词语，不要使用含糊不确定的词语。

功能描述能分点列出就分点列出，简单直接，不要使用大段文字，便于设计开发理解。

举个例子，这是对于留言界面的反例：用户可以在留言界面进行留言，留言可删除，点击屏幕可以刷新。

程序员看到了就要崩溃，是否登录才能留言，留言的字数限制，初始显示多少条，留言可删除是管理员删除还是用户，刷新是下拉刷新还是其他方式？

比较规范的做法：

留言初始显示六条，查看更多留言点击下方有关页数按钮。

• 游客不能进行留言，注册登录用户才可进行留言。
• 留言字数限制在五十字以内。
• 用户留言，本人可以进行删除，其他用户无删除权限。

以上只是一个简单的例子，功能描述足够清晰，才能提高设计开发的效率，减少沟通成本。

4、一个小细节，玩过很多产品，部分产品还在犯，

• 是”登录“，不是”登陆“，
• 是”登录“，不是”登陆“，
• 是”登录“，不是”登陆“，

重要的事情说三遍。

需求文档

需求文档是产品经理的日常工作，可能我们对于这份工作并没有做好，重在细节。

• 需求文档的命名要确定一个规范，以后照此进行，便于文档整理。
• 需求文档中，最开始需要给出产品定义，说明产品是一个给什么用户，基于什么场景，使用这个产品干什么。
• 关于需求文档中的术语和定义，都需要对专有名词给出具体的解释。
• 需求文章中最基本的信息架构图以及产品用例图，都要放上去，便于阅读者了解产品的整体思路轮廓，更加了解需求文档。
• 产品的版本规划中，确定的都填上去，不确定的就写待沟通。
• 有关具体的功能，先给出功能定义，再给出详细的流程图，前置条件、功能规则、后置流程使用清晰确定的词语进行表示，不要使用产品经理本身并不是特别了解的程序表达方式如：正则表达式等词语形容规则，这样的描写对错不确定，程序员看到这种内容也比较排斥，专业的人做专业的事，信任他们才对。
• 产品经理对于填写用户资料、评论、留言等内容的字段说明给出具体的规则，这是产品经理必备的素质，比如微博发状态140字，QQ个性签名50字等主流社交一般的规则，进行了解参考结合具体的产品给出合理的字段说明规则。

其他

1、最后一个在产品设计的过程中，不要刻意追求创新，去打破现有的一些产品交互逻辑。

比如修改密码，绑定邮箱等内容一直都放在菜单设置里面，这么多年的产品培养了用户这个习惯就不要随意打破，打破的效果只会适得其反。

2、每次和设计开发去沟通的时候，先想好要说的问题，为什么这么做，找到相应的数据以及产品样例进行支撑，来解释你的做法从而说服他们，不要因为程序认真发表他的意见拒绝你的需求，你就立马撕逼，这是最没有意义的一种行为。

事实上，我遇到过的程序员都是讲理的，前提是你要有足够的理由说服他。

最后

从小听过了很多大道理，却依旧过不好这一生。

这句话个人还是比较赞同，所以我比较喜欢掉坑，在产品设计的过程中，只有掉过坑后才能让自身印象深刻，在实际地遇到困难直到解决之后，才能对产品设计有更多的体会，能力得到提升。

另外一个非常重要的就是总结，在你做完一个产品上线、一个产品迭代，在阅读完一本产品书籍后，不要经历了就经历了，看过了就看过了，对于这个过程中掉过的坑以及内容的总结，用mindjet等软件进行记录，十分有必要，让你快速吸收经验知识，能力也会得到很快的提升。

这是《用户体验要素》中的第一章节，一个章节进行总结浓缩为一页，一本书的精髓内容无非几页而已，这种做法的优点。

• 提升你对于内容的筛选总结能力
• 加深对于产品设计过程或是书籍的理解
• 便于在产品设计思考遇到困境时，进行快速地翻看查阅，可以寻找一些灵感。

对于产品设计的思考，有兴趣可以和我交流。

#专栏作家#

不羁，微信号：hujianfeng1234，人人都是产品经理专栏作家对于电商以及社交领域产品有着深入的了解，对于产品设计以及交互体验有着近乎偏执的狂热，不折不扣的书虫，热爱思考，活到老，学到老，欢迎交流！

本文原创发布于人人都是产品经理，未经许可，不得转载。