B端业务场景地图绘制五步法_产品经理|产品经理|PM老猫

文来自我正在写做的新书《决胜体验设计》（暂定名），欢迎大家在写作过程中给我提建议、期望、不足、错误！因为是在word写作，黏贴过来排版比较随意，请大家多担待

4.2.1 场景地图的绘制

从上一节的讨论中，我们讲到B端用户场景有着发散、复杂的特点。作为产品经理，如何能全面、准确的梳理用户场景呢？

场景地图绘制五步法，是我在实践中总结的，梳理B端用户业务场景的方法论，五个步骤分别为：明确画像用户、确定业务目标、推导关键任务、绘制旅程地图、细化业务场景，如图4-1。

图41 场景地图绘制五步法

明确画像用户

明确画像用户，是一切体验设计和场景分析的前提。在B端业务中，相同岗位的业务人员，涉及的场景、痛点，多数情况下是相通的，但如果想更加细致的做好体验设计和痛点挖掘，则需要将同一岗位的角色进一步细化成多个不同特征组合的画像用户。例如，同样是房产经纪人，老员工和新员工对业务以及APP的熟练程度是不同的，产品经理可以将用户细分为新用户和老用户两类画像群体，针对新用户推送一些APP使用技巧、业务入门等知识，以及在登录APP后增加一些分步骤引导的说明，从而提升用户体验。

确定业务目标

B端产品，本质上是为业务服务的，即便从用户视角思考体验问题，也不能脱离业务。因此，在分析用户场景时，从业务目标出发，是一个比较好的切入点，这样做可以让分析的逻辑遵循以业务为中心的原则，确保后续的工作不偏离产品的价值本质。

推导关键任务

通过业务目标，我们可以推导出用户日常的关键任务，每个任务是为了达成目标、服务于目标的独立工作。任务本身也可能是一个场景，但颗粒度更粗一些，任务可能是独立的，也可能彼此之间有连续性，例如门店经纪人的客户开发、带客看房、客户签约三个任务，也是一个客户转化的旅程过程。

绘制旅程地图

每一个任务，都可以拆解成用户角度的作业过程，也就是所谓用户旅程，而旅程中的每个节点，也是一个场景。通过对任务的拆解，从用户旅程的角度进一步分析作业过程，让我们对场景的理解更深刻。

细化场景变体

任务被分解为旅程阶段后，呈现了作业过程，但还不够生动。下一步，我们可以通过人物、时间、地点、起因、经过、结果几个因素，对每一个旅程节点，还原的更加立体生动。

接下来，我们围绕Z公司经纪人办公终端优化的案例，采用场景地图绘制五步法，绘制一份房产经纪人的场景地图。

4.2.2 明确画像用户

　　大可：“土豆，你的调研工作已经开展一段时间了，关于用户场景的梳理，有什么产出分享么？”

　　土豆：“正准备找您交流，根据您介绍的场景地图绘制五步法，我已经完成了门店经纪人的场景梳理！”

　　大可：“说来听听！”

　　土豆：“首先明确了分析的目标画像用户！我先盘点了门店业务中几个典型的涉众利益方，业务管理者主要是大区总，业务执行者包括了门店的店长和经纪人。我对每一个角色都简单绘制了他们的用户画像！，如图4-2！”

图42 房产经纪人门店业务的涉众和画像用户

　　土豆（喝了口水继续）：“我们先来看看大区总，每个大区总都要负责一个区域的整体业绩，一般公司安排的都是有几十年从业经验的高级管理人员，这里我拟人化了李总，工作20多年，至少有本科学历，有房有车，妥妥中产，并且业务能力强，管理经验丰富！”

　　土豆：“接下来是店长王经理，工作10年左右，从一线业务人员一步步成长起来，本科毕业，事业持续上升中，干劲十足，有一半时间都出外勤，贴近一线客户，带领门店拿结果。”

　　土豆：“然后门店经纪人，这类角色画像用户比较丰富，例如有行业老炮老黄，行业新人小杨。老黄在门店干了七八年了，对小区情况非常熟悉，客源多，业绩好，对系统使用也很熟练！行业新人小杨，刚入行没多久，业务知识还不扎实，对小区和房源情况也不熟悉，对咱们软件的使用也不熟练，但是激情十足，一腔热血！”

