每日埋首于这个页面的改版、那个功能的迭代，是否真正理解手头这些设计工作对于整个业务的价值？又能否衡量每处新设计对于用户体验的影响呢？

其实，设计师完全可以不像游击一样，哪里发现问题就跑去设计哪里，而是运行一套良性的机制，帮助整个团队，从更全局的视角去观察用户和洞察业务，让产品持续地提升体验，让团队持续地做出对的决策。

近几年，我们一直在探索这种良性的机制，做过很多尝试，也看到一些慢慢成型的方法，给业务带来了实际的益处，设计师在团队中输出的价值也越来越有分量。这里想和大家分享的，就是我们对于体验管理机制的一些思考。

用户体验设计 VS 用户体验管理

要解释“用户体验管理”，我想和“用户体验设计”对比起来说，会更清楚。用户体验设计关注的是“完成一次有效的设计”，获得某个问题的具体解决方案；而用户体验管理关注的是“运行一个有效的机制”，让团队运行一套能够持续提升用户体验的工作方式。

关于体验问题池的反思

体验问题池是我们曾经尝试过的一种体验管理机制。我们通过各种方式收集用户的体验问题，放入问题池进行状态管理与共享，并在每个产品周期中逐个推进问题的解决。

体验问题池

这样机制的引入，似乎给设计工作带来了些进步之处：

1. 我们有了清晰的Check List，待解决和已解决问题一目了然；
2. 每个体验问题都有明确的优先级，解决时有轻重缓急；
3. 只要我们持续推进迭代，就能持续解决问题；
4. 使用线上团队工具，方便信息的管理和共享。

一切似乎非常美好，但实际上又暗藏着危机，体验问题池给团队带来了什么样的风险呢？

共情不等于洞察

我们和用户一样痛，并不代表我们对用户体验有更全局的认知，更深刻的洞察。

关注局部问题，可能错过创新机会

越关注局部，就越容易获得局部的解决方案，也就意味着更可能错失颠覆性的新流程与新体验。就像我们如果只关注于用户损坏的地图，就更可能提出修补地图的解决方案，而错过提供手机导航的创新机会。

紧急问题不等于紧急目标

帮助业务在市场中竞争，及时抓住机会有时比解决问题更重要。因此，我们制定目标时，不能局限在解决某个问题上。比起“解决地图损坏的问题”，“为用户达到目的地，提供更高效的新方式”或许是更有价值的目标。

同步信息不等于达成共识

只与合作方共享一份庞大的清单，很容易进入到只有设计师干着急的状态，产品和技术角色处于被动合作的位置，而没有形成共同的目标和愿景，合作难以顺畅。

工作量不等于工作效果

我们能非常直观地看到解决过多少问题（还不一定真解决了），但仍然无法测量，在这些工作之后，用户的体验究竟发生了多少变化。

那么，更好的机制应该是什么样呢？目前，团队正在运行的体验管理机制，更重视全局化的体验洞察，可量化的体验指标，以及团队共识的建立。我们把这样的机制称作“全局化体验管理”。

全局化体验管理

全局化体验管理的关键流程，划分成5个重要阶段：

全局化体验管理流程图

1. 俯瞰

在俯瞰阶段，我们需要获得用户体验的全貌，通过可视化模型制作体验全景图。这里推荐几种适合俯瞰全貌的可视化模型：

用户体验地图／User Experience Map

用户体验地图从用户视角出发，展现用户在整个旅程中的体验情况。当业务提供的是流程型服务时，比如租房、找工作，用户体验地图就很适合用来展现体验全貌。下图是我们为58租房业务制作的租客用户体验地图。

租客用户体验地图

（2）服务蓝图／Service Blueprint

服务蓝图是从系统视角出发，展现业务系统和组织是如何运转，支持用户旅程的。如果业务同样是流程型服务，并且后台系统相对复杂，可以在用户体验地图的基础上，结合服务蓝图，帮助我们建立更完整的图景。

（3）生态地图／Ecosystem Map

生态地图能够从用户视角和系统视角出发，展现用户在不同维度上的体验状态及系统支撑方式，因此适合展现非流程型服务的体验全貌。

