编辑导语：在进行产品或项目规划时，我们需要先了解项目的具体需求、最终目的、当前背景等各方面，尤其作为产品新人，在进行产品功能设计时，更需要理清思路，做好规划。本篇文章里，作者分享了他初次接手一个裂变活动时的策划经历，一起来看一下。

在需求评审的时候，我们都希望自己设计的功能能够得到上司的表扬，能够得到周围同事的认可。但如果我们设计产品的时候思路不清晰，就有可能会说服力不强，被其他人的问题问住。这里我分享给大家我自身一次裂变活动功能策划的经历。

一、确定项目背景目标

当时我接到的入职后第一个项目是：设计一个公开课裂变功能。

拿到一个具体的项目之后，首先需要知道为什么要设定这样的项目？项目背景、目标是什么？

这个项目背景是公司目前流量获取成本非常高，产品增长出现瓶颈。为了降低公司流量获取成本，本次产品版本迭代需要加入一个裂变小功能。项目目标是增加裂变名片数量。

二、目标拆解，使目标更加明确

对目标进行拆分，可以使不明确的任务变得的更加明确，做事会更加有思路和方向。

图：项目目标拆解图

从项目目标拆解之后的结果来看，分享着人数、分享频率、被分享者人数、以及转化率都可以作为设计出发点和决策因素，在梳理场景的过程中，就需要着重考虑到这些出发点。

三、裂变场景梳理，寻找机会点

梳理完真实业务现场中流量转化过程中的细节之后，就要以调研事实为依据，开始脑暴梳理分享者对应的场景和需求，排列出需求优先级，选择优先级最高的需求做深入设计。

这次还是主要以体验课学员这类新用户的裂变为出发点，理由有两个:

1. 公司目前这类用户占比较多并且并没有充分利用。
2. 由于自己去售前现场调研过，还未调研过售后现场，对体验课学员和正价课预报名学员稍有了解，而对正价课学员的上课流程还未有充分了解。

分享者场景梳理如下：

图：裂变场景的梳理思维导

图中，分支按照用户-场景-需求机会点这样去排序梳理，先去不断发散思路，不要急于否定自己的前期想法，下一步才是整理汇聚。其中用红色标出裂变场景机会点。

四、排列出优先级，选出这次优先做的场景

站在活动分享者的角度梳理完场景之后，开始排列具体的需求优先级，如何排列优先级，从这几个维度出发：

• 需求频率和分享人数量；
• 开发难度和效果；
• 分享意愿强度。

维度占比得分：1-5分，每种维度得分：1-5分。

总分=维度占比得分*每种维度得分。

最终参考结果去考虑先做哪种场景。

结果做出直观的表格如下：

表格梳理完成后，就得出了一份还算比较客观的评价依据。

其实这里列出严谨的表格的好处就是，在需求评审的时候你可以有理有据说出为什么先选择这样的需求去做，更加具有说服力。但是也不要完全参照表格之中的优先级排序，还是需要根据实际情况进行场景的筛选。

最终选择第一个版本做买一赠一活动，也就是购买付费公开课的用户可获得一次免费赠送好友的机会。总体来说这个活动场景面向的活动参与人数最多。先不用追求完美，快速上线一个活动测试效果，未来再逐渐将活动覆盖至每种细分场景。

五、流程图与原型图

1. 流程图

在选择好具体要去设计的场景之后，接下来的流程图的绘制是重中之重，一定不可以省略。因为只有流程图梳理通了，后面的原型和需求评审才会比较容易。并且流程图也能够让参与者明确知道业务是如何运作的。

画流程图前应该梳理清楚这几个要素：

• 用户：有多少种类的用户会参与其中？系统也可作为参与者。
• 事项：这些用户要完成的事情分别是什么？
• 数据：在这个过程中数据是怎么流转的？
• 特殊状态：万一出现问题了，该怎么处理？

图：流程图

其实要展现哪些流程图也没有非常固定的规则，还是要根据实际项目去评判，就例如我目前做的裂变工具，裂变进来的流量如何入库以及如何给售前跟进是流程中需要重点去考虑的。但如果是电商类的产品，则需要更多去考虑各种特殊状态该怎么处理。

流程图的最终目的还是为了能够和开发更好的交流，只要达到这个目的就好。

2. 原型图

当流程图梳理的通顺了，原型图也就非常简单了。在流程图中具体数出来需要画原型的有多少个页面，与业务流程一致，页面结构清晰，界面统一。

这里就不花过多的时间赘述原型设计的细节了，本文的重点还是在新人产品做功能设计的基本流程套路。

六、PRD文档

当流程图、原型图都确定之后，就需要将这些撰写成PRD文档。

PRD文档就是产品需求文档，主要是一份供技术人员阅读的文档，他们需要参阅这份文档进行产品的视觉设计与开发。所以PRD文档中最核心的部分，就是功能部分的描述，需要考虑到各种异常情况与产品细节。考虑到的越多，开发的速度就越高，质量就高。

每个公司和团队情况的不同，文档也会有微小的差异。但总的来说一份完整的PRD文档通常包含以下几个部分：

• 需求简介（需求背景、产品特点）；
• 功能详情（产品功能结构图、业务流程图、页面流程图、主要功能描述）；
• 性能要求；
• 产品运营计划。

之前说到过功能详情部分的描述是PRD文档的核心，是占大头的地方。一个非常简单的评判标准就是看字数。字数越多，考虑到的状况就越多。这里我总结了在描述功能的时候，通常包括以下几种类型：

1. 取值规则：即产品前端的字段取的是对应的什么字段。
2. 限制：包含显示的范围、极限值、格式、排序等。
3. 状态：默认状态、常见状态、特殊状态。
4. 操作：常见操作、特殊操作、误操作。
5. 反馈：包括提示、跳转、交互等。

在刚开始写需求文档的时候，会发现自己总是会考虑的不全面，写出的文档经常被各方挑出毛病，这是非常正常的状况。遇到这种情况千万不要气馁，因为这正是不断试错和快速成长的机会。多去听听各方意见，自己新建一份复盘文档，把所有的问题及时写进去，下次尽量避免。

可以看到我第一次写的复盘文档，真的问题很多~但也必须经历这样的过程，才能得到成长~

图：我的复盘文档

七、总结

作为一个新人，很能体会新人产品在最初拿到任务的时候，内心的不知所措。

这个时候千万不要一上来就开始干，一定要捋清楚自己的思路，列出一步一步的规划，在脑中形成做事的框架，并且不断地反思、总结、优化这个框架，这样才会效率越来越高。

本文由 @小猫雯 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。