分享

从需求到功能,B端产品设计四步法

 一叶知秋6012 2022-08-28 发布于北京

一个 B 端产品经理自身产品设计的质量和效率,直接决定了项目的结果与效率。但很多人一开始并没有这样的经验,缺乏相对统一的思考框架及能力体系,难以快速输出产品设计。作者结合自身经验,总结了 B 端产品设计四步法,帮助你少走一些弯路。

之前在公司《产品学习小组》会上,我们讨论过一个话题,就是产品经理有没有相对统一的思考框架和能力评估体系。

结果,各个方向的产品负责人都有一个共识:就是技术的培养和评判标准,相对成体系一些,但是对产品经理来说,就会变得不太容易。

一方面是因为产品细分的方向比较多,另一方面产品跟业务走得近,相对属性也会离散一些。所以就导致了产品的成长环境和路径都会带有非常强的个人色彩。

不过最终,产品出身的 BOSS 还是传授给我们了一套他沉淀方法论—— ' 万能产品五步法 ':① 用户 – ② 需求 – ③ 场景 / 路径 – ④ 痛点 / 诉求点 : ⑤ 解法

算是在宏观上,把产品分析的过程有了一个框架的抽象。

经过学习演练,我也深受其益,一直在使用。

不过这个模型,我发现有一定的使用范围。那就是比较适合于用户比较确定且相对独立的,C 端适用性更强,或 B 端某一个特定用户在限定场景内。

那如果是一个完整的 B 端产品,涉及到非常多用户角色参与并相互协作,那就会需要另外一些方法来补充。

我觉得本质上,C 端产品操作或 B 端在特定场景操作,是一个使用需求;但对一个完整的 B 端产品,各个用户角色的使用更像是一个过程,他们共同协作操作完成的那个结果,才是 B 端产品本身的需求达成。

今天,我就尝试来聊聊,B 端产品设计的思考框架。

PS:以下文章内容,我们重点讨论 ' 产品设计 ' 环节的一些方法。我们假定产品设计对应的需求价值分析没问题,产品决策已经做过了。

不知道,大家在日常工作中会不会遇到这样一个现象?

一些人接到一个需求后,马上就会开始进入到功能设计:流程图画系统流程,xmind 列功能清单,甚至直接 axure 开始画交互页面。

在这样的操作下。大概率在需求评审环节、开发环节甚至上线后,他会遇到以下情况:细节遗漏、忘记协同其他部门进场、遇到无法解决的技术 / 资源卡点,最终导致项目不断返工、延期,甚至停工。越大规模项目,问题会越严重。

在我的实际工作中,我也遇到很多以上这样的情况。到最终,可能一个人需要很多项目的血泪经验,才能慢慢做得成熟一些。

B 端产品的基本面,是讲究产品可用性的,各个链条环节的问题,都会影响最终结果。

这也是 B 端产品要求重逻辑和专业性的原因。

所以,一个 B 端产品经理自身产品设计的质量和效率,直接决定了项目的结果与效率。

那么,在 B 端产品设计中,有没有一些像产品五步法一样的方法,能指引产品设计,让大家少走一些弯路呢?

过去一段时间内,我自己在部门内也做一些论证,也提炼了一套我认为比较有效的方法,我称之为 'B 端产品设计四步法'。

接下来,我们按步骤讲解下:

一、拆需求(用户 ->场景 ->需求)

一个最小的子需求,应有 3 个要素组成:用户 ** 在 ** 场景下的 ** 需求。

那一个完整的大需求,就需要 N 多个子需求所组成。

但是,一个人如果想要直接面向子需求颗粒度去分析,对于大项目复杂项目,基本是不可能完成的任务。

在这里,我建议大家使用「角色 × 流程」象限图表法

按照这个框架,我们需要依次代入每个用户的视角,来穷举不同用户在不同场景下的需求点。

PS:场景 1、2、3、4,尽量按照信息流的时间线顺序(大概率是可以的)。

注意,在这个环节大家不要考虑任何系统功能和实现,就用白话来描述需求点。因为后边有其他步骤来做转化的事情。

