B端产品用户体验地图绘制流程

一、综述概论

2021年在创业公司参与了公司一个核心项目——某省会级国家电网生产调度综合大楼数字孪生智慧楼宇1~2迭代阶段研发项目。

本人在团队内负责产品部分，主要工作内容包括需求对接、用户分析、交互定义、数据整理、原型输出等（因初创公司体量有限，产品+交互二合一也就见怪不怪了），同时也参与视觉评审、项目解说（毕竟自己挖的坑要自己填）。

项目概述：该项目是基于数字孪生技术三维可视化的智慧楼宇系统，包括：

• 楼宇状态监测（用电、能效、水浸等全方位监测）
• 楼宇智慧运维（自动派发工单、工单进度追踪）
• 传感器自身运行状态监测
• …

【PS：百度百科对数字孪生的定义如下：“数字孪生是充分利用物理模型、传感器更新、运行历史等数据，集成多学科、多物理量、多尺度、多概率的仿真过程，在虚拟空间中完成映射，从而反映相对应的实体装备的全生命周期过程。数字孪生是一种超越现实的概念，可以被视为一个或多个重要的、彼此依赖的装备系统的数字映射系统。” 数字孪生对各个行业的赋能不同，由于本人自身水平有限，故不过多讨论数字孪生概念，请各位感兴趣的朋友自行查阅相关资料进入深入了解 】

在我们的实际项目中可以简单理解为在电子化办公的基础上加入三维可视化场景，例如：

• 三维场景线上远程运维
• 日常运维路径追踪
• 抢险救灾及时响应
• 抽象数据3D可视化（配电线路可视、设备运行状态可视、电气火灾监测可视等）

在这里更多的想探讨总结如何利用“用户体验地图”这一设计方法论为B端产品进行切实有效的赋能。

在此之前，先大致总结“用户体验地图”与“B端产品”各自的特性，以及在此基础上如何在B端产品中利用这一方法论为设计工作增值，最后以本人亲历的实际项目进行推演复盘，总结绘制B端产品用户体验地图的一般流程与特点。

二、基本概念

1. B端产品

B端，代表企业用户商家，英文是Business，是互联网产品中的商家界面（即：管理平台）。用户通过它进行日常的商业活动，例如企业库存管理，销售统计，员工出勤考核等等。可以说，用来解决企业需求的产品，都是 B 端产品。

以上定义来自百度百科。

关于对B端的定义，各种网站论坛的帖子数不胜数，这里不做评判该定义的边界范围及对错，个人认为由于B端产品在不同行业、不同业务场景、不同客户需求以及不同产品形态之间所表现出的差异不同，故每个人对B端产品都有自己的认识。

借用文学大佬莎士比亚的话来说“一千个读者眼中就会有一千个哈姆雷特。”

就当前项目而言，本人对B端产品特性的通俗认识如下：

为产品买单的甲方不是产品的直接使用者而是管理层或领导层。公司当前项目甲方是某省级国网单位后勤公司，而产品的核心用户是基层班组及各组运维人员，二级用户是中层管理者，例如各部门主任、办公室主任等。

对于领导层而言，基本不会直接使用产品，他们关注的更多是产品上线后，节省了多少人力运维成本、提高了多少设备安全指数以及如何将事故损失降到最低值等…

对于产品需求需要深入甲方公司/团队/组织工作环境面向产品未来的直接使用者进行调研；双方达成合作共识之后，仅根据甲方领导层/决策层对于解决方案的预期与建议（当中可能包括某些隐晦的需求表述）是远远不够的。

个人认为，该类B端产品的特点在于专业领域的深度较深，往往需要巨大的学习成本，这里的学习成本指的是对特定行业/领域的认识和了解以及对客户现有业务流程的熟悉程度。

就该项目而言，当前产品模块主要是电力系统的监测与运维，对于产品人员而言需要深入基层的业务环境中去调研需求，调研之前需提前对业务场景、工作环境有一个大致的了解与认识。