　　土豆：“如果想要做完整的用户体验分析，需要对每一个用户画像进行研究，但因为我们时间精力有限，而APP的大多数用户都是经纪人，并且目前人员流动大，新人比较多，所以新人就是我们体验优化工作服务的一个重点人群，因此，接下来的场景地图绘制，我就拿小杨作为画像用户，进一步开展分析！”

　　大可：“很好，没问题，其实小杨和老黄的工作场景大多数时候都是相同的，分析清楚小杨的场景，再补充老黄的特殊场景，就很全面了！”

4.2.3 确定业务目标

业务目标是指业务人员工作的核心目标，如果业务人员工作繁多，分析时无从下手，可以从考核指标中寻找业务目标。

考核指标体现了管理者对业务管理模式的思考，也体现了管理者对下属工作目标的要求和期望。常见的考核体系设计，KPI（Key Performance Indicator）强调量化结果，OKR（Object Key Result）强调自驱赋能，OKR常见于科技公司产研团队。

任何商业公司，都要实现自己的商业价值。在实现商业价值的过程中，业务提出人（CEO、董事长）制订公司的战略规划；业务管理者（副总裁、总监级别）要承载战略的落地，为自己负责方向的业务结果负责；业务执行者要做好执行，帮助业务管理者取得结果。

公司整体的经营目标，被拆接到各个业务口负责人身上，例如销售副总裁要承担业绩指标，采购副总裁要承担成本与供应链效率指标，产研副总裁要承担业务满意度、业务支持率等指标。

业务管理者会将指标进一步拆解，分解到执行者身上，执行者不一定为业务的最终结果负责，但所负担的指标会直接或间接的支撑业务管理者达成业务结果。在现代企业管理中，每一个受雇员工都会有考核指标，衡量其工作绩效。

例如，在一个经典的B2C电商业务中，营销人员的KPI可能是销售额，审单员的KPI可能是审单量和准确率，客服人员的KPI可能是服务满意度和接待数量。

考核指标往往是量化数字，在梳理场景的工作中，我们并不关心考核指标的具体数值，而更关心指标背后体现出的工作重点和目标，因此，通过分析KPI，可以理清用户的工作重点，从而进一步推导背后的关键任务。

　　土豆：“对于大区总李总，核心KPI是大区业绩以及团队建设，因此李总的业务目标是达成业绩，培养建设梯队团队。对于店长王经理，考核的KPI是销售业绩，以及房源数量，因此，店长的业务目标是达成业绩，以及获取足够的房源；而对于我们分析的目标画像用户小杨，考核的KPI和店长一样，同样是成交量与房源数，这也是目前一线经纪人工作的重点。因此，对于小杨来讲，工作的关键业务目标，就是提升成交量、增加房源数量。”

4.2.4 推导关键任务

关键任务，是为了达成业务目标的业务工作，每一个关键任务都应该有明确的目的，关键任务可以直接帮助业务达成目标，也可能间接帮助业务达成目标。关键任务可以是松散的，互相独立的，也可能有上下游关系，是一个业务链路的几个阶段节点。

从业务目标到关键任务推导的准确性，取决于产品经理对业务的熟悉程度，如果自身对业务不熟悉，不了解业务人员的日常工作，关键任务的推导就会有遗漏、不全面。不过，我们并不一定要整理出所有的关键任务，我们的目标是挑选典型的、有代表性的任务，并进一步推导场景。如果想穷尽业务人员的所有工作任务，可能的一个思路，是整理他们全天的工作细项，以及特殊日期的工作内容，但是这样做需要投入较多的精力和时间。

　　土豆：“围绕画像用户经纪人小杨的工作目标，我梳理出了他日常的几个关键任务，分别是电话陌拜、带客看房、履约交付、捕获新房源，如图4-3。”

　　大可：“不错，很清晰，这四个任务确实是一名经纪人的重点工作。”

　　土豆：“不过有一点我没想明白，每天小杨都要参加晨会和晚会，这个是不是该写进关键任务呢？”

　　大可：“推导关键任务，是一个梳理业务并呈现结论的过程，如果觉得有价值，就列示出来，在下一步工作中，并不是每个关键任务都要还原背后的场景。”

　　土豆：“明白。我还发现，我推导出小杨的关键任务，就是我之前绘制小杨的用户画像中的每日主要工作。”

图43 从业务目标推导关键任务

　　大可：“确实，关键任务很多都是日常工作。另外，你有没有发现，你列出的四个关键任务，其中前三个关键任务本身就是一个客户开发、转化、履约交付的过程？”

