方法论如何用(通用方法论)

从0到1设计一款B端产品,分不开两个阶段,一个是整体设计阶段,另一个是详细设计阶段。其中都有哪些工作需要准备,一起来看看作者是怎么说的,希望对产品初学者、一直在做产品功能设计的产品人带来帮助。

方法论如何用(通用方法论)(1)

几天前,跟两个工作5年以上的产品经理聊产品设计。令我惊讶的是,他们居然不清楚B端产品的设计分为两个阶段,一个是整体设计阶段,另一个是详细设计阶段。

分析原因,大概是因为他们一直在基层岗位拧螺丝,接触的都是详细设计阶段的内容,对整体设计不熟悉也就不足为奇了。这就是在大厂拧螺丝的弊端吧。

有感于此,我才准备写本篇文章,从整体上介绍如何从0到1设计一款B端产品,并努力做到图文并茂吧。希望能对产品初学者、一直在做产品功能设计的产品人有一些帮助,让他们从更高的视野来看待产品设计这件事。

文章较长,目录如下。

一、第1次业务调研

在决定好做某个方向的产品,并联系好调研的客户之后,就开始了第1次业务调研。

这里有一个常见的误区,认为业务调研是一次完成的。实际上,由于B端产品涉及的业务较为复杂,所以,业务调研往往不是一次就能完成的,通常需要多次调研。

多次调研并非随意调研,而是按照由上至下、由大致小、从粗到精的顺序进行调研。就像剥洋葱一样,从业务框架开始一层一层剥,直至业务细节。

1.1 调研前的准备工作

由于是第1次业务调研,也是第1次与客户接触,所以我们需要给客户展现我们的专业性,让客户信赖我们,让客户相信我们。所以,在第1次业务调研前,需要了解行业里通用的业务模式。在与客户沟通交流的时候,能够与客户平等对话。

比如,客户想做一套自己的电商系统,那么在去客户那里调研前,我们需要搞清楚通用的电商业务模式。

1.2 调研的目的

第1次业务调研的目的如下。

  1. 明确业务范围;
  2. 梳理客户的业务现状;
  3. 了解客户业务的痛点和问题,以及客户的期望。

1.3 调研哪些内容

由于我们已经知道通用的业务模式,所以调研的重点就放在客户个性化的业务上,如此可以减轻我们调研的负担。

具体来说,需要调研的内容包括:梳理整体业务流程、明确客户的痛点/问题以及期望,了解客户的组织架构

1.3.1 整体业务流程

由于本次调研的目的之一是明确业务范围,所以不用调研业务细节,只需要弄清楚客户的整体业务流程。

一般来说,整体业务流程需要达到的细度是,能够表达出各参与方在哪里做什么事情。换句话说,就是搞明白三要素:参与方、现有业务系统、各参与方在业务系统中的业务活动。

我们以某电商的业务为例,说明整体业务流程,如下。本篇文章后续的例子,将基于该电商的业务展开。

方法论如何用(通用方法论)(2)

在梳理整体业务流程时,需要注意两点。

首先,需要搞明白业务流程中存在的痛点和问题,这是我们后续做方案时需要解决的。

比如,在上面的某电商整体业务流程中,供应商通过线下手工方式给平台提供商品信息,由平台在电商平台端录入商品信息。随着买家需求的增长,供应商和供应商提供的商品信息均在逐渐增多,平台录入商品信息需要的人力也逐步增加,这给平台带来很大的负担。

其次,需要搞明白客户现在用的系统有哪些,各个系统的作用是什么,客户对这些系统的替代或集成是怎么考虑的。这是我们后续考虑系统集成方案的基础。

1.3.2 组织架构

B端产品的客户往往具有多层级组织架构。比如,集团下面有各个公司,公司下面有子公司,子公司下面有孙公司,孙公司下面有门店、项目部等。

了解清楚客户的组织架构,将有利于后续的权限设计。

1.4 调研后需要交付什么

调研结束后,不是简单跟领导汇报调研情况就可以的,而是需要写一份调研报告。调研报告的内容包括:

  1. 客户业务现状,会用到整体业务流程图,并辅以文字说明;
  2. 客户业务存在的问题,以及客户的期望;
  3. 哪些问题可以用产品解决;
  4. 问题的优先级列表。

调研报告完成后,需要与客户沟通并获得客户确认

二、整体方案设计

客户认可调研报告后,我们开始产品整体方案的设计。相比于细节方案设计,整体方案设计更宏观,不涉及业务细节和产品原型。

2.1 整体方案流程设计

根据我们在第1次业务调研中得到的痛点和问题,对客户整体业务流程进行改进,形成整体方案流程

整体方案流程需要表达出的三要素是,参与方、系统(现有的和将要做的)、各参与方在系统中的业务活动

方法论如何用(通用方法论)(3)