选择适合业务类型和观察需要的可视化模型，制作体验全景图，能够帮我们有效地构建俯瞰视角，便于下阶段的观察。需要注意的是，全景图要尽可能展现用户全程体验的情况，而不局限于用户在产品中的行为。

用户体验地图是我们在业务中最常使用的模型，具体制作方法不再赘述，以58招聘全职应聘者的体验地图为例，说明基本概念和读图方法，便于后面内容的阅读。

体验地图包含三个基础部分：满意度曲线图、感受量化图、倾向量化图。

（4）满意度曲线图

展现用户在旅程中各个关键接触点上的满意度值，对用户的体验做量化概括。

招聘满意度曲线

服务阶段&接触点：将接触点划分为不同的阶段，划分的原则是“用户在这些接触点上带有共同的阶段性目标”，比如用户在APP中进行搜索、筛选、浏览，这些接触点背后的目标都是寻找需要的信息，可以划分到一个服务阶段中去。这样做的价值在于，理解了每个阶段背后的用户目标，我们才可能为用户实现目标设计更好的方式。

满意度值：通过定向的问卷投放，统计各接触点的满意度值，将主观感受量化为体验趋势。

基准线：各接触点满意度的平均值，代表服务体验满意度的整体水平，我们把它作为基准线，来衡量各接触点的体验高低，同时也用来与行业基本分值做对比评估。

兴奋点／一般点／沮丧点：以基准值为界限，划分兴奋点、一般点和沮丧点。一般点和沮丧点可以视为服务体验的短板，值得我们重点观察与分析。

（5）感受量化图

展现各服务阶段中，用户的痛点、惊喜点，暴露并量化各阶段的用户感受。

招聘感受量化图

（6）倾向量化图

展现用户的喜好、态度等信息，如用户在浏览列表时，对于不同信息的关注程度，这些信息同样是需要量化的。

招聘倾向量化图

这样，我们在俯瞰阶段获得了能提供全局视野的图表。值得注意的是，不论使用了哪种可视化模型，都只是对信息的重新组织与展现。而被组织的信息依然是信息本身（不是结果），仍需要我们进一步观察和思考，才能产生有价值的洞察。

2. 洞察

洞察阶段要做的，是通过观察体验全景图，明确业务当前的关键挑战，并根据挑战制定下阶段的关键目标。我们通过“两个反思”的方法，来引导思考，产生更有效的洞察。这两个反思，分别是反思“点”和反思“段”。

（1）反思“点”

用户的沮丧点和一般点有哪些？沮丧背后的本质原因是什么？

（2）反思“段”

每个服务阶段中，用户达成阶段目标的方式是什么？这样的方式有什么问题？

举个例子，我们来观察一年前58租房的租客体验地图。

租客体验地图反思点

反思点时，我们能看到体验不佳的接触点不算少数，但再分析各阶段的严重痛点，便会发现联系沟通、预约看房、实地看房这几个环节中，用户不满的主要原因都是直到这时候才发现，房子不符合自己的要求。

所以，隐藏在体验低点背后的本质原因，是用户无法在线上更充分地判断房子是否符合要求，造成之后的联系和看房，变成了白费力气和白跑一趟。以此类推，我们会发现，往往在众多的体验低点背后，本质原因只有关键的几个。

反思段时，我们发现，在查找房源阶段，用户通过阅读图文信息的方式，判断房子的具体情况，但这种方式形式单薄，信息传达效率低，不确定性也非常高；再比如在租房决策阶段，用户要反复通过联系房东、约看、实地看房的方式，了解多个房源，过程麻烦，性价比也很低。

在两个反思之后，我们便能整理出业务正在面临的关键挑战：

1）用户无法在线了解更具体的房源信息；

2）后续流程缺少监管。

由于获得了这样的洞察，我们未来的关键目标也随之变得异常清晰：

1）为用户提供更前置地在线了解房源的新方式；

2）全流程平台可监管。

关于制定目标，这里要时刻小心局限性目标。举个例子，比如目标A是“设计一个杯子”，目标B是“设计一种喝水的方式”，你认为哪一个是局限性目标呢？如果我们的目标中已经出现了具体的方式，那么它大概率是会限制我们发散解决方案的目标。

