起点学院课程

谈一谈B端产品的设计方法

3 评论 6450 浏览 25 收藏 24 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

编辑导语:B端产品即为组织提供商业价值的产品或服务,B端产品设计能力是产品经理需要具备的能力之一。本文作者通过正在规划的战略项目,总结B端产品设计的方法论,分享一些能够指导B端产品经理具体工作的方法,希望对你有所帮助。

最近我们正在规划设计一个部门的战略项目,目标是搭建一套可支持对外商业化的零售SaaS系统,过程中涉及到一些B端产品设计的方法论,我觉得有必要总结分享一下。

总体来看把过程分为以下三个阶段:

  1. 背景分析
  2. 需求调研及分析
  3. 系统搭建

具体每个阶段又分为若干步骤,这些可以指导B端产品经理的具体工作,纯干货分享。

刘生:谈谈B端产品的设计方法

一、背景分析

做背景分析第一步先看需求来源,这决定了项目的重要性和紧急性,通常有以下几种:

1. 客户需求-合同、招标书

对于靠为大公司做定制开发软件的企业来说,这是常规操作,拿到合同或招标书后开始启动,有明确的deadline,时间要求比较紧迫。

2. 战略需求-老板

做过C端产品经理的朋友都经历过老板基于个人喜好、同理心,对人的理解,突然提一些奇思妙想,希望团队尽快落地。

而B端产品的服务对象是企业,需要基于业务的系统性逻辑思考,天马行空的成分会低很多,老板通常是基于一定的洞察力发现未来可能会出现的机会和变化,结合目前策略上的差距,指出战略方向,但具体怎么做仍需要专业团队的分析输出。

由于看的是未来战略,老板相对会有耐心,会给团队足够的时间分析准备,属于重要但不紧急的项目,但会阶段性检查成果,通常半年或1年是一个节点。

3. 日常需求-产品经理

通常是自发的,基于对产品体验的优化、竞品的对标、客户的反馈,围绕战略需求有针对性的打造,重要性上不如战略需求,紧急性上不如客户需求。

作为一家致力于打造SaaS产品的企业来说,第2和第3种需求将会是主旋律。当然也不排除第1种需求,但比例应控制在10%-20%,传统的软件公司就完全是第1种需求驱动。

如果按照凯勒&帕帕森的《最重要的事,只有一件》理论,那么对要吃SaaS商业化这碗饭的企业来说,当前阶段这个战略项目的规划和落地就是唯一,至少应该保证有一个全职团队要不遗余力的做这一件事,其他事情都靠边。

背景分析的第二步是“战略五看”,分别是:

  1. 看环境
  2. 看行业
  3. 看客户
  4. 看竞争
  5. 看自己

从长期视角洞见行业终局, 从全局视角观察领先格局,从动态视角把握趋势,再回到行业的本质,看看哪些东西是不变的。

知己知彼,从环境、行业、客户分析得出的行业机会点,结合从竞争、自己得出的战略控制点,可以识别出未来的战略机会,最终推导出where to go,既确定产品的目标和范围。

刘生:谈谈B端产品的设计方法

每个产品都有特定的用户群体,确定产品目标和范围实际上就是输出如下这段话:

我们的目标客户是一家 XXX 企业,目前他们的工作方式是:XXX ,面临了 XXX 的痛点,我们可以通过提供 XXX 产品解决,可以达到 XXX 的效果。

把这段话中的XXX补齐,输出的就是我们的目标客户和产品,多段这样的话就组成了我们的目标客户群和产品范围。

4. 以零售行业为例,输出“战略五看”

4.1 行业终局

如我在《三维零售-我的最终幻想》一文中所分析,未来零售行业的终局可以用“商品-时间-价格”的三维坐标来表示,原点就是“你在脑子里想象某个东西,不论是你曾经见过、用过,或者仅仅是一个设想时,都能以一个最合适的价格立马获得,并且瞬间出现在面前”。

那么为了达到这个目标,企业首先会通过全渠道零售构造一条价格和时间的曲线,然后通过供应链C2B能力打造一个曲面,最后将这个曲面逐步向原点趋近,越趋近于原点的企业竞争力越强。