例如，对于电力系统而言，产品人员需要首先了解高压/低压、变压器机组、三相电流/电压、能耗、功率等基本概念，而后根据实际需要，进行“用户访谈”、“实地调研”。

如果条件允许（开发周期、项目预算等）的话，研究人员最好可以驻场调研，实地体验运维人员的工作环境、任务流程、设备养护操作流程。

驻场调研期间，在与运维人员的沟通中可以发现更多有价值的信息。设计优劣之处自安于对细节的把控程度，正所谓当局者迷旁观者清，当产品人员在观察运维人员的动作习惯、操作细节时往往能发现很多可以优化并且值得优化的地方，而这也正是用户在描述当前工作流所存在的问题时最容易被忽略的地方。

正如福特汽车创始人-亨利福特所说：“如果听用户的，我们根本造不出汽车，用户只需要一匹快马。”

如果客户只是认为日常设备运维这一重复性动作繁琐且枯燥，我们可能只会进一步简化流程，例如从一天巡检两次优化到一天巡检一次、每隔4小时巡检优化为每隔6小时巡检、纸质签到优化为电子签到…

但是在驻场调研过程中我们发现，日常运维的根本目标是对设备实时运行状态进行监测，确保整栋楼内所有变压器机组、配电箱运行状态正常，这里我们提炼的关键词为“所有”、“实时状态”。

由此得出客户真实需求是对所有设备7*24小时运行状态的不间断检测，为解决这一问题，可以将运维人员工作范围内的所有设备安置智能传感器，通过数据传输将所有设备运行状态，实时参数等进行可视化显示，发生故障/险情时第一时间通知相关班组负责人。如此一来，既节约人力成本，又提高运维效率。

产品解决方案应尽可能满足甲方各类用户群组的需求，因为面对同一产品，不同用户群组的关注点不同。

该项目的用户群组分为三类，分别是决策层、管理层、执行层。

决策层包括国网后勤总经理、副总经理，管理层包括部门主任、办公室主任、运维班组负责人，执行层包括各班组成员。其中执行层可以归纳为产品的核心用户（高频用户），管理层成员为二级用户。

不同群组用户对产品的需求和关注点有较大差别。

决策层（相关用户）虽然对产品的使用频率较低，但其关注点在于周期性宏观把控，例如楼宇生命健康度的周期性变化、如何优化组织架构、宏观的数据分析、投入产出比等全局问题。

管理层用户关注点在于如何有效降低安全隐患、对于安全事故如何提高响应速度、各班组之间如何高效协作的问题。

执行层用户为一线工作人员，对于产品本身没有过多的话语权，但却是最能发掘用户真实需求的一组群体，从他们的实际工作流程、工作环境中可以观察到当前工作流值得优化的地方。同时他们所反映的一些情况，也是最真实、最直观的问题，对产品人员提炼用户需求有极大的帮助。在进行产品调研、构建产品逻辑架构时，应从不同用户群体出发，听取不同用户群体的声音，综合分析后得出最优解决方案。

B端产品的最终目的是解决问题，产品的核心功能可能不止一个，且各功能间相对独立，不同功能涉及不同的业务场景，其对应的设计思路也不尽相同。

该项目为国网生产调度大楼智慧后勤平台，其核心的功能应该是与电力系统密切相关，例如电气火灾监测、设备运行状态监测等，但从“后勤”的角度出发，却远不止楼宇电力系统，正所谓“水火不相容”，楼宇内部密集分布了上百个精密仪器，与之伴随的就是上百条回路信息，而回路运行过程中最危险的情况之一就是由楼内漏水引发的短路对用电设备造成的巨大损失。

而楼宇水系统（包括但不限于给排水管道、空调水管道、消防水管道等）与电力系统基本毫无关联（不可否认的是供水设备需要电力供给），但在后勤系统中确是不可忽视的一个子系统。

如果说水系统与电系统是相对独立且平行的两个子系统，那么用电设备运行状态与电力能效则可以理解为二者呈线性因果关系。

