上一篇介绍了如何进行需求分析，需求分析的结果就是确定当前版本规划，接下来就是具体的功能策划，确定产品方案，输出研发可执行的需求文档。
一、思路分析
这个阶段和之前提到的需求分析思路是有重叠的，如果上一阶段工作做得足够细，这里就只需要整理之前的分析内容，输出产品定义文档，主要目的是向项目团队成员理清楚：需求从哪来？为什么要做？产品的功能定位，要解决什么问题？用户画像，角色分析、心理分析、行为分析、使用场景等内容。
二、绘制产品流程图
梳理产品的业务和逻辑流程是产品设计的核心，也是产品经理逻辑思维能力的重要体现，清晰明朗的流程图是后续原型、需求文档的基础，也可以让团队中的其他成员快速了解业务和功能，常用工具包括visio、axure等；
流程图通常包括参与角色、信息流转（信息传递、页面跳转等）、行为事件、异常判断等内容，根据业务复杂程度、信息交互方数量等分为单通道流程图和多方交互的泳道图，我的一些设计原则包括：
拎清楚主线，明确开始和结束点，确定关键路径后，在补充细节分支、异常判断等内容，尽量考虑完善，最后适当简化合并部分细节；不同类型的内容尽量颜色区分，一目了然；
下面是我梳理的登录流程的案例，仅供参考
登录流程
三、梳理思维导图
流程清楚之后，我们就可以据此画思维导图，思维导图的常见工具包括xmind、mindmanager等，内容主要包括产品结构和信息，除了这些内容，我通常还会把重点注意事项、核心逻辑判断等内容加上，进行备忘和提醒；思维导图出来后，这个产品有哪些功能、页面、展示什么信息内容就都清楚了。 下面是我写这篇文章的脑图，思路是一致的，梳理清楚文章结构和内容，这篇文章的核心就清楚的。
这篇文章的脑图
四、输出原型图和需求说明
接下来就是根据以上内容输出具体的原型图和需求说明。之所以把这两块合在一起说，是因为我经历的公司为了简洁、快速，都是使用的axure来画图和编写需求规则，没有单独的word形式的prd文档。对应文档的形式，我认为只要适合当前团队规模，便于人员协作、信息管理追溯就可以了。
原型图就是把上面梳理的导图进行页面化，站点地图的结构需要符合功能框架和页面层级，然后设计每一个页面，展示什么内容，如何布局排版进行呈现，团队有ui的话，页面尽量简洁清晰，低保真即可，给ui留出设计空间；这里建议每个产品经理在工作中逐渐整理和归档自己的原型，标准化部分控件、功能，这样能大大提升后续的输出效率。
需求说明包括项目介绍、修订记录、全局说明、模块功能描述和页面规则说明
1..项目介绍即思路分析过程中得出的产品定义文档；
2.修订记录：产品是分版本不断迭代的，修订记录能有效的呈现修改记录、迭代计划、变更内容，帮助我们进行内容管理和追溯；
3.全局说明即把产品通用内容提出来进行统一说明，避免重复工作；场景内容包括系统权限、常用控件、页面加载华润切换、通用字段、通用业务规则、埋点、缓存机制、crash收集、消息推送等内容，这个网上很多模板都有，可以参考、在工作中不断完善，形成自己的模板；
4.模块功能描述则是简介该模块有哪些功能，页面框架、操作流程，即前面梳理的产品结构图和业务流程图；
5.页面功能说明则是对每一个页面进行说明，通常内容包括
内容展示：这个页面长什么样、有什么信息；功能规则：这个页面能干什么；操作交互：怎么操作、操作后的反馈是什么；
以上内容每个页面基本都会有，此外通常会有一些容易忽略的细节，经历这么多项目，在和开发、运营人员和谐交流中，我总结了如下：
a.功能细节
数据来源：接口还是写死；数据缓存机制；极限展示规则：比如字数限制、行数限制、内容条数限制、数字显示极限等等；图片尺寸问题，压缩还是裁剪；夜间模式；新功能引导； 前后置条件：例如某些页面需要登录才可进入，相邻页面数据状态变化后需要同步；输入框键盘规则、输入内容现在默认状态说明、异常情况说明：空白页、无网弱网加载失败等情况的显示规则；
b.版本兼容问题
新功能是否和关联的功能有冲突；新旧版本内容显示是否有冲突；
c.风险预案
产品策略风险：是否会有漏洞被褥羊毛，需要考虑防刷机制；用户信息安全风险，是否隐私会被泄露；法律政策、市场审核等风险：是否需要增加灰度开关，功能下架后的显示规则；
d.运营需求
是否需要数据埋点是否需要后台数据统计和查询
建议大家可以不断总结完善这样一份checklist，面对一些复杂的功能时，设计完成后可以进行自检，保证文档质量。
总结
最后我们输出的文档是包含项目简介、需求分析、流程图、原型图、细则说明的综合内容，是开发可以据此进行落地实施的文档；再往后就是进行需求评审，和运营、开发、测试、ui、老板进行pk，确认最终方案，欲知详情，下回分解！