　　土豆：“是啊，这里我正好也有困惑，关键任务的颗粒度该怎么把握呢？例如，电话陌拜和带客看房，我也可以用一个[开发转化客户]的任务来表示；而电话膜拜，我也可以分解成[筛选名单]、[电话拜访]两个任务。”

　　大可：“任务的颗粒度，确实比较难把握，我们来看看一些不同颗粒度的任务拆分方式，首先，把[电话陌拜]这个任务拆分出子任务，并且对子任务[电话预约]再做一次拆分，可以得到图4-4。”

图44 任务结构的变体I

　　大可：“可以看到，[电话陌拜]这个任务，可以向下拆接出两个层级，其实这些层级也是相对的，我们再做一次变化，将[开发转化客户]变成一个任务，和[履约交付]同等级，然后去掉[电话陌拜]任务，将其下边的[筛选名单]、[电话预约]往上提一层，和电话预约变成平级别，又会得到图4-5这样的结构。”

图45 任务结构的变体II

　　大可：“此时，我们觉得[开发转化客户]这个任务颗粒度有点太粗了，于是再次决定将他下边的子任务往上提高一层，得到图4-6的结构。”

图46 任务结构的变体III

　　大可：“总之，我们会发现任务的颗粒度定义非常灵活，（其实这很像用户故事地图中对Activity和Backbone的定义，后续章节会进一步讨论），我的建议如下，首先，每一个任务应该具备明确的业务价值。比如图4-6中的[筛选名单]，是一个动作，业务价值并不是很明确，不适合作为任务节点。其次，每一个任务应该是一类场景的聚合。如果任务重包含了差异很大的场景，则考虑任务颗粒度太大，例如图4-5中，[开发转化客户]这个任务，包含了[电话预约]和[带客看房]的子任务，两者是完全不同的场景，可以考虑将[带客看房]往上提一层变成一个独立任务，这样打电话的场景和现场看房的场景就被解耦了。”

　　土豆：“明白了，这个解释很清晰。”

4.2.5 绘制旅程地图

确定关键任务后，下一步我们要拆解每个任务的旅程阶段。所谓旅程（Journey），是指从用户的视角，为了达成某个诉求，所需要经历的一系列过程。旅程是用户体验中非常关键的概念，任何用户体验的分析工作，都是围绕画像用户，从旅程的梳理展开的。

初学者很容易将旅程和流程搞混，旅程并不是流程。

流程是从业务的角度描述过程，可以包含多角色；而旅程是从用户的角度描述过程，必须是单一用户的视角。一个业务流程，可以拆解出多个用户旅程，例如针对新员工入职流程，就可以从新员工的视角绘制入职旅程，从HR的视角绘制接待新员工旅程，从IT人员的视角绘制IT资产设备派发管理的旅程；而一个用户旅程，显然不能完整描述业务。

接下来我们所讨论的用户旅程，是指包含了用户在线上和线下作业的完整体验旅程，也即用户体验设计四个层次中的第三层，如图4-7。

需要注意的是，体验设计的四个层次中，既有客户体验，也有用户体验，实际上这并不是有意区分了客户用户，只是遵循了一些方法论最早提出时的命名；不论客户还是用户，指的都是画像用户，是拟人化的人物。在B端业务中，不论是商业化软件，还是自研系统，从用户体验层面，我们研究的都是软件终端用户。所以，请大家一定不要被客户体验设计、用户体验设计这两个不一致的叫法搞晕了。

图47 用户旅程研究的是体验设计四层架构中第三层的问题

在经典的B端软件设计中，设计人员往往从业务流程梳理开展工作，通过将核心业务流程、分支业务流程一个一个理清楚，搞清业务的全貌。复杂的B端业务，就像一个杂乱的毛线团，核心业务流程就是线头，从核心流程入手，就可以把乱麻一般的线团顺着线头理清楚。

遗憾的是，设计人员重视流程的梳理，却往往忽略用户旅程的梳理，缺少从用户视角对业务过程的描述。因为B端产品设计，首先要支持业务开展，流程顺畅，不能出现中断、异常，这就导致设计出来的软件，从流程的角度，业务可以顺利执行，但是如果从单一用户角度，软件却非常难用，业务过程也不一定顺畅。

现代软件设计，要求软件产品，既能很好地支持业务，解决业务问题，又能够让用户使用起来有效率、便捷、体验良好。因此，作为产品经理，我们既要懂得如何从业务流程中抽象、提炼软件功能，这是基本功，又要懂得如何从用户视角的旅程中寻找体验优化的机会点，这是扩展技能。

