B端设计师必备:如何体系化了解业务

3 评论 5615 浏览 52 收藏 19 分钟

在B端设计中,很多业务具有角色多、业务场景复杂、功能链路长等特点,所以很容易面对新的任务,就不知从何下手了。本文作者从4个角度,分析当面对B端新业务时,应当如何快速开展工作。希望能给你带来一些帮助。

接触 B 端设计小伙伴会发现,很多业务具有角色多、业务场景复杂、功能链路长等特点,所以在工作中会经常遇到以下几个问题:

  • 突然被调配到新业务,拿到一个不熟悉的业务或者新产品,不知如何开展工作?
  • 换了一个新行业,面对一个从 0 —1 的新项目,应当如何熟悉新业务?
  • 面对较为复杂的业务,经常和业务方沟通讨论不在一个频道,又不知如何着手。

本文将从以下 4 个角度展开探讨,当设计师面对B端新业务时,应当如何快速熟悉业务并开展工作。

一、查行业和竞品

首先,不要一上来就急着看系统。线上的功能模块只是实现需求和业务目标的手段,并不一定是最优解,能够为客户解决问题的方式有很多,不一定非得是我们提供的互联网服务。所以如果我们一上来就着急走数据看系统,很容易就会把自己的眼界,局限于这些产品的功能界面中。

1. 查行业报告

首先需要明白自己从事的是一个什么行业,这个行业叫什么,是做消费品的、是酒旅还是建筑地产等。提供企业服务有做SaaS的,有做PaaS的,有做平台数据对接的,也有本公司自研系统,第一步要建立起对这个行业有一个宏观的认识。

通过市面上的这些行业分析报告,可以了解到自己做的业务处在哪一个赛道,另一方面也能大概知道目前所做业务,在市场处在生命周期的哪一个阶段。比如下文就是艾瑞咨询关于中国SaaS 产品的一个图谱,通过这些图谱不光可以了解我们公司产品所处地位,也能纵向知道公司产品的竞争对手有哪些。比如为企业提供SaaS零售电商服务的就有微盟、有赞、小鹅通等服务工具。

2. 查行业竞品

看竞品不仅是要看产品本身,还要比较它的行业地位,需要了解我们的产品在大背景下,处于一个什么地位,是行业头部,还是在追赶地位。同时,还要关注产品背靠的资源和竞品相比有哪些区别。比如这两年大火的Scrm运营工具——微盟的企微助手,背靠的资源就是过去几年通过商城零售产品积累的客户。以及微盟于2022年发布的WOS新商业操作系统中,企微助手与微盟其他产品的超强融合能力。

关于行业竞品,需要大家花点时间找一找,也可以通过相关的负责人问一问。

3. 查公司战略

了解公司战略并不是一句虚话,它涉及到你后期负责的业务的发展方向。比如微盟从2020年开始提出大客化战略方向,如果你是负责零售这一块的业务,你必须要知道你的客户群体是要以大客为主,大客和小客在需求痛点上是完全不一样的,所以这涉及到我们后期面对这些角色设计上的一些区别。

再比如微盟2022年新推出的WOS新商业操作系统 ,除了提供微盟的标准化产品解决方案外,还可以让更多的生态伙伴产品参与进来共建产品,包括 PaaS 平台,可以满足商家的个性化需求定制。这也会涉及到我们在产品设计,页面框架层搭建的兼容性,需考虑覆盖各类业务、以及产品对外的一致性等。

二、看产品和价值

看产品,是指看产品的业务文档,而不是看prd界面,需要了解产品的核心价值和目标客户群体。这个阶段,需要看产品在什么样的场景下,帮助哪一类客户,解决什么痛点或者问题。这个阶段涉及产品一切的文档资料,包括业务背景、需求文档、宣传文档、产品白皮书、销售资料和公众号等,我们都需要尽可能多的,主动性去找相关资料和数据查看。

1. 看产品的专业词汇

很多B端产品都是服务于很垂直的领域,所以不免涉及到专业领域的一些词汇。比如CDP产品,我们在了解这个产品时,需要知道一些基本概念,比如什么是多渠道标签,标签的类型有哪些,什么是文本标签、多值标签、日期标签等;用户分群里的人群包、自定义人群和系统人群,以及常说的圈人条件是指什么。

