超硬干货:如何把需求变成产品方案?

12 评论 25505 浏览 201 收藏 22 分钟

编辑导语:在产品经理的日常工作中,往往需要了解和收集许多的用户需求,那么,如何将这些需求进行分析筛选,然后转化成为一份产品方案呢?本文作者结合自身的经验,从前期准备、方案设计、需求评审三个层面,为我们介绍了如何对需求进行产品化设计并通过需求评审。

在《用户体验要素》一书中说到,产品是由战略层、范围层、结构层、框架层和表现层这5层组成。

而之前的文章中,给大家介绍了做产品要如何贴近用户、如何评估需求的。即从战略层和范围层的角度,去解决问题,定义需求。那在需求明确后,我们又该如何将需求转化成产品方案呢?

这篇文章,将从前期准备、方案设计、需求评审三个层面,给大家介绍下该如何从结构层,框架层和表现层,对需求进行产品化设计,并通过需求评审的。

大家如果有需要的话,可以先收藏,后续设计方案时,再一一核对参考,保证我们在设计方案时,做到不重不漏。

一、前期准备

1. 明确需求目的

目的,是产品方案的指向标。我们通过各种渠道,获得需求后,我们首先要明确,做这个需求的目的是什么,是为了解决什么问题,满足什么需求而出发的。

因为,我们在需求产品化过程中,会产生很多“新点子”。但这些点,是否适合放到产品方案中,就需要我们立足于需求目的,去通盘考虑,平衡投入产出比,输出符合预期的产品方案。

总的来说,需求或版本的目的可分为以下三类:

  1. 用户体验优化:已有功能点优化、增加操作入口、增加功能等;
  2. 提高内部效率:增加内部平台某种能力、给运营增加推广渠道、功能组件化开发等;
  3. 商业化:增加会员模式、增加对接广告接口等。

为了保证产品人对需求有足够的深入的思考,一个版本或一个方案,都只要解决一个主要问题。因此,我们在定义目的时,也要尽可能收拢到一个核心观点上,让整个方案都围绕目的服务。

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. 方案持续性介绍

一般前两点评估通过,需求就是可以落地执行的了。但我在介绍完方案之后,还会补充介绍下后续的运营方案和产品的迭代计划。

一来,可以给开发打个预防针,告知这个功能后续优化的可能性,让他们提高对需求的重视程度;二来,系统全局的描述,也能体现你在产品能力。

每一个产品需求,都是我们展现自己的机会。在职场,只有紧紧抓住每一个机会,我们才有承接更大需求,在产品道路更进一步的可能。

三、写在最后

产品方案,是从用户、问题、场景的视角去切入需求,在更系统的产品层面和更长的时间维度上,全面思考,输出的文档。

以上内容,是我这两年,把写过的大大小小数百个需求,汇总整理出来的。包括目的、背景、产品逻辑、需求边界、原型、数据、需求文档这七点,我将这七点统称为需求落地的“七要素”。

 

本文由 @豆奶 原创发布于人人都是产品经理,未经作者许可,禁止转载。

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 你好,请问方案设计里面的页面流程也需要在需求评审之前进行吗?(我以前以为需求评审是需求经过分析筛选后和小组其他成员确认需求的过程),如果需求都没确定,做页面流程会增加工作量吧?(小白提问哈)

    来自重庆 回复
  2. 请问下怎么看文章内的图片呢

    来自四川 回复
    1. 已更新

      来自广东 回复
  3. 感谢up主的分享,想求一份文章中的图片。

    来自四川 回复
  4. 新产品的落地差不多经历了这些环节:
    用户需求>-产品需求采集 >产品策划 >产品交互设计 >产品视觉设计 >产品页面重构 >产品研发 >产品测试 >产品发布 >需求收集 >迭代

    那从用户需求到原型生成,是怎么抽象到具象的? 就像生活中 盖房子,拿到的原材料都钢筋 混凝土, 产出的高楼却各不同;
    公司餐厅,厨师拿到的原材料是番茄和面,产出的却是番茄臊子面,为啥不是湖汤面。
    就像你在设计工作中, 我觉得研究用户、组织、竞品、政策, 这些都是原材料, 经你输出出原型时,基本就具体化了,我看网称为具象就也这么说了。 张三拿到同样的原材料,输出了臊子面,李四却输出了糊汤面,这个过程发生了什么?

    一段时间里我对这点很是困惑。

    来自河南 回复
    1. 首先,前期对市场和用户调研和分析,除了限定你需求的边界之外,更重要的是给你提供方向。

      就跟你说的盖房子一样,拿到的都是钢筋、混泥土,但想让你盖房子的人会告诉你,他有多大的地,想盖几层楼,一楼是门店,二楼是客厅和厨房,三楼是住人等等…

      在了解到这里的边界和主方向后,产品经理做的事就是把这些需求都收拢起来,变成【能解决需求】的可行的方案。

      在这个过程中,主要是根据你对人的认知,对生活的理解,输出能解决需求的方案。

      这也是产品经理的价值的体现,我这里能提供的建议就是,用流程图去梳理能解决需求方案。

      而在如何具象化过程中,以我当前的认知,确实没有能够具象到,究竟该用什么样方法去设计出“最好”的方案。

      但不可否认的是,不同的产品人对需求的认知有偏差,对生活和人的感受不同,输出的方案肯定也是不一样的。

      就跟不同建筑设计师,盖出来的房子也是不同的一样。

      同理,如果我们设计微信朋友圈模块和张小龙设计的也是不同的。

      可没有人在一开始就敢保证我们做的就一定是错的,小龙做的方案就一定是最好的,最正确的方案。

      所以,最终的方案一定要经过市场的验证。现在的朋友圈也是小龙团队在几十种方案中,选了相对满意的方案,上线的。

      所以,这也是原型画完之后,要尽可能让团队的人一起来评估,以获得不同视角的调整建议,并且在上线后,也需要持续观察市场反馈,进一步持续迭代和优化。

      最后,总结一下:前期调研明确好边界和方向,然后从解决问题的角度去设计方案,最后观察反馈,持续优化需求。

      只能从这三个层面去尽可能保证需求,能够符合市场预期。

      不知道,我这么解释,能否解决你的困惑。

      来自广东 回复
    2. 是的,可以解惑的。 “配方”已收到 ,谢谢。

      来自河南 回复
  5. 感谢分享💛💛

    回复
  6. 辛苦了,给你点赞

    来自江苏 回复
    1. 感谢支持~

      回复
  7. 写的很好

    来自湖北 回复
    1. 嘿嘿~感谢支持~

      回复