超硬干货：如何把需求变成产品方案？
在《用户体验要素》一书中说到，产品是由战略层、范围层、结构层、框架层和表现层这5层组成。
而之前的文章中，给大家介绍了做产品要如何贴近用户、如何评估需求的。即从战略层和范围层的角度，去解决问题，定义需求。那在需求明确后，我们又该如何将需求转化成产品方案呢？
这篇文章，将从前期准备、方案设计、需求评审三个层面，给大家介绍下该如何从结构层，框架层和表现层，对需求进行产品化设计，并通过需求评审的。
大家如果有需要的话，可以先收藏，后续设计方案时，再一一核对参考，保证我们在设计方案时，做到不重不漏。
一、前期准备
1. 明确需求目的
目的，是产品方案的指向标。我们通过各种渠道，获得需求后，我们首先要明确，做这个需求的目的是什么，是为了解决什么问题，满足什么需求而出发的。
因为，我们在需求产品化过程中，会产生很多“新点子”。但这些点，是否适合放到产品方案中，就需要我们立足于需求目的，去通盘考虑，平衡投入产出比，输出符合预期的产品方案。
总的来说，需求或版本的目的可分为以下三类：
- 用户体验优化：已有功能点优化、增加操作入口、增加功能等；
- 提高内部效率：增加内部平台某种能力、给运营增加推广渠道、功能组件化开发等；
- 商业化：增加会员模式、增加对接广告接口等。
为了保证产品人对需求有足够的深入的思考，一个版本或一个方案，都只要解决一个主要问题。因此，我们在定义目的时，也要尽可能收拢到一个核心观点上，让整个方案都围绕目的服务。
2. 了解需求背景
不论多大的公司，多大的团队，在产品的发展阶段，资源都是不够用的。此时，论证需求必要性，提高需求实现的优先级，就非常重要。
而了解需求背景，我们首先找到需求第一来源人，并通过以下两点，来论证需求必要性：
1）数据论证
通过调查，从数据层面，来论证需求的紧急性和迫切性。
如：用户体验优化，可以用用户投诉量来论证；内部平台能力和商业化需求，可以用上线多久后提升多少收益，或估算投入产出比（ROI）来论证。
2）竞品调研
若市面上有同类产品已实现该需求，这也可以侧面论证需求实现的必要性。所以，我们可以通过调研的方式，梳理的功能流程图，并从用户、需求、场景三要素进行分析，看竞品是否满足需求的，又是如何满足需求的；
但在实际工作中，系统的竞品调研，其实比较少做，主要是比较耗费人力，后续有机会的话，会专门写一篇文章来给大家详细介绍，这里就不过多描述了。
可虽说我们比较少做系统的调研，但我们在平时的工作中，也会关注竞品每个版本新增的功能模块。分析后，若发现竞品的新功能是符合用户需求的，我们也要及时跟上。
二、方案设计
在明确目的，了解背景后，我们进入产品方案的设计环节了。即下列内容，将正式从结构层，框架层和表现层的角度，和大家介绍该如何把需求，进行产品化方案呈现的。
而这个环节的最终目的，是要我们输出完整产品方案，接下来我将从五个步骤来跟大家进一步介绍：
1. 逻辑梳理
在做需求时，很多刚入行的产品，接到需求后，就直接就开始画原型，这个是错误的。因为，画原型，是产品方案已经确定，产品流程无明显纰漏，需求边界已经明确后，才开始执行的工作。
否则，后续评审或开发过程中，会出现因方案不够严谨，出现多次返工的情况。不仅降低我们自己的工作效率之外，而且还可能影响产品的迭代节奏。
所以，在画原型之前，首先我们要先梳理两个核心逻辑：
1）产品方案逻辑
产品方案之所以被称之为“方案”，因为它是从宏观的系统角度，可持续迭代的层面切入需求，且通常需要多角色配合的。
如，为了减少用户投诉而做的产品方案，就要从客服、用户、运营、产品这四个层面，告知各方在不同的版本后，需要支持和协助的工作是什么。
因此，我们在梳理产品方案时，要关注不同角色的所面临的问题，如何持续观察优化的角度去通盘思考。
我们可以从第一用户要执行的动作入手，进行逻辑推演。如下图泳道图所示，我们如果要开发一个给客户提供线上下单的平台，就可以从要发货的客户下单的动作入手。
客户下单之后，订单数据应该被哪个下游角色所接收，接收之后，下游角色还需要哪些角色配合支持，以此来不断往下延伸拓展。
在梳理清楚之后，我们再最终把所有角色的交汇场景通过泳道图的样式呈现出来，明确各个角色要支持整个产品方案的具体工作，最终输出产品方案的流程图。
2）页面流程
页面流程是从微观产品功能层面的逻辑梳理，是包含在产品方案中的某个产品能力。常用于大小功能点优化，版本升级中某功能点的梳理。
如：上面的客户下单、受理、创建单的场景，客户是如何在什么页面，点击哪个模块下单的，受理部门受理之后，又是如何创建运单的，把这些页面的具体操作流程一一细化梳理出来。
如果是功能点优化，可以从用户和数据交汇核心页面出发，梳理页面流程。
如果是独立的功能或产品版本，可以先从功能入口出发，思考各页面中用户是谁、解决的需求点是什么、产品如何解决需求的，并且后续还要考虑数据流转情况。
这里的用户是包括所有使用产品的角色，可能有运营、客服、销售、领导层、运营、开发等。当然，如果需要呈现多角色的使用流程，同样可以利用泳道图的方式来呈现。
如果竞品有类似的功能，我们也可以参考竞品的页面流程，但注意，我这里说的是“参考”，不是“照抄”。产品人要以满足用户的需求来思考方案，面向用户场景来设计需求，解决用户问题为最终目的。
3）注意事项
（1）工具无优劣
就跟吃饭用筷子还是用勺子的一样，选择适合自己的就行。因此，不论是泳道图、流程图、还是简单的线框图，只能能清晰地描述逻辑即可。
（2）方案多选择
在思考方案时，肯定会有多个方案，多种场景，如果出现难以判断孰优孰劣，可以输出多个方案。在内部讨论或向上汇报时，陈述不同方案的优劣势，让大家一起讨论决策。
以免出现单方案不通过，要重新思考，降低工作效率。
（3）善于求助
工作是要解决问题的，不是来体现你个人能力的，这也是你们之所以称之为“团队”的原因。如果遇到自己确实无法解决的问题，要及时向同事或上级同步困难，寻求帮助。
（4）流程多讨论
在方案梳理时，要和需求涉及的团队多沟通，尤其是开发，保证方案切实、可行；在梳理完成后，要尽快在团队内部和领导过一遍，以保证产品逻辑无太大纰漏再执行下一步。
千万别偷懒，也别怕麻烦，毕竟，很少有人能够独立的把整个方案都思考得很全面。前期的每一步繁琐，都是为了避免落地时的返工。
2. 确定边界
在确定核心流程之后，需要进一步细化方案，确定需求边界。主要是补全流程中异常情况和应对策略，尽可能做到，既节约资源，又拥有好的用户体验。
在补全异常流程时，我们主要关注四个问题：
1）平衡：注意平衡用户体验与开发工作量的关系
在实际工作中，工作量和用户体验是成反比的，体验越好的模块，工作量越大。所以，产品的工作要从需求目的出发，寻找双方的平衡。该如何取舍，取决于产品发展情况、市场情况、产生命周期和产品自己的工作经验。
如果遇到难以决策或解决的问题，要及时向上汇报，寻求帮助。
2）安全：资金安全和用户安全问题
新版本的微信，红包功能就调整了红包个数和金额的位置，导致有大量的用户导致资金和金钱输入错误，导致用户投诉。
因此，如果需求涉及资金、用户信息等问题，要慎之又慎。产品文档在进入评审会之前，最好多过几轮，以求万无一失。
3）复用：组件化开发
如果功能模块后续可能被其他需求所复用，为节约开发成本，可以与研发多沟通，看是否可进行组件化开发。
如：banner广告可能可以在其他页面复用，但当前版本仅支持首页的应用即可，就可以进行组件化开发，后续其他页面如果需要的话，就可以直接复用。
4）便捷：配置性功能开发
如：banner的内容后续需要经常更换，为了减少后续反复发版，影响线上功能，也可以和研发多沟通，看能否进行配置性开发。
这也是节省了研发后续的工作量，你跟他提，他会比较乐意帮助你的。
3. 原型设计
原型设计是在框架层，来思考和设计产品的。前面的逻辑和需求边界都确定的话，这一步其实可以让交互设计师来支持，尤其是业务推进比较忙的时候。
但并非所有公司都有交互设计师，如果没有的话，这一步还需要自己来实现。画原型的具体操作，就不多讲了，如果是刚入行或准备入行的小伙伴，想学的话，可以报个班学一下Axure或sketch。
不用太精通，只要能把想要的页面，简单的还原出来，设计师和开发都能看懂，就已经足够了。在这里我讲一下几个避坑指南：
1）原型分版本保存
我刚做产品的时候，原型都是直接覆盖上一个版本的。但后来，评审会的时候老大提出要加什么功能，我突然想起这个功能在之前一个版本做过，但想找回来，却发现版本已经被覆盖，找不到了…
2）原型有注释
如果原型没注释，就跟上课不做笔记的后果一样，很容易一转头就忘了。而且不在原型中注释的稿件，如果给开发或设计执行时出错了，最后吃亏的还是我们自己。
3）异常情况定义清楚
除正常的注释之外，异常情况也需要在原型中定义清楚。
因为，有些开发在开发时，不一定会时刻盯紧文档来看。所以，除了文档中要说清楚异常情况的设计标准之外，最好在原型中也要注释清楚，也是为了避免后面出现问题时，相互扯皮。
4）需求修改及时备注
如果需求在评审或开发过程中，有变更的情况，除了在文档中备注之外，原型中也需要及时变更。
以上内容，都是我用血和泪给大家总结的经验教训，我刚入行的时候，因为偷懒，很多地方没有做好，当时背过很多锅，所以希望大家，千万不要再重蹈我的覆辙了。
4. 建立数据反馈
一个好产品人，是会从更高的产品系统的层面，思考和解决问题的。
因此，为了更好地验证目标的达成与否，我们需要建立数据反馈机制，给产品方案提供统一的衡量标尺。我们团队建立数据反馈主要是通过两点：
1）埋点
C端的功能型需求，是可以通过用户反馈来迭代的。但除此之外，我们还要增加当前功能点的埋点，为产品后续优化提供更严谨的理论支持。
如果是刚上线的基础功能，还未确定明确的业务指标，可以只增加基础埋点。如：产品页面曝光pv、曝光uv、点击pv、点击uv等。
将埋点数据统一上报到数据平台中，定期观测数据表现情况，以便优化后续产品。但如果是有上线有一段时间的产品，我们要从业务指标衡量标准出发，对产品数据埋点，进行二次或三次的拆解。
也可以参考前面的页面流程图，一般来说，有需要判断的地方就要有埋点。我们只有知道每个节点数据流向，后续才能建立数据模型，分析用户操作。
2）异常监控
产品要经常主动观察数据表现，但人力有限，我们无法做到24小时实时盯着数据。所以，若功能中有影响用户核心操作的功能点，还需要让研发帮忙建立异常监控，以保证产品核心流程能够满足用户正常使用。
如：我们团队就有通过微信的开放能力，建立告警机制，一旦某个商家出现问题，就会出现如下图所示的告警通知，以便我们的产品和开发团队能快速发现并处理问题
这也是技术团队在沟通方案时，要和技术一同关注的风险点。
5. 需求文档
在全面思考以上的四点后，我才会遵循以下呈现方式，将它们统一收拢到文档中，形成完整的产品方案。
首先，在文档开头，描述背景和目的，最好用调查过的数据，来论证需求实现的必要性；其次，将产品原型或交互设计稿放到需求模块，要图文结合，让文档的阅读者能够清晰地知道每个功能点，具体需要做什么。
如果涉及多端支持的需求，我会从支持端的角度来陈述需求。即前端要做什么，后台要做什么，数据要做什么，支付要做什么。
然后，把接口文档、原型、交互稿、设计稿等相关附件，都附在需求文档中，以免遗失；最后，再补充一点，如果文档有变更，要及时，立刻更新到文档中，同步给各方，避免背锅。
我的习惯是在开头用红色加粗字体，描述修改的需求点和修改日期。
三、需求评审
当完成上面所有内容后，我们的需求才可以进入到需求评审阶段。需求评审的目的，是为了论证需求执行的必要性，方案落地的可行性，同时给要支持需求的各方，都能够了解产品方案具体需要大家做什么。
所以，为了让产品需求顺利通过评审，我们要从评审目的出发，逐一打消评审方的疑虑。
1. 需求必要性评估
评审一开始，就要先陈述目的和背景。这里前面也讲过，要用数据来论证需求必要性，调查的数据必须要足够合理且严谨，才能有效通过评审，并拔高需求优先级。
2. 方案可行性评估
介绍完目的和背景，获得评审各方的认可之后，就可以和大家介绍解决问题的需求方案，和数据埋点情况。
在陈述方案环节，我也遇到过需求被直接打回的。出现这种问题，可能是前期产品逻辑有问题，又或者是产品方案没有和开发充分沟通，最终设计出不适合落地需求。
但一般能到评审会的需求方案，都通过了产品内部的评估，基本没什么方向和逻辑上的问题，除非是自己偷懒。而技术层面能否通过评审，就依赖于我们在前期设计方案的时候，是否能多和开发沟通，明确技术细节，以保证方案是可以落地的。
3. 方案持续性介绍
一般前两点评估通过，需求就是可以落地执行的了。但我在介绍完方案之后，还会补充介绍下后续的运营方案和产品的迭代计划。
一来，可以给开发打个预防针，告知这个功能后续优化的可能性，让他们提高对需求的重视程度；二来，系统全局的描述，也能体现你在产品能力。
每一个产品需求，都是我们展现自己的机会。在职场，只有紧紧抓住每一个机会，我们才有承接更大需求，在产品道路更进一步的可能。
三、写在最后
产品方案，是从用户、问题、场景的视角去切入需求，在更系统的产品层面和更长的时间维度上，全面思考，输出的文档。
以上内容，是我这两年，把写过的大大小小数百个需求，汇总整理出来的。包括目的、背景、产品逻辑、需求边界、原型、数据、需求文档这七点，我将这七点统称为需求落地的“七要素”。
本文作者 @豆奶 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