　　土豆：“在经纪人的几个关键任务中，我挑选了带客看房，进一步绘制带客看房过程中的用户旅程。如图4-8。”

图48 梳理任务的旅程阶段（以带客看房为例）

　　土豆：“我将带客看房的旅程分解为三个阶段，分别是需求沟通，看房前和买家再一次核对需求，接下来是在约定的时间地点实地看房，看房后，如果比较顺利，就和买家签订意向合同，或者继续约看房屋。”

　　大可：“你对带客看房任务的旅程拆解没有问题，针对每个旅程节点，我们还可以进一步标识每个节点的目标，例如[需求沟通]的目标就是‘准确理解需求从而匹配房源’，[实地看房]的目标就是‘成功约看房屋。’”

　　土豆：“有一点我不太明白，您让我在旅程目标下边列出的场景细化要素是指什么呢？”

　　大可：“严格来讲，旅程阶段并不是场景，结合了场景六要素的旅程阶段，才是场景。例如，[需求沟通]，这是一个抽象的工作或任务，而[客户与经纪人一起在门店沟通买房需求]，这才是场景。我们最终要绘制场景地图，现在已经得到了旅程阶段，只需要把每个旅程阶段相关的场景要素罗列出来，下一步就可以通过这些场景要素，来穷举所有可能的结合了真实场景的用户旅程了！场景要素除了我们之前讲到的人物、时间、地点，还可以把环境考虑进去。例如，在极端恶劣天气带客户看房，和晴朗天气带客户看房，遇到的挑战和问题肯定不一样。”

4.2.6 细化业务场景

　　大可：“我们已经梳理了旅程阶段，场景要素，下一步，可以根据场景要素，把每一个旅程阶段可能的细化场景都罗列出来。我来看看留给你的作业完成的如何啦？”

　　土豆：“已经弄好了！来看图4-9。”

　　土豆：“需求沟通的阶段，人物涉及到经纪人和买家，时间就是在看房之前，地点包括了网络、电话和门店，因此组合出的三个实际业务场景，分别是在网络沟通需求、通过电话沟通需求、在门店沟通需求。”

　　土豆：“实地看房的阶段，场景更复杂一些，人物包括了客户、经纪人、房东、钥匙持有人，在我们公司的业务中，有些时候钥匙是被专人保管，看房时需要钥匙持有人一起出席；时间是全天候；地点是待售房屋；这里多了一个环境要素，是否恶劣天气。”

　　土豆：“根据这些场景要素，我将现实中比较典型的几个实际业务场景整理了下，主要包括恶劣天气拿到钥匙成功看房、恶劣天气未拿到钥匙未看成房屋、约到房东一起看房、与钥匙持有人一起看房。”

图49 经纪人用户场景地图全貌

　　大可：“你为什么列出这几个场景呢？看起来[恶劣天气未拿到钥匙未看成房屋]是一个很小概率的场景啊？”

　　土豆：“是的，现实中，这个场景发生概率很低，但这种情况下，也非常容易产生客诉，如果处理不当，客户就会投诉。我分析过投诉数据，这类投诉还挺多的，所以我觉得这个场景虽然发生概率低，但是非常重要，于是列在这里。”

　　大可：“很好，这也是我们做场景分析的意义，要贴近实际业务发生的情景！虽然我们是产品经理，设计的是软件产品，但如果想把软件做好，必须深入到业务，跟踪业务真实发生的情景，例如针对极端天气，是不是有相关的危机预案，或者软件中能否提前进行预警提示？这都是可以改善服务品质，提升体验的点。但是如果我们只是被动的坐在办公室接收需求，远离这些场景，那么就会措施改善、解决问题的机会！”

　　土豆：“是啊，对于这点，我也有很深的体会，不过，对场景分析的这么细致，会不会工作量太大了，图4-5只是针对一个任务的场景细化，就能得到这么多子场景了，如果把业务人员的所有场景都分析出来，感觉我一个月都不用下班了啊！”

　　大可：“围绕场景，寻找业务机会点，提升用户体验，本来就是一个繁琐的工作，也是帮助你进一步理解业务的机会。现实中，根据实际需要掌握分析的深浅和范围，更关键的是，要始终具备从画像用户的视角洞察旅程的思考习惯。”

　　土豆：“明白了！”

　　大可：“接下来，我们一起看看得到的场景地图，如何具体应用与业务、体验优化工作中。”