换个角度,谁能够有效帮助零售企业趋近这个终局,谁就可以在企业服务市场中分得一杯羹。

刘生:谈谈B端产品的设计方法

4.2 领先格局

通过对20多家零售企业服务商的调研,我们发现逻辑简单、价格便宜的管家婆,备受传统中小企业青睐,满足日常经营80%场景,横跨7大品类服务50万家企业:

我们发现营销玩法多样、体验好、平台服务丰富、紧跟微信生态的有赞,备受中小型数字化转型企业的喜爱,满足多种业态服务于8万商家;

我们发现深耕多年商超、连锁、便利店业态的海鼎,具有强大的配置能力,丰富的报表,全面细致的功能,能满足大型企业的精细化运营需要,在深耕行业有很强的影响力;

我们发现具有丰富产品线、强大的财务管理模块、复杂的组织管理能力,正在向SaaS转型的传统软件厂商用友、金蝶,具有大量高端客群,行业案例丰富,对大型集团公司有很强吸引力。

4.3 趋势

2020年两会三番五次提到产业数字化、新基建、互联网+等等概念,已上升到国家战略,企业在数字化转型,降本增效上有迫切需求。

尤其是这次新冠疫情席卷中国之后,很多企业用5个月完成了过去5年都没有下决心做的事,是一次难得的历史机遇。

而社零数据中网上实物零售的比重也从2019年同期的18%增长到25%,交易上行的大势已不可阻挡。

就连打造平台生态的微信,也于7月10日正式宣布将推出“微信小商店”,一套免开发0费用的卖货小程序,裁判员也脱光膀子下场当起运动员。

4.4 行业本质

无论是阿里新零售、京东无界零售、腾讯智慧零售,也无论是重构人、货、场、还是流量、转化、客单、复购、裂变的新零售公式,企业追求的永远是降本增效,成本、效率、体验的优化。

二、需求调研和分析

最傻的需求调研方法恐怕就是直接跑过去问客户:你要的是什么?你有什么需求?

因为这样你压根得不到想要的结果,或客户根本提不出需求,或觉得客户提出的都是不痛不痒的需求,或感觉极具个性化,做与不做无所谓。

毕竟你调研的人不是技术专家,他们关注的永远都是看得见的需求,如果你傻傻的只满足了这些看得见的需求就交差,那就大错特错,结果只有一种:客户不满意,反馈系统难用。

产品在接收到一个需求时,除了关注业务反馈的点外,应该具备在实际工作场景中挖掘那些看不见的点的能力,甚至进一步的需求。

这需要对业务的充分理解,做到感同身受,设计出更合理、高效的方案。

刘生:谈谈B端产品的设计方法

举个例子:

给某个超市做一个纸质价签管理功能,客户提出的需求就是能够查看并根据商品价格打印价签,这是一个看得见的需求。

于是,产品经理就在每条商品详情页增加了一键打印功能。按说客户提出的点满足了,但交付后客户反馈系统没法用,非常不满意。

如果我们深入挖掘一下,就会发现至少有以下几个看不见的和进一步的需求:

  1. 一般便利店都会有上千个SKU,假设每次10%变价,也会有100个价签需要打印,而每次进入商品页面打印价签的操作时间至少5秒,打印100次,再加上等待打印时间,可能半个小时都搞不定,这个过程对于店员来说非常煎熬,降低人效不说,而且会极大影响工作热情;最好的解决方案就是提供批量打印功能,在等待打印同时还可以做别的事情;
  2. 线下门店打印价签通常是提前为促销做准备,或者是促销后恢复原价,这个反应速度越快越好,为了做到无缝衔接,价签打印要前置,也就是在系统真正变价之前就准备好物料,所以要有按变价时间维度筛选商品并打印价签的功能;
  3. 促销是变价的主场景,所以应该有预先知道门店促销活动的功能,这就需要营销日历,让店员清晰明确的了解到接下来的活动及变价情况,并且联动打印价签;
  4. 促销活动的种类繁多,那么在价签样式上要予以区分,尤其是与普通商品的价签样式,那么是不是可以考虑增加各种活动的价签模板,并给出不同的默认颜色和样式,额外再提供编辑功能;
  5. 我们发现经常变价的门店人力成本非常高,除了打印还有核对、陈列,偶尔的操作失误还会引来客诉,基于ROI考虑,是不是可以改用电子价签呢?这就是进一步的需求了。