在用电设备安全运行的前提下所必须考虑的是能效的高低，能效包括用电能耗、用电负荷、同期增长率、电能质量等多个参数，这些参数又可以做进一步细分。

例如用电能耗可分按“峰平谷”用电时段分为细分或按照设备类型进行分类能耗分析，电能质量可以分为电流质量和电压质量，而电能质量问题又是由频率偏差、电压偏差、三相不平衡、谐波畸变等多个参数异常引起。

所以电能质量作为衡量能效的重要指标，虽然与“电气设备安全”同属电力系统，但二者业务场景及数据信息大相径庭，再加之政策影响：“中国承诺在2030年碳达峰，2060年碳中和”，以国企、央企为代表的的大批企业开始关注能效比（能效比即能源转换效率之比）或能源产出率（单位能源产出情况，该指数越大表面能源利用效率越高）。

由此可见，能效监测更多涉及到的用电设备的实时数据或高阶数据分析，与用电设备运行状态监测的相同之处仅在于目标对象一致，但各自模块背后的业务场景相对独立，用电设备运行状态是对变压器机组运行状态、回路状态以及用电设备运行状态进行监测，而能效监测则是对该类目标设备用能进行数据统计、数据分析以及数据预测等。

综上所述，对于国网智慧后勤项目而言，用户的核心诉求表现是多方面的，且各方之间相对独立，不存在明显的需求优先级之分。故我们在进行产品策划与设计时，需要深入了解各业务场景，以及业务场景背后的逻辑或影响因素以及不同业务场景的具体表现形式（抽象到具象or二维到三维or复杂到简单）。

由于所在领域、业务场景、用户群体、项目预算不同，B端产品竞争壁垒较高，竞品分析具有一定局限性，在不了解相关竞品的具体业务场景与用户需求的条件下盲目的做竞品分析，最终收益会微乎其微。

竞品分析是我们在进行产品设计时最常用到的一种产品分析方法。由于本人工作经验有限，对于B端产品的竞品分析方法论尚未有全面系统的实践经历，目前仅结合当前工作经验和相关文档信息对B端产品的竞品分析存在的局限性做以下概括（以下信息参考自“两只猫爸”署名文章“B端产品如何做竞品分析？”。文章链接：http://www.woshipm.com/evaluating/4250256.html。感兴趣的同学可自行查阅）：

（1）B端产品的个性特征多于共性特征

因为B端产品多是公司企业根据自身组织特征、业务场景、地域特征、收益情况而深度定制的解决方案，同类产品的个性特征明显大于共性特征，同时还与产品研发团队自身水平相关。

正因为“世界上没有两片完全相同的树叶”。所以我们在定义对标产品或选择相关竞品时，不能刻板地、按部就班地对竞品的功能定义、视觉风格、交互逻辑进行评判。

该设计对于这一场景是好的设计，可能并不适用于当前场景。

（2）产品相关的有效信息匮乏

由于B端产品多面向企业组织，产品使用群体有限，仅为企业内部人员。

且B端产品的主要壁垒之一在于其价格昂贵，交付形式为一对一全流程交付（开发团队交付至甲方内部并提供一定的培训课程和技术支持，全程对第三方及以外人员进行保密）。

当我们想了解竞品相关信息时，可搜集到的信息有限，其中具有参考价值的信息更是少之又少，因此成为影响B端产品分析的重要因素。

（3）行业壁垒

因为B端产品作用于各行各业（传统制造业、医疗、教育、餐饮等），其行业特点各不相同，某些行业的行业门槛较高，例如电力行业、医疗行业等。

这就要求产品研究人员在进行竞品分析前需要具备相关行业的基础知识，而这些行业知识是需要大量的时间成本去学习，无形之中提高了产品的开发成本和开发难度。

（4）由于产品的买单者和使用者通常属于领导与被领导的关系，二者之间的需求在一定程度上可能会相互冲突

在产品设计时要尽量规避这类冲突，尽可能平衡二者需求。