按照以上的原则,把各个象限表格填写完成。

完成第一遍之后,还需要继续第二遍,第三遍的 review。

在后边的每一遍检查中,可以尝试按不同流程(例如场景中包含的信息流、资金流、实物流等等)、按不同用户(例如按照用户生命周期时间线)来交叉比对信息。

串联时候,一定要做到保证逻辑(不是系统逻辑,而是自然逻辑)自洽。

读到这里,有人可能会问:这个象限图表,看起来不就是多个用户在驱动一个流程场景变化,能不能就是一个流程图来呈现呢?

大部分场景下,是不能等同的。

严谨来说流程图更多是单一主线随时间变化的呈现,但是这个图表中,其实会包含更多个流程图,例如上边说的信息流、资金流、实物流等等。

另外,还有一些前置准备信息、后置信息,都跟流程没太多强耦合关系。画成流程图,特别容易遗忘这些需求点。

第 1 步「拆需求」,是产品设计最重要的一环,这个环节有偏差,后边几个环节都要跟着重新返工,会影响整体项目效率。所以,大家一定要在这个环节多花一些功夫。

二、需求转译事件

当第 1 步完成之后,我们就会得到不同用户一个个明确的需求点。

那么第 2 步,我们就侧重于需求怎么达成,这里给一个公式。

一个需求的结果 = 事件 1+ 事件 2+ 事件 3+ ……

其中,事件 X= 用户 ** 通过 ** 做 **

一个事件,可以是一个页面的按钮点击,也可能是一个逻辑的执行,也可能是一个 sop 的执行等等。

注意,不同事件之间,可能有先后顺序或依赖关系。

在这一步中,因为是事件视角,就要关心能不能达成的问题,尤其是一些核心卡点。看哪些事件的完成,依赖外部、依赖资源、依赖技术可行性等等。

理论上,在这一步,就需要大面上确定各个事件的可行性。如果是关键环节不能达成,那就要寻找替代方案,如果找不到,那基本上也就不能继续往下走了。

不少人,就是在这个环节内,没有对关键环节做论证,导致详细方案出完才发现有卡点,需求做不了。

我自己的经验,第 2 步完成之后,才能去做项目立项。

三、事件模块化聚合

第 1 步是按照用户视角。

第 2 步也是按照用户视角和功能视角。

完成前两步之后,所有需求都被事件转译,接下来我们需要收敛一下功能点。

大家发现一个事件的元素组成是:用户 ** 通过 ** 做 **,这里面通过 '**' 这个对象,更多就是领域模块。例如交易订单、促销、支付、清结算、业财、物流等等,当然这个模块颗粒度可以更粗也可以更细,大家根据实际情况来决定即可。

这个步骤的主要作用,就是将离散的功能点所需要的承载体,聚类聚合。

因为需求最终落地的最细划分会到模块,而模块一般情况其实跟岗位职责是对应起来的。例如 A 同学考虑 A 模块的设计,B 同学考虑 B 模块的设计。

另外,功能点聚类之后,也能一次性 get 到大需求内所有对单模块的影响点,便于一次性分析,省得来回倒腾。

四、详细设计

完成以上 3 个步骤之后,其实产品设计的主要工作基本就完成 80%。

剩余的,就是如何落地到具体细节设计和描述。要不就是新增一个能力,要不就是改动一个能力。

详细设计的对象,可能是页面的交互、一个自动脚本、系统校验逻辑、线下 SOP 等等。

产品设计一定要结合现在系统的现况。一方面是现在系统的逻辑,另一方面是新能力叠加已有能力的成本。

这个环节会用到专业知识和设计经验,每个人情况不同,我默认大家这个环节已经比较熟练,不再赘述。

不管如何,如果前面几个步骤做得比较扎实,这个第 4 步我觉得问题不大。因为到这个步骤,技术已经完全跟产品站在同一个起跑线了,会 ' 补位 ' 或 ' 掰扯 ' 产品功能如何实现的。

本文由 @减形简远 原创发布于人人都是产品经理,未经作者许可,

题图来自 Unsplash,基于 CC0 协议

查看原文

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多