综上,如果每一个产品都能向前一步说话,从行业“降本增效”的本质出发,设身处地的为客户思考,获取全量的真实需求,也就避免了无从下手及费力不讨好的窘境。

价签管理只是一个很简单的功能,当我们面对复杂功能的需求调研和分析时该如何下手,还是要有一套方法论。

1. 过程分为三步

1.1 业务流程梳理

业务流程是分层的,尤其是当我们把目标客户定位为中大型企业时问题尤其复杂:

  1. 第一层:是组织级,集团视角,关注分工、管理和大方向的业务流向。比如在零售企业中,就会存在供应链、门店、售后,客服、财务等几个不同的部门。这一层的调研内容主要是确认企业的组织构成,流转方式,目前存在的经营问题,寻找潜在的机会点;
  2. 第二层:是业务级,部门视角,关注每个岗位具体负责什么,产出什么,以及这些活动之间的关联。例如门店部门要销售商品,需要库管、销售运营、导购的配合才能完成,产出就是销售额,这是业务流程梳理的主线索,也是主要输出。这一层的调研内容主要是确认部门内岗位分工,每个业务事件的流程,参与者,事件及关注的产出物,通常是报表形式;
  3. 第三层:是操作级,通常是某个岗位的视角,实现某个业务场景需要的具体操作步骤,可能由某个或几个岗位的人操作,属于需求细节。这一层的调研内容主要是确认每个角色参与的业务流,日常的操作流程,了解功能、数据、用户体验等方面的问题。

业务流程分析起来很多很复杂,还会有子流程嵌套,很难用文字描述清楚,因此这一步的产出最好采用跨部门和岗位的泳道图,下边以线下销售场景为例说明:

刘生:谈谈B端产品的设计方法

线下门店销售业务流程横跨3个部门7个岗位角色,而每一个步骤又包括若干的子流程,输出这个流程的目的是确认各个部门之间的关系,及各个角色应该承担的工作内容。

1.2 角色与场景分析

基于步骤1输出的角色应承担的工作内容,再具体看某个角色在特定场景中都需要做什么事,那么就拆分成两个基本要素:

  1. 参与者:这个流程中与系统进行有意义交互的任何事物,可以是某个岗位的人,也可能是一个硬件或系统,比如门店销售可以是导购,也可以是自助结账机,线上销售就是APP或者小程序;
  2. 做什么事:是指系统执行的一系列动作,是一个动词+名词的组合,且必须是有意义的,产生实际结果的动作,比如,操作收银机执行一系列动作,生成销售订单,这就是一个完整的场景了,但只是添加一个商品到购物车,这不能叫完整场景。

2. 为什么要用这种角色+场景的方式分析

主要因为以往很多技术性产品经理在分析和设计产品时,总是以功能的视角去思考,既这个系统应该有什么功能,这样做出来的产品就是一系列功能的堆积,用户常常抱怨太难用。

看到一堆“xx管理”的菜单,根本不知道干什么用,即使看了天书一样的手册,要完成一个场景,可能需要切换若干个菜单模块,合上天书,又不知道该去哪找需要的功能了。

而以角色+场景方式驱动的分析方法,是一种侧重于“用户视角”的分析,将系统做成一个黑盒子,不仅可以有效指导最终展现的菜单形式,避免上述问题,还有利于梳理场景时发现那些看不见的问题。

下边以“导购”角色的“销售”场景为例进行分析:

刘生:谈谈B端产品的设计方法

刘生:谈谈B端产品的设计方法

步骤2分析的角色+场景只输出了一个核心路径,是主流程,还要补充拓展流程、完善前置条件、后置条件、特殊规则。

  • 拓展流程:指分支事件和一些异常情况;
  • 前置条件:指这个场景发生前需要系统具备哪些能力或处于哪个状态;
  • 后置条件:是场景结束时输出的内容或一种状态;
  • 特殊规则:就是受限于客观情况必须规避的情况,比如硬件性能、数据库大小、使用环境、技术选择、公司规定等产生的限制。