如果我们发现自己的产品还没有整理这些信息,我们可以通过竞品的官网,或者到竞品的用户手册、帮助中心等模块找到这些信息。我们还是拿 CDP 举例,下方就是就是火山引擎和 Growing IO 的帮助文档,熟悉了这些专业词汇,可以让我们可以更快的了解产品,当然如果你有时间,也可以帮助自己的产品去整理这一份文档。

2. 看产品的价值

怎么去看一个产品的价值点,这个较为复杂,我们可以借用一个工具叫价值主张画布(The Value Proposition Canvas),它可以帮助我们很好的去理解产品和目标群体之间的关系,清楚地描述出产品帮助客户解决了哪些问题,和创造了哪些收益。

价值主张画布内容较多,感兴趣的同学可以看一下《价值主张设计》这本书,这里我们简单总结分为【价值地图】与【客户洞察】两个板块。

1)价值地图

描述产品为客户创造的价值,包括产品与服务、创造价值、解决痛点。

  • 产品服务:我们给客户提供的是一种什么样的产品或服务
  • 解决痛点:产品解决了用户的哪些难题
  • 创造价值:产品让客户获得哪些好处

2)客户洞察

帮助我们理解客户,包括客户的任务、客户的痛点以及客户的收益。

  • 客户工作:是指客户利用系统要做哪些工作日常及事项
  • 客户痛点:客户在本来工作流程中遇到的问题及阻碍
  • 客户收益:指客户通过购买该系统,获得的盈利来源

三、理功能及流程

1. 理产品功能大图

一定要看核心业务或者产品功能的大图,理清业务功能模块、数据之间的来源去向关系,整个平台的数据是怎么流转的,以及最后是怎么形成逻辑闭环的。这时最好多向身边的同事多多请教,避免埋头苦干,可能自己纠结了半天的问题,可能都抵不过同事的一点点拨。

比如近两年大火的私域运营工具SCRM ,其核心本质是一个社交化的私域运营工具,其PC端功能主要分为4块,引流获客 — 促销运营 — 营销转化 — 决策管理,下图就是是微盟企微助手产品功能模块大图。

2. 理数据流程

业务流程相对是一件相对复杂的事情,不同产品的流程侧重点不一样,有些产品的流程会牵涉多个角色,这个时候需要找到对应产品负责人,要到不同权限角色的账号,因为不同权限角色的账号功能也不一样。有了账号,了解每一个功能菜单帮助客户解决了什么问题后,就可以建数据走流程了。

1)找到核心功能模块

首先找到该业务的核心功能并熟悉它。比如拿SCRM产品举例,微盟企微助手、微伴助手和微盛企微管家都将【活码】这个菜单功能排在头部位置,一方面是从产品的使用频率考虑,另一方面它也是产品的核心功能模块。怎么找到核心功能模块?你可以通过产品的导航、或者产品官网的介绍,找到产品的核心功能模块。

2)关注不同角色的工作

和C端产品不同,B端产品角色相对固定,我们需要关注有哪些角色、角色之间的协同关系、工作的场景、目的和操作链路。概括起来有以下三个内容:角色信息、工作内容、考核指标。

  1. 角色信息:包括角色名称、工作职责、能力维度等。比如SCRM产品会有老板、运营负责人、员工等角色。
  2. 工作内容:具体场景、内容描述、目标和期望。比如老板会看整体数据及基本分析结果,运营负责人会维护整个系统的信息和数据分析,包括创建派发任务等,员工更看重任务完成等。
  3. 考核指标:一般会结合任务而需要完成的考核指标,这个和每个产品的特性有关。

3)体验并感受产品

在体验产品的过程中,把自己带入产品的角色中去,用我们专业的眼光走查一遍产品,比如产品的框架设计如何?里面操作流程是否符合用户认知?各功能模块的交互是否一致?是否会有操作的错误的判断可以结合自己的交互走查表,不过仍需注意,不要陷入到产品的细节体验中去,毕竟我们要做的是熟悉各个功能模块。