如上文所说，对于该类产品而言，一个产品的不同用户群体的关注点与用户需求不同，而这些来自不同用户群体的用户需求会有一定的矛盾性。

例如从决策层出发，此类用户群体想借助该产品尽可能的实现“智慧后勤”，他们对智慧后勤的期望不仅局限于提高效率，降低成本，更希望可以借助该产品提高可量化的安全保障（稍微夸张一点的说，为满足甲方需求提高促单率，显示产品的可靠性与安全性，向决策层领导保证安全事故的最小损失范围与最快响应速度，且与律所等仲裁机构达成一致，若产品未达到对应水平可加倍赔付或有乙方承担相关法律责任）。

但根据执行层一线运维人员所反应的业务场景得知，此类数据难以量化或无法量化（也可能运维人员出于责任归属问题考虑，不愿为设备安全运行划定具体的阈值范围，毕竟安全事故事后问责要承担相关法律责任，基层运维人员出于自身角度考虑不愿为此担责或自身专业水平有限，无法为此提供有效信息）。

运维人员更多反应的是提高个人效率方面的诉求。此时，决策层所关注的可量化的安全保障这一需求，需要执行层运维人员提供真实有效的数据支持，但运维人员无法提供数据支持，且运维人员关注点在于提升运维效率。

如何平衡两类需求的矛盾也是B端产品设计时需要特别注意的一个方面。毕竟要同时兼顾多用户群组的用户需求，不仅要满足产品直接使用者（执行层运维人员）的需求，也要兼顾最终为产品买单的决策层（总经理/副总经理）对产品的期望和诉求。

2. 用户体验地图

我个人对于用户体验地图（Customer journey map, CJM）的理解是将自己（产品设计人员）带入用户的工作环境中并以上帝视角不带任何感情色彩的体验用户真实的工作流程，观察并记录用户的每一步动作直至该流程结束。

绘制用户体验地图可以简单理解为以上帝视角看故事并真实还原的过程，并最终将所看到的故事演绎到合适的载体中。

用户体验地图通常由以下几部分组成：人物特征、阶段、目标、行为、接触点、想法感受、情绪曲线、痛点（爽点）。

这里我借用记叙文写作五要素：时间、地点、人物、事件、结果来概括用户体验地图方法论。

用户体验地图示例

（1）时间即用户体验地图的时间线（阶段）

根据爱因斯坦相对论所说，我们生活所面对的三维空间再加上时间构成所谓四维空间。

三维空间是静止不动的，不能构成完完整的故事情节，是影视动画中所谓的静帧。虽然静帧也可以极具表现力，但是不能构成一个完整的故事。

在用户体验地图中，时间作为第一要素，时间线贯穿了用户体验过程的始终，是我们分析用户体验的线性依据。

以网上订餐为例，订餐过程可以分为以下几个阶段，分别是：

• 订餐前（个人产生订餐想法）
• 订餐过程中（选择订餐软件、查看卖家评价、与卖家沟通、选择配送时间）
• 订餐后等待送餐（关注送餐人员是否能准时送达）
• 用餐过程中（与网上看到评价做比较）
• 用餐后（留意好评返现等商家优惠活动、积极参与评价评分等互动）

整个流程中，用户故事是线性展开的，时间是整个故事分步进行的基本依据和参考。

（2）地点是一个故事（用户体验地图）中的客观因素

依然拿订餐举例，用户周围的环境特征会影响订单成交率，用户所处的位置周边有多少商家提供外卖服务、饭菜种类是否齐全、商家出餐时间、饭菜质量、配送时间以及是否免配送费等一系列客观因素都会影响用户故事的走向。

言归正传，产品设计人员在以上帝视角体验用户工作流的时候，应该提前了解业务场景或故事环境。以便理解用户动作的前因后果，防止片面孤立的看一副静帧图像。

（3）人物是整个故事中除时间之外的第二个贯穿始终的元素（人物特征）

人物是推动故事发展的主观因素。什么人做了什么事，带来了怎样的结果和影响，这个过程中又发生了什么意想不到的情况…