将多个角色场景进行抽象整合输出系统用例,系统用例作为最小需求单位指导系统开发。

这里说的抽象整合就是技术层面的复用逻辑,好比软件开发中“类”和“对象”的关系,系统用例是一类的抽象,角色场景是一个具体的行为。

刘生:谈谈B端产品的设计方法

仍然以“导购”+“销售”场景示意,输出系统用例如下:

刘生:谈谈B端产品的设计方法

三、系统开发

进行到这一步,系统变得越来越具象,引入的人也会越来越多,一个很复杂的项目为了保证原始需求不走样,非常有必要的一步是把系统用例映射回原始业务流程,看看是不是都覆盖全了,可以用类似这样的表来跟踪:

刘生:谈谈B端产品的设计方法

这是一个回顾和整理的过程,同时优化系统用例,按照模块分工给相关的人输出原型设计和数据报表,这些是技术产品经理最擅长的了,但需要强调3件事:

1. 菜单结构设计

很多技术产品在设计交互时喜欢用功能模块来划分菜单结构,直接把底层的功能投射到用户交互层,这对于没有行业属性的软件来说是迫不得已,但在客户实际使用中却有很大缺陷。

因为在业务操作中,会出现不同层次页面的频繁交替,让使用者云里雾里,感觉十分混乱。

产品经理只能通过输出天书版的操作手册来培训使用者,无形中增加了学习成本,而放下天书,又忘了该去哪个页面操作,想找一个功能也不知道该去哪个页面。

对于垂直行业的B端产品来说更好的方式是以“业务场景”来划分菜单结构,以完成某一件事为主线,好处是可以明显改善重复和混乱的现象,让整个系统的菜单结构清晰明了,使用者更容易上手

为了适应不同行业中“业务场景”可能存在的差异,系统中还可以设计一套业务流程管理功能(BPM),去定制“业务场景”中的操作流程,并最终体现在菜单结构的改变。

这是一个很复杂的功能,但对于横跨多种行业的软件来说可以大大增加系统灵活性,减少后期的开发工作量。

2. 数据操作完整性原则

本质上软件的工作就是信息输入、信息处理和信息输出。

在设计输入环节时我们要检查“增删改查CRUD”四个基础功能是不是给全了,是不是能够在一个页面内解决?以及是不是足够好用。

比如商品主数据的输入,由于涉及到大量SKU,那么设身处地为操作人员考虑,从提高效率的角度,要考虑批量导入,批量删除、批量修改、条件筛选的功能;在设计输出环节时我们要提供丰富的筛选查看以及必要的导出功能,这样不仅方便客户在系统内查看数据,也可以自助导出用其他工具透视。

通常不同的数据操作权限会分配给不同的角色处理,所以不仅要提供功能,还要考虑在权限层面解耦出来。

3. 角色权限模型

B端产品通常都适用于RBAC权限模型(Role-Based Access Control),也就是每个用户都要被赋予一个或多个系统角色,每个系统角色都对应一个明确的权限集合,包括对菜单、页面元素、数据资源的访问与操作权限。

需要建立一个“用户——角色——权限”之间的对应关系,用户与角色,角色与权限都是多对多关系,即一个用户可以对应多个角色,一个角色可以分配给多个用户,一个角色具有多个权限。

当用户比较多时,还可引入用户组,将角色与用户组进行关联,当角色发生变更时,可以大大提高操作效率。

完成这些工作后交付UI设计,最后进入软件开发,这两步就要交给专业的UI设计和软件架构师操刀了。

四、总结

B端产品设计需要丰富的行业背景和专业能力,不仅要有逻辑能力还要有全局视野,清楚行业的上下游关系,看不同角色在链条中的作用。

不应是简单的堆砌功能,也不是所有的功能都适合做到线上,而是要看清楚哪些符合行业本质,才在哪个方向发力。

 

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

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 想问一下,文章中的泳道图是用什么工具画的~

    回复
    1. axure

      回复
  2. 其实吧,把b 换成C ,你会发现是一样的。。没啥亮点的东西

    回复