这样的好处,可以避免产品因历史的包袱问题而带来的眼界束缚,完全用一个全新的观念和心态体验新产品。在建数据流转的过程中,我们可以得到一个小白用户对于这个产品的使用体验,在使用的过程中,也可以记录下来自己的行为和感受。对于很多新的产品团队来说,一份新手用户对于产品的认知和体验感受也是一份宝贵的资料,因为等我们真正熟悉业务产品时,很有可能会忽视这些旧问题。

在建数据的过程中,可以结合之前相关业务文档一起看,一边走一边了解每个功能模块的前世今生和具体细节,同时产品的数据流转一定也要多走几次,尽可能理清数据业务的流转逻辑。

4)特殊产品仍需和线下实践结合

有些特殊化的产品,流程比较复杂,需要亲身经历和体会。比如拿物流的WMS仓储系统来说,如果不到现场亲历入库、出库、盘点和分拣等实体操作,光通过系统和文档,很难知道现场作业人员的所思所想,和不同角色所要关注的点。

只有亲历了一遍现场以后,才会知道作业环境的嘈杂和混乱,所以有些特殊化的系统,还是需要自己体验走完一遍这个流程比较好,毕竟纸上得来终觉浅,绝知此事要躬行。

3. 理交互规范

有了对整个产品功能模块的了解,下面就是熟悉产品的交互框架,还有一些组件库。尽可能做到在实际设计时让这些组件做到复用,这样可以帮助我们节省很多时间,也可以避免很多交互上的错误。

四、问对人说对话

通过前面的一系列自主调研及建数据流转,对我们所要负责的业务有了一个较为清晰的认识,这中间我们也会产生很多问题,不免需要上下游的小伙伴们打交道,怎么和小伙伴沟通讨论仍需掌握一些方法。

1. 问对相关业务人

我们需要找到业务的关键人,特别是刚去一个新公司面对一个新业务的情况下,这个时候需要了解业务的人员组织架构,找到对应的负责人,当然我们不可能上来就让人家给我讲讲业务和人员架构。

1)找到对应负责人

比如我们可以这么说,不知道你有没有时间,或者你是否能够推荐团队里面的大佬能够给我讲一下,以便我们后续更好的配合及开展工作。

2)问问题不要过于笼统

在和对应的业务产品沟通的时候,你不能直接说,你能不能给我讲讲这个功能或者业务,这个问题太过于概括和开放,对方一下接不住这个问题。如果对方没有做准备,很有可能在他和你讲的过程中,还会涉及一大堆技术和行业词汇。

2. 说对话的一些有用技巧

  • 把问题整理好,可以集中性地问,不要一个个地去问,以防不停占用别人的时间,毕竟谁也不喜欢不停地被人打扰。
  • 如果是一些抽象复杂的问题,提前发给人家,让对方也有个准备时间。
  • 在向别人请教的时候,如果能够带上纸笔作记录更好,以表示对别人的尊重,等到回到自己的工位后,也可以自己画出产品的业务的流转图,加深自己对于产品的理解。
  • 如果可以,给别人带上一杯奶茶啥的,毕竟没有人有义务无条件帮助你。

关于新入职的同事,或者被调到一个新业务时,我们需要向当前业务骨干设计师请教业务问题时,也需要掌握一点说话技巧。我曾在群里看到一位前辈分享过一个表达话术,和大家分享下:

五、总结

关于了解业务,我们整体的思考框架是,先整体再局部从大到小,从行业入手了解行业竞品,产品是怎样的商业运转模式,再通过价值主张这个工具,了解产品各个功能模块的价值。

找到产品的对应负责人,了解业务或者产品的组织架构,知道产品的核心模块是哪些,清楚不同角色的之间的流转关系是怎样的,将角色之间的流程串联起来,就能够达至了解业务。最后,我们对产品的掌握了解差不多了,其他的非核心模块,可以在后期做项目的时候,一边做一边了解。

希望本文对你有所帮助。

参考文献Yves Pigneur《价值主张设计》

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

题图来自Unsplash,基于CC0协议

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 竞品的用户手册不那么好拿吧

    来自江苏 回复
  2. B端设计真的需要较高的自身业务能力才能真正地交付一个产品

    来自山西 回复
    1. 你是指了解业务的能力吗

      来自浙江 回复