还是以订餐为例，用户故事走向客观上收到环境因素影响，主观上收订餐用户的人物特征（年龄、职业、收入、消费观念、口味偏好、文化程度等）影响，比如在校大学生与职场人士的订餐时间会略有不同，职场人士一般订餐集中在中午，在校大学生可能会集中在晚上。学生群体可能更加关注优惠力度，高收入职场人士可能偏向于菜品质量等。

相同的客观条件下，不同的主观意向也会带来不同的故事走向。用户在一定范围内（客观限制）内具有比较灵活的选择或想法，所有这些都是以人物为载体去表现。

“以人为本”的设计，说的正是以人为主体，优化体验过程，也印证了人在用户体验地图中的主体作用。

在叙述用户故事时，要先将各个用户的故事背景区别开来，不同的人物有不同的剧情。区别“人物背景”这一操作对应在用户体验地图中就是创建用户模型。用户模型应该是具有代表性的、容易引起大众共鸣的且符合故事背景的，而不是个性的、特立独行的。

（4）事件就是剧情（行为与触点）

一个剧本，确定好时间、地点、人物之后，就可以开始写剧情了。

还是以订餐为例，在订餐过程中你进到一家感觉还不错的店里，你会联系商家确认菜品口味或菜品多少，但由于店家回复消息特别慢导致你失去耐心选择了另一家。

又或者当你下单之后从店家处得知好评返现活动，你在用餐之后感觉饭菜口味符合预期并积极参与互动领取返现或平台积分，增加了对卖家或订餐平台的好感度，促使你下一次订餐优先考虑该商家，从而逐渐商家成为稳定的客源之一。

在绘制用户体验地图时，对于故事的内容要尽可能的细致，“细节决定成败”说的没错，用户对产品体验的感受往往藏在细节里（例如平台积分、服务评价等活动），而这些细节往往就是用户自身难以表达的痛点，痛点的背后就是需求，需求就是产品功能的来源。

所以在叙述事件（用户体验流程）时，做到“事无巨细”总是好的。

（5）结果是人物动作的反馈

在用户体验地图中，我倾向于将“结果”理解为用户反馈（想法、情绪曲线、痛点爽点），用户在行径过程中每一个行为动作的反馈都可以理解为是一个“结果”。每个动作的反馈结果串联起来构成用户整个故事（工作流）的心路历程，包括心理变化、对产品的认识、印象以及是否实现自我满足（达成预期目标）。

依旧拿订餐举例，你在产生订餐想法（需求产生）后会选择订餐平台、筛选商家别、比较价格等一系列操作。此时你的同事or同学向你推荐了一款订餐平台，因为该平台会定期向用户发放优惠券。此时你的情绪可能会被调动起来带着有便宜不占的想法选择该平台。

但是进入之后你发现该平台商家种类有限，没有你喜欢的商家或菜品，现在你的心态是领了优惠券又没地方花的爆炸心态，在看了几个商家的口碑评价之后，你迈出勇于尝新的第一步，在送达之前心里默念不要迟到不要迟到，尝过之后发现没有翻车是长舒一口气的心里窃喜（捡到宝藏卖家）。

在用户体验地图中，面对一个故事不同阶段中用户的情绪波动曲线，要做到有则改之无则加勉，那些让用户感觉舒适愉悦的反馈要继续做的更好，让用户感觉不爽想吐槽的反馈要努力优化体验细节，抚平用户心理。

“结果”作为最后一个要素，是前面四个要素共同作用的结果。

前面四个要素中任意一个出现问题，都会影响结果的反馈。在前面四个都梳理清晰之后，反馈结果就会自然而然的浮出水面。

产品设计人员根据不同阶段的反馈结果分析产品可以优化改进的地方。当然，优化过程不会是一步到位的，因为影响结果的4个因素中，既有主观因素也有客观因素，二者都不是一成不变的，任何一个出现变化都会影响用户故事的走向。

