编辑导语：产品原型可以帮助产品经理将想法具象化为一定的效果，但是在设计产品原型之前，产品经理应当先明确相关背景，找准最终目标，做好相应的信息收集等。本篇文章里，作者对产品经理在设计方案前应当做的事情和步骤做了总结，一起来看一下。
产品设计是产品经理的基本功，但很多人其实基本功都没有练好。
先不说产品做事的核心逻辑是先决策要不要做、能不能做、如何做、如何做好。即使对于一个确定的事情，不少人可能处理得也不是很好。
有人可能上来就画原型，然后方案考虑得不周全，被各方diss，有人可能先梳理流程，然后给出相对比较完整的解决方案，有人可能会再多考虑几个解决方案，选择相对优的解法。
说实话我之前的流程也是先需求分析，然后竞品调研、梳理流程、给出解决方案。
我最近思考下来觉得这套流程虽然没什么问题，但不够系统，也少了点东西。
我现在的想法先搞清楚背景和目的，然后把目的转化成目标和指标，在收集内外部相关的信息之后，再基于要达成的目的去考虑具体的方案设计。
一、明确背景和目的做事先问目的，先把背景和目的了解了，再去考虑具体的实现手段，因为目标不同，后续的路径、动作可能完全不一样。
比如你的上司跟你说，我们下个版本做个抽奖吧，你花了一个礼拜去做调研，做产品方案，结果有可能你上司跟你说这完全不是我想要的啊。
如果你在收到这个需求的时候多问几个问题，可能就是完全不同的结果了。
比如你问：我们是出于什么考虑想做这个功能啊，最终想达成什么效果呢？
可能你的上司说：我们最近老用户活跃度降低，所以想针对用户活跃做个抽奖，刺激用户产生一些关键行为；或者是我们的用户虽然持续在付费，但整体ARPPU较低，希望提升一下。
你看两个不同的目的，对应的后续动作其实是完全不同的。而且上司口中的抽奖，其实是解决方案，不是问题本身，知道目的是什么，你才能判断怎么做，以及有没有更好的方案。
有2个工具可以帮助大家来明确目的，一个是5Why，一个是What-Why-How思考。
前面那个就是多问几个为什么，后面那个就是别人让你做什么的时候，先了解一下为什么要做，要做什么，最后才是怎么做的问题。
二、确定目标并拆解当知道做事的目的之后，后续就是看怎么达成这个目的了。
我们需要先把目的转化成具体的目标，然后尽可能地把目标拆解，并且量化。
今年是我党建党100周年，我党的目标是全面建设社会主义现代化国家，那怎么建设，建设到什么程度？
在“十四五”规划中，可以看到这样一些衡量类别，经济发展、创新驱动、民生福祉、绿色生态、安全保障。
以经济发展为例，又细分了GDP增长、劳动生产率增长、常驻人口城镇化率这些指标。
素材来源于互联网
全面建设社会主义现代化国家是大的目标，下面又细分了若干个小的目标，每个目标又有对应的衡量指标。
举我们国家发展规划的例子，是因为这是我能想到的最复杂、最庞大的案例了。一个国家的发展尚能够把目标进行拆解，并且量化，你做的事情有比国家发展规划更复杂么。
这部分有2个思考方式可以借鉴，一个是系统思考，一个是量化思考。
- 系统思考，就是找到所有的要素、关系，然后对所有关联的部分进行量化，比如我党的规划。
- 量化思考，就是先构建出来量化公式，然后拆解相关联的指标，不断细分。比如：
- 利润=收入-成本；
- 收入=DAU*登录率*付费转化率*ARPPU。
然后再不断拆分各个指标，直到不能拆分为止，后续再提升单个指标。
三、收集信息不少人在收到需求之后很快就去考虑解决方案去了，实际解决方案是输出的结果，当你输入足够多、质量足够高的信息的时候，解决方案可能自动就出来了。
1. 内部信息
这部分其实主要就是用户信息、数据信息、业务和产品信息、限制条件这些。
用户信息其实就是明确我们是想解决什么人在什么场景下的什么问题，解决之前是怎样的，解决之后又会有什么价值。
数据信息主要是数据现状，基于目标拆解部分得到的数据公式、核心行为漏斗，先看目前整体的数据情况，再细分查看，看分行为、分人群、分渠道、分新老、分版本等维度下有没有什么异常。
业务和产品信息主要是看功能的上下游，关联模块、历史迭代情况，更充分地了解和定位问题。
限制条件主要是为了解决这个问题，我们能投入多少资源、多少时间，以及有没有什么业务或者技术上的限制。
比如有些看起来不错的方案，为什么当时没有做，是有业务上的限制，还是技术上的限制，还是有什么历史遗留原因，先确认清楚，避免后续发现挖了个大坑。
2. 外部信息
其实就是主要看要解决的问题，市面上是怎么解决的。
在不知道怎么做的时候，先去看看别人是怎么做的。如果知道怎么做的，可以看看有没有更好的解决方案。
这部分其实主要是竞品调研，先明确调研的目标，选择合适的竞品，最后是调研，并得出结论。
要详细调研的是要解决的是什么问题，具体怎么解决的（业务流程、产品流程、产品功能），解决得好不好（用户行为、数据表现、用户反馈），需要什么关键资源，以及我们该如何处理？
四、方案设计导入了那么多，终于到方案设计这块了，主要分这么几部分：
- 牢记目的》目标》指标；
- 梳理整体业务；
- 明确核心路径；
- 功能设计 MVP；
- 运营计划；
- 原型、文档。
下面来分别看下。
1. 牢记目的>目标>指标
这部分就不用再赘述了，我们做这个事情就是为了服务最开始的目的、目标，千万别忘记了。
千万别做了一堆东西，最后发现跟目标没什么关系，目标明确了，才能取舍后续的优先级。
2. 梳理整体业务
首先要明确的是业务关系，我们要做的事情，在整个业务中的地位是怎样的，能贡献的价值是怎样的，这有助于我们自己分清楚在做事情的优先级。
其次是梳理清楚业务流程，这部分的产出物就是流程图，很久之前写过一篇流程图的文章，可以看下。
3. 明确核心路径
这部分就是为了满足用户的需求，需要做的事情，一部分是用户自己需要做的事情，一部分是为了满足用户需求，我们需要做的事情。
以直播电商为例，用户最终是在直播间下单并收到商品，为了支撑整个流程，我们需要做很多事情。
核心路径明确之后，我们才能知道，哪些是关键点。
4. 功能设计 MVP
在上面的核心路径部分，有一些东西是需要我们产品经理们进行功能设计的，整体设计流程是：
- 先梳理清楚模块结构（产品架构）；
- 然后整理功能树（功能清单）；
- 之后绘制页面流程；
- 最后别忘了数据设计。
模块结构，指的是有哪些功能模块，模块之间的关系是怎样的，以及有没有涉及到其他模块。
功能树，指的是相关的功能点。先发散，再收敛，再聚焦，找到优先级最高的功能，最关键的点，重点关注。
页面流程，指的是页面之间的关系、流向。
这里需要注意的是，我们上面所有的工作都是基于主观臆测得出来的结论，可能正确也可能错误，所以我们整体需要基于MVP的原则来进行验证。
比如我们需要验证的核心假设是什么，达到什么标准能证实或者证伪这个假设？
比如我们能不能把整体功能拆成几步进行验证，先验证比较核心、风险比较高的需求，然后再进行后续迭代？
比如我们目前的产品方案是不是验证成本最小，验证周期最短的方案？
功能性需求处理完之后，千万别忘了数据需求，我是真的见过不少产品经理在功能上线后啥啥数据都没有。
- 首先我们需要明确我们要看什么指标，计算规则是怎样的；
- 其次是提相关的数据埋点需求；
- 然后是数据的统计规则、上报规则，上报周期、数据回收周期（实时、小时、天、周等）；
- 最后是数据的展现形式，是一次性取数，是邮件报表，还是数据看板等。
5. 制定运营计划
很多时候产品功能是需要叠加运营计划的，需要结合具体的功能来看是否需要运营计划，以及需要什么样的运营计划。
最终和相关小伙伴确定好对应的人、事、物和时间点。
6. 绘制原型、撰写文档
这部分就是我们经常说的画原型，写PRD文档了。
方案设计差不多就这些，后面是方案如何落地了，包括需求评审、项目排期、开发测试、上线、复盘&迭代这些了，有机会的话后续再单独写篇方案落地的文章吧。
五、最后千万别一上来就画原型，这样的方案很可能被推翻很多遍，最后也没达到想要的效果，先想清楚，再动手。
最后简单回顾下文章，产品经理的思考方式是要不要做，能不能做，如何做，如何做好。
在假定要做的情况下，可以按照这样的流程来进行方案设计。
首先明确背景和目的：
其次是确定目标并拆解：
系统思考 公式量化。
然后是收集信息：
- 内部的：用户信息、数据信息、产品和业务信息、各种限制条件；
- 外部的：最佳实践。
最后是方案设计：
- 梳理整体业务；
- 明确核心路径；
- 功能设计 MVP：先梳理模块结构（产品架构）， 然后整理功能树（功能清单），之后绘制页面流程， 最后千万别忘了数据设计；
- 制定运营计划：确定方案 人事物 时间点；
- 原型、文档。
以上，就是本文的主要内容，欢迎斧正、指点、拍砖…
#专栏作家#
王家郴 ，公众号：产品经理从0到1，人人都是产品经理专栏作家，喜欢网球和骑行的产品汪，目前奔走在产品的道路上，漫漫产品路，与君共勉。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