3. 共识

共识阶段的主要目标，是推动整个团队对于前期的结论达成充分共识，建立共同的阶段性目标，并在此基础上制定推进计划。

如何达成共识，组织一场全员宣讲会是个好方法。把业务团队都邀请来，分享前期的发现、面临的关键挑战和目标，让每个环节的相关成员都对现状知情，引发共鸣和重视。我们也会在宣讲会上针对关键目标，从设计师的角度抛出一些草案，激发团队的思考和方向探讨。

关于制定计划，同样需要多种角色共同制定，再拆分到各角色的具体计划中去。比如在转转的一次阶段性计划中，客服体验成为当时的关键挑战，我们便邀请客服团队的同学从天津来到北京，共同参与宣讲会，同步问题所在，并将提升客服体验的细分目标明确下来，客服同学也马上制定了具体的提升计划。这个接触点的满意度在下个周期的俯瞰中，表现出显著的提升。

4. 设计

设计阶段或许是我们设计师最熟悉的，这时的关键是以阶段性目标为中心做设计。关于敏捷设计与测试的流程方法，这里就不多讲了，只分享两个重要的体会。

（1）别觉得头脑风暴已经被玩烂了

在针对某个目标寻找解决方案的道路上，头脑风暴仍然是利器。或许曾经经历过一些无效的、令人失望的脑暴会，让你觉得这东西徒有其表、毫无意义。但脑暴作为一种创意工具，同样需要我们在使用中对它进行迭代，摸索更多适合自己团队，适合当前目标的组织方法。

头脑风暴

（2）是时候开始进行双重验证

产品数据是长期以来验证设计的主要手段，但产品数据只能验证行为，而用户的心理及态度同样需要更精细化的验证。因此，我们逐渐在业务中融入双重验证的方法，在设计的验证阶段，通过产品数据监测行为变化，同时通过用研数据监测态度变化。

5. 再次俯瞰

再次俯瞰阶段的目标，是回溯上个阶段的工作，开启下个阶段的管理循环。通过对用户体验的再次量化和对比，我们可以直观地看到每个阶段的团队工作，给用户体验带来的影响和变化，对上阶段的工作进行精细地复盘与总结，再开始产生新的洞察，制定下阶段的目标。

转转满意度对比图

图中是为转转APP以半年为周期制作的用户满意度对比图，可以看到在一个阶段的工作之后，各个接触点的用户满意度都有了不同程度的提升。我们会逐个梳理哪些工作带来了这些提升，从而在复盘中，获得新的认知。

6. 一切还没有结束

当然，我们的探索远没有结束，全局化体验管理的基础流程帮我们对用户体验进行周期性的观测、理解并明确下阶段的方向。但不论任何方法，永远有迭代的空间。我们正在为全局化体验管理方法的更进一步，做两方面的尝试。

（1）从“用户视角”到“用户系统双视角”

目前，在各个业务中使用的可视化模型，都是以用户体验地图为主，完全以“用户视角”来展现体验现状。但我们的很多业务背后，都存在相当复杂的组织和系统，牵扯到很多第三方、业务角色、渠道及线上线下的丰富场景，这些组织的运行方式，是对用户体验产生影响的主要因素。

因此，我们开始尝试在俯瞰阶段，以用户体验地图为基础，增加服务蓝图来展示组织运行结构，拓宽我们的观察视野。

（2）从“周期回顾”到“实时监测”

由于每次的俯瞰和洞察大约要耗费2-3周的精力，之前的工作都是以季度或半年的固定周期进行。目前，我们正在搭建满意度实时监测系统，对关键接触点上的用户满意度、感受、倾向进行实时并自动地收集、分析、量化、可视化展现，以实现更实时、更自动化的体验监测。

最后，分享一句自己非常认同的话：

不停地创新方法，才能不停地创新产品。

We can’t innovate our product if we don’t innovate how we build it.

—— Alex Schleifer（ Airbnb设计副总裁）

作者：王丹，宋杰

本文来源于人人都是产品经理合作媒体@58用户体验设计中心（微信公众号@58UXD），作者@王丹，宋杰

题图来自Unsplash，基于CC0协议