最后结论：大家在绘制用户体验地图时就想象成初中写作文（当然没有800字的字数要求），文章内容越生动、越细腻，判卷老师就（开发团队和老板）越喜欢（因为越具说服力）。

3. B端产品与用户体验

“对于任何一款产品的用户体验，无论你关注与否，他就在那里。”——非著名UX从业人员沃兹基硕德。

在网上查了很多资料后发现，看到一种呼声还是比较高的，“B端产品重功能、轻体验”、“B端产品的用户体验不是重点”等声音。孰对孰错，在这里不做评判（本人也不具备评判的能力）。

但是不可否认的是任意一款新产品的出现，应该是首先解决了已存在的产品所不能解决的问题。但是随着中（hu）国（xiang）速（mo）度（fang）越来越快，你的用户群体可能会被别的同类产品挖墙脚，挖墙脚的原因有两个：

• 同样的产品，对面有你没有的功能
• 同样的功能，对面做的比你做的好

总结下来就是“人无我有，人有我优”，否则就不能怪用户喜新厌旧（用户都是渣男渣女，产品人员默默流泪）。

“人无我有”的重点在于产品功能的创新，“人有我优”的重点在于用户体验的创新，这么说应该还是容易被理解的。

对于创新类产品（市面没有的产品或功能），只要做到人无我有就算成功，毕竟是第一个吃螃蟹的人。但是在市场中同类产品或功能>1的条件下，“人有我优”的重要性显而易见。

对于创新类产品在这里不做讨论，毕竟第一个吃螃蟹的都是少数人，况且用户体验是一个“人有我优”的过程。那在这个过程中，用户体验的好坏，很大程度上影响了用户忠诚度。

“你做的不好，就不要怪被人做的好”。从这个角度看的话，无论对B端产品还是C端产品，用户体验都对用户留存产生重要影响。

我认为二者区别在于：B端的用户体验建立在解决客观问题、提高工作效率的基础上，C端的用户体验是建立在满足大众需求和帮助用户实现自我价值的基础上。

二者的作用基础不同，研究人员也就没有必要从产品属性的角度对用户体验做“即决高下，也决生死”的判定…

如果B端产品的用户体验是建立在伪需求或理想需求的基础上，不要说用户体验了，就连交付都过不了就被甲方一顿喷，做的再花里胡哨也没有用。

但是人的欲望是满足不了的，基本需求被满足后会进行“需求升级”，从产品功能的“能用”到“好用”，从“一尺宽”到“ 万丈宽”（需求升级的过程可能是甲方自知自觉的，也可能后知后觉的，还可能是产品人员自我反省的结果）。

在这个过程中，如果是纯粹的新功能的产生，对应的是新需求（说明产品团队前期需求的挖掘广度不够），如果是在已有功能上的迭代升级或拓展，可以理解为就是优化用户体验的过程（前期需求挖掘的深度不足）。

无论是对新需求的挖掘还是对现有功能的优化，“用户体验地图”是一个都是一个不错的选择。

4. 用户体验在B/C端的适用性区别

本人查了很多资料，也看了很多产品大佬关于用户体验地图的文章之后发现，大部分关于用户体验地图的案例分析都是基于C端产品，同理，用户体验也被更多用在讨论C端产品身上，那么用户体验对于B端和C端的价值区别在哪里。

如上文所说，B端的用户体验建立在解决客观问题、提高工作效率的基础上，C端的用户体验是建立在满足大众需求和帮助用户实现自我价值的基础上。

这个结论是通过分析产品定位和产品功能之后得出的。如果我们再向深处分析，市场上无论哪一种产品，其本质都是商业产品，不论是产品团队还是设计团队都服务于商业目标1，产品团队的焦点在于发现商业价值并论证该价值点的真伪，设计团队的焦点是利用设计为商业价值增值。

同样是服务于商业目标，但是B端和C端的受众对象以及实现商业目标的手段却是不一样的，导致用户体验的关注点也不一样。