针对平台录入商品信息负担重的问题,给出了解决方案。建设一个电商供应商端,由各个供应商提交商品信息,然后平台负责审核商品信息。这可以降低平台录入商品信息的负担。同时,供应商提交的商品信息需要经过平台审核,可以有效避免供应商录入信息不规范的问题。

2.2 产品定位

产品定位是要阐明,系统(产品)为谁提供什么服务。

我们举的例子中,电商供应商端的定位是,为供应商提供商品信息提交与管理等功能。

如果系统涉及的参与方比较多,那么可能需要将系统拆分为若干子系统,并分别阐明各子系统为谁提供什么服务。

2.3 功能模块设计

功能模块设计,就是考虑为用户提供哪些功能模块,以满足产品定位。

这是一个做加法的过程,把能想到的功能模块都罗列出来。在这个过程中,可以参考竞品的功能模块。

方法论如何用(通用方法论)(4)

2.4 应用架构设计

应用架构设计的目的有两个,一个是说明各个功能模块之间的关系,一般指数据流转关系;另一个是说明系统的功能模块与公司内部其他功能模块间的关系,是改造还是重新开发

方法论如何用(通用方法论)(5)

由于电商系统中已经有订单管理模块,且订单管理模块包含订单及其状态等信息,所以电商供应商端不需要重复开发订单管理模块。为了实现电商供应商端的订单列表和订单取消申请两个模块,只需对订单管理模块的接口进行改造。

2.5 产品路标设计

产品路标设计,就是依照业务优先级确定功能模块的实现节奏,即YY1年MM1月DD1日实现哪些功能,YY2年MM2月DD2日实现哪些功能……

方法论如何用(通用方法论)(6)

做完以上5个步骤,就完成了产品的整体方案设计。在进行第2-n次业务调研前,需要与客户确认整体方案。

三、第2-n次业务调研

3.1 调研哪些内容

第1次调研的内容比较宏观,所以第2次调研需要搞清楚各个功能模块所涉及业务的现状、存在的问题和痛点,以及用户的期望。

具体来说,需要梳理出各个功能模块所涉及的业务流程,并画出业务流程图。同时,需要对客户的报表需求进行调研。

如果第2次调研后发现还有一些细节没有弄清楚,那么就需要更多次调研。但是,最好在调研前做好调研计划,每次调研内容尽量系统、全面,以减少调研的次数。因为客户一般都比较忙,不太容易约调研时间。

3.2 调研需要交付什么

调研完成后,需要产出调研报告,并与客户确认。调研报告的要点与第1次调研后输出的调研报告相同。

四、详细方案设计

4.1 详细方案流程设计

根据第2次调研得到的业务问题、痛点和用户期望,对当前的业务流程进行改进,并分别绘制各个功能模块详细方案流程

详细方案流程描述的是角色A在系统B中做事情C。换句话说,详细方案流程的三要素是角色、系统、活动

通常,用跨职能业务流程图表示详细方案流程。

4.2 页面流转图设计

页面流转图是比详细方案流程图更细节的图。相比详细方案流程图,页面流转图描述的是角色A在系统B中为了完成事情C需要的操作D,以及操作涉及的页面。可以看出,页面流转图的要素是用户操作和页面

基于页面流转图,可以梳理出产品的页面有哪些,这是后续产品原型设计的基础。

4.3 产品原型设计

产品原型设计大家都比较熟悉,就是把设计意图形象、直观地表示出来。

不同的公司,产品经理在原型设计时的分工稍有不同。有交互设计师的公司,产品经理画出线框图就行。如果公司里没有交互设计师,那么产品经理需要把交互设计也做出来。

对于B端产品,最重要的是解决客户的业务问题,而不是把用户体验做到极致。所以,我们会看到很多B端产品的设计很low。这不是因为B端产品经理的审美水平不行,而是因为客户并不需要高大上的用户体验。但这并不是说用户体验就不重要,可以随意瞎搞,而是不需要在用户体验上花费大量精力。

4.4 权限设计

B端产品的特点之一是,客户的组织架构复杂。为了保证数据的安全,需要进行功能或数据的权限控制,这就涉及到权限设计。

通常,权限设计分为功能权限设计和数据权限设计。功能权限设计是对页面中功能点的访问权限进行设计。功能权限设计有一套经典的理论模型——RBAC模型,一般的B端系统都会基于这个模型设计功能权限。

数据权限设计是对用户能够查到的数据范围进行设计。通常而言,用户的数据权限和他在组织架构中的节点有关。

4.5 埋点设计

为了量化产品的使用效果,同时记录用户的使用行为,需要进行埋点设计。通过埋点,可以获取用户的行为数据,进而对该数据进行分析,从而得出有价值的结论,例如,如何改进产品的功能。

至此,就完成了一个B端产品从0到1的设计。

作者:产品经理伯庸;产品经理伯庸;

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

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页