AAA教育

首先，我们在写需求画原型时，要做足准备

第一，产品经理在做原型时，不要一开始就画交互界面，而是单独列一个区域，把这个版本需求的来龙去脉说清楚。包括为什么要做这个版本，要满足哪些人的哪些需求，做了这些后有什么价值，如何证明，以及大概要做的模块都有哪些，时间估算等等，让每个来开会的人一上来就有宏观意识。

第二，涉及业务流程的需求，也要单独列一个区域，专门绘制流程图，并把流程图中的「概念」解释清楚，然后才是针对概念的交互界面，这样也能方便开发迅速理解业务，再和交互稿对照查看，印象更深刻。

第三，在绘制交互界面时，也要尽量按目的、按逻辑分组归类。比如将「提升用户活跃」作为大分类，在这个分类下，「推送功能优化」作为小分类，在这个小分类下，我们要做哪些子模块，层层分解。

 

其次，我们在会议召开前期，也要做足准备

第一，在和全体开发开会前，尽量提前和开发各业务负责人召开一个小会，进行需求初评，目的是提前收集问题，沟通是否有技术难点，确认需求的开发成本，并从技术的角度看是否有考虑不全的逻辑漏洞等等。如果存在需求不足的地方尽快修改。当然还可以让开发负责人向下简单传达要做哪些需求，让大家心里有数。

第二，在会议召开前，一定先通过邮件形式发布会议召开邀请，同时附上即将要讲解的原型文档，至少提前1天让所有参会人员了解需求。当然最好在发完邮件后到每个开发座位上再提醒一下，督促大家去阅读文档，有较大分歧的反馈尽早收集处理。

 

最后，在召开会议时，更要有备而来

第一，每一个需求点，产品经理自己要有充足的理由说服大家，无论是数据证明，还是市场调研，还是用户心理分析等等，尽量避免说出「我觉得应该XXX」这样的话，而是讲客观依据。

第二，每一种交互设计，都尽量有几套方案备选，如果大家对已画出的交互意见较大，就再摆出几种备选，让大家有目的地展开讨论。

第三，产品经理讲解交互稿时，可以先讲总体，再讲重要细节，再讲次重要细节，并层层确认。比如订单支付流程，先讲解支付顺利的主流程，再讲解支付失败的异常流程，最后再讲解支付成功、失败的交互效果。这样做的好处是限制讨论边界，避免理解偏差。

第四，对于会议上争议较大的问题点，有个「5分钟」原则，5分钟后还没有结论，就记录下来，会后再单独讨论。如果问题点太多，就说明产品经理还没考虑清楚，那就尽早结束会议，重新修改原型，再召开一次会议。当然我们还是希望这样的情况不要发生，因为非常浪费时间和精力。

 

最后的最后，再介绍一个小经验

就是建议将PRD、需求FeatureList和原型都画在一起，统一讲解，这样能提高效率，减少理解成本。如下图所示：

当然这是个人经验，不同公司可以根据情况调整。