从需求分析到产品设计的思考框架
编辑导语：很多同学看过很多文章读过很多书，知道很多产品设计的知识，但一到自己上手设计产品，总是思绪万千，却不知道从何下手，其实这是因为知识还没串联成体系。每个产品都是需要一系列需求的慢慢搭建，作者结合自己的产品经验，对从需求分析到产品设计过程中的思考框架进行了梳理和总结，与大家分享。
互联网打工人肯定听过这样一句话：“既不会开发？又不会设计？又想当个经理？那只能去做产品经理了”每天开开会、画画图、写写文档、让程序猿干干活——总结一下就是“钱多事少有人管”。那产品经理的工作真像大家想象的这么舒服吗？
现实往往是方案做完之后，经常面临无数轮的修改工作，甚至到了开发阶段，才发现没办法实现需要推翻重来的尴尬情况。
下面介绍下由脑花总结的“从需求分析到产品设计的思考框架“，通过使用思考框架能够在一定程度能避免上面出现的问题（反复修改、推翻重来）。框架主要从方案的充分性、适当性、全面性进行搭建，希望能给各位同行带来一定启发，同时也邀请各位一起完善。
01 框架介绍
框架分为两个阶段：产品思考、产品方案。
产品思考阶段，需要想清楚几个问题：需求背景、需求目的、功能定位、限制条件。这些问题看着都很虚，实际上是在明确需求边界，同时也是产品经理在设计产品方案阶段的指导思想和第一原则。
产品方案阶段，是指为达成需求目的所需要做的事及如何去做。此时输出物的种类非常多，如产品原型、产品需求文档、埋点表、数据需求等。主要作用是帮助项目成员更准确、全面的理解需求，以便更好的实现产品方案，同时也是帮助产品经理更全面的梳理需求，重新验证方案自洽性。
1. 产品思考
1）需求背景及目的
这里借用亨利·福特的“一匹更快的马”故事做一个举例，若用户分别在“着急赶路”和“赌马”的场景下提出，所提供的方案是完全不一样。针对赶路场景，用户希望的是最短时间内到达目的地，我们可以提供“汽车”、“高铁”、“飞机”等比原方案更优的解决方案；针对赌马场景，用户目的就是赢下比赛，仅需提供一匹快马即可。
显然相同描述在不同场景下的目的有可能是完全不一样。产品经理在设计产品方案前一定要先明确背景（背景不仅限于具象化的场景，还有需求之外的“话外音”）及目标，这样可有效避免产品方案的方向性错误。
另外在产品方案阶段出现两个设计方案争议不下时，就要把“目标”拿来出，看看哪个方案对目标有更积极作用，否则坚决放弃该方案。
2）功能定位
很多人听到“定位”这个词会觉得很虚，摸不着头脑。脑花查阅相关资料及请教大佬之后得到初步结论：定位包含两个因素：目标用户和想要解决的问题。这里以微信和陌陌两款社交通讯产品举例。两款产品本质都属于通讯工具产品，但由于产品定位的差异，两款产品所呈现的调性是截然不同。
3）限制因素
任何需求都有一定限制因素，如上线时间、开发资源、技术架构、行业合规等因素限制。通过明确限制因素可以确保方案的可行性及适当性。
接着上面的“赶路场景”举例说明：若用户是准备从深圳赶往北京，那可选择“高铁“、“飞机”等出行方式，如果不考虑成本因素，甚至可以选择“私人飞机”的方式（这是不可能的）。
都说产品经理是CEO的学前班，那产品经理和CEO之间又有哪些异同点呢？首先共同点是两个岗位都是重决策的岗位，他们做任何决策都会影响到全公司或项目组成员。差异点是在资源上的差异，老板拥有全公司的资源，而产品经理只能是靠人格魅力去争取资源了。所以说产品经理就是带着枷锁进行决策。
产品思考阶段的工作对产品方案的具有指导意义，决定着产品方案是否能有效解决需求，脱离产品思考基础行产品方案设计是没有意义的。所以接到需求时，先不要着急动手去画原型、写文档，而是先把需求背景、目的想清楚，确认功能的定位后，再开始原型和需求文档的工作。
2. 产品方案
1）前提条件
前置条件：触发该流程的前提条件，如查看微信好友列表的前置条件为“注册且登录微信账号”；
数据来源：流程中数据来源，如审核功能中：审核人员审批审下级发起的审核单。审核人员的操作流程中，下部发起审核产生审批单就是审核人员的操作流程中的数据来源；数据来源通常是在发生数据流转的场景下需要进行说明。
角色及权限：即用户在系统中承担的作用的抽象，C端角色通常是由产品经理和运营人员一起来定义的，并将角色和账号进行绑定，B端业务相对复杂，往往是设定“超级管理员”账号，然后将权限管理产品化，让运营人员自定义角色。关于权限管理功能设计大家可自行查阅资料，这里不过多赘述。
2）操作流程
事件：主要是指功能的交互规则及逻辑判断。这个模块用来说明用户和系统之间发生的交互。交互规则是泛指的交互规则，包含功能的页面布局、触发功能的动作及触发后的交互效果；逻辑判断则是指当用户在前端发生行为，系统对用户行为进行识别、判断并返回相应的动作的过程。
事件影响：指用户与系统完成交互后，用户和系统会得到什么样的反馈及产生什么样的数据和结果。
异常流程：是对主流程补充，我们尽可能全的罗列并写清楚异常流程时，可以有效避免在产品设计时的场景遗漏。异常流程的梳理建议是参考测试同事的正反例原则。
3）通用说明
数据埋点：埋点就不多进行赘述，但不管是采用第三方系统还是自己的埋点体系，都要做好数据分类，后续提取数据时能减少很多功夫。
数据需求：主要为业务方和产品经理在使用和运营提供决策依据，在设计产品方案时一定要规划相对的监控数据指标，以便于后续运营和迭代时有数据进行支撑。
产品方案阶段，主要是说明产品设计及需求文档输出阶段需要考虑的因素，但更多是起到自检的作用，一定程度上能减少产品经理在输出原型和需求说明文档时遗落逻辑及关键点。
通过对框架的整体说明，相信大家可以比较清晰认知两个阶段作用。在产品思考阶段，是让我们想清楚为什么要做这个功能，应该往哪个方向去做；在产品方案阶段，则是提供一个思路自查原型和需求文档考虑是否全面，需求是否说清楚。
02 总结
可以发现，产品思考阶段没有明确的输出物，也没可量化的标准进行衡量，同时它又占据产品经理的大量时间，而最终的工作成果又都是在产品方案阶段才有所体现，也就导致不了解产品岗位的人，甚至产品“工具人”（曾经的脑花）也会产生这样的认识：“产品经理接收到需求后，照着竞品画原型让开发把功能实现就可以了”。
他们都忽略了产品最核心且无形的工作——思考。正如冰山效应一样，大家只看到水面上的冰山，没看到水面下的山体，但水面下的冰山确实表象上的数倍。
使用思考框架短期内不能给你带来能力明显的提升，甚至会影响工作效率；但从长期而言，它能从思维上帮助我们形成更加体系化、系统化的思考模式，以保证我们的工作是有意义的且相对全面的。
当然脑花整理的框架不一定适合所有人，但请一定要搭建自己的思考模型。因为搭建思考框架的过程本质上是对过往工作的抽象及总结，而这两项能力也是产品经理最基础及核心的能力之一。
本文由 @Jarrett 原创发布于人人都是产品经理。
题图来自Unsplash，基于CC0协议。