C端产品服务于个体对象，其商业目标是通过提供某种服务并吸引用户产生消费行为为其买单（充值、下单、订阅等），其本质是吸引用户“花钱”买服务。

B端产品服务于商业公司，其商业目标是通过提供某种服务来提高效率，减少成本（例如各种管理后台），其本质是帮助用户“省钱”，省到就是赚到，B端产品其实是变相的为用户“赚钱”。

这样看来，“用户体验重C端轻B端”也就见怪不怪了。

C端产品吸引用户花钱，为产品提供的服务买单，例如充值VIP享受特权。所以C端产品需要高频迭代，不断优化用户体验，因为用户花钱了，从用户角度出发花钱了就要享受最好的服务。

B端产品帮助客户省钱，省到就是赚到。甲方领导是想花一块的钱办两块的事，无论是为了降低成本还是提高效率，购买某产品就是为了花最少的钱办最大的事。

那为什么B端的用户体验难做呢？根本原因在于“花钱容易赚钱难”。

谁都想花钱，花钱带来的快感多爽啊，何况C端产品有100种让你花钱的方法（就是不断优化用户体验的过程）。

那省钱怎么办呢？最简单的办法就是开源节流。

B端产品其实就是一个省钱的手段，但是问题就在于大家（B端客户）都想省钱，怎么省钱可以最有效并且最舒服（花100省20还是花150省50），这就是B端产品用户体验的价值所在。

即便用户体验差，客户也可以接受，大不了这个省钱的过程不太舒服，省的少一点。但是如果用户体验越好，省钱过程就越舒服，省下的钱也就越多。

所以也就不怪B端产品用户体验总被吐槽，根本原因可能在于甲方的选择。

以财务管理系统为例，假设该系统价值100块，甲方经评估后发现花100块购买该产品后可以减少20块的人力成本，意味着产品的单位价值比是5：1，当系统优化过后，系统总价值变为150块，如果客户购买新系统，则可以减少50块的人力成本，产品的单位价值比是3：1。

同样是节约成本，甲方可能会觉得既然已经实现是花100省20的目标，何必多花50买新系统只为多省30。

从这里不难看出，甲乙双方对于产品价值的计算方式是不同的，在甲方眼中只做差价计算，而忽略了产品的单位价值比。而提升产品单位价值比的过程，恰好就是提升产品用户体验的过程。

三、案例推演

以上述项目为例，推演绘制用户体验地图的流程。该项目的用户需求来自于用户访谈、实地观察以及用户反馈。

首先根据利益相关者地图的理论，将用户分为“核心用户”、二级用户和周边用户分别对应为“执行层”、“管理层”、“决策层”。在开始创建用户体验地图之前，先根据用户群体分别创建用户模型。

1. 用户模型一

2. 用户模型二

3. 用户模型三

4. 绘制用户体验地图

“智慧后勤”平台的设计指导原则：

• 满足各类用户群体的工作需求
• 提高工作效率、准确率
• 提高横向（各班组）与纵向（班组与上级）之间的沟通协作能力

基于上述用户模型将分别创建与之对应的用户体验地图，这里以核心用户群体，运维班组负责人为代表进行示例。

由于时间关系，用户体验地图以文本形式进行展示，以1-5表示情绪节点（3表示初始值，向下表示情绪负增长，向上表示正增长）

（1）运维班组负责人的“用户体验地图”

用户任务目标：查看各子系统运行状态和实时参数、向各班组成员派发工单。

通过用户体验地图总结归纳的痛点与机会点，结合用户行为的情绪值，可以对进行需求优先级进行排列，最后根据开发周期、开发成本等因素综合考虑是否进行优化。

四、总结概括

用户体验地图的绘制过程确实需要消耗大量时间，并且最好是在有一定数据支撑或用户研究的基础上进行，否则其赋能作用十分有限。

用户体验地图作为产品设计过程中的一个工具，应当注重对产品的思考与逻辑的表达，切忌本末倒置过度注重视觉效果而忽略产品背后的逻辑。

本文作者 @第一生瓜蛋子 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！