我们每日埋首于网站改版、功能迭代的繁忙中，却鲜有时间反思手头设计工作对业务整体价值的贡献。我们能否衡量每一次设计迭代对用户体验的影响呢？
实际上，设计师大可不必如游击队员般，哪里发现问题就扑向哪里，而是应该建立一套良性机制，帮助整个团队从全局视角观察用户、洞察业务，让产品持续提升体验，让团队始终做出明智的决策。
近年来，我们一直在探索这种良性机制，尝试了多种方法，并逐渐形成了一些初步成型的思路，这些思路为业务带来了实际效益，也让设计师在团队中的价值日益凸显。在此，我们分享对体验管理机制的一些思考。
要解释“用户体验管理”，不妨将其与“用户体验设计”进行对比。用户体验设计关注的是“执行一次有效的用户体验设计”，获得具体问题特定解决方案；而用户体验管理则关注的是“运行一个有效的机制”，让团队拥有一套持续提升用户体验的工作模式。
体验问题池是我们曾经尝试过的一种体验管理机制。我们通过各种渠道收集用户体验问题，在问题池中记录这些问题的状态并与团队分享，然后在每个产品周期中逐个推进问题的解决。
体验问题池
这种机制看似给设计工作带来了进步：
- 我们有了清晰的任务清单，待解决和已解决问题一目了然；
- 每个体验问题都有明确的优先级，解决时有轻重缓急；
- 只要我们持续推进迭代，就能持续解决问题；
- 使用线上团队工具，方便信息的管理和共享。
一切似乎进展顺利，但实际上暗藏着危机。体验问题池给团队带来了哪些潜在风险呢？
共情不等于洞察
我们和用户一样痛，并不意味着我们对用户体验的理解更有全局性、更深刻。
关注局部问题，可能错过创新机会
越关注局部，就越容易沉迷于局部的解决方案，也意味着更可能错失颠覆性的新流程与新体验。譬如，如果我们只关注用户损坏的地图，就更有可能提出修补地图的方案，而忽视了提供手机导航这一创新机会。
紧急问题不等于紧急目标
帮助业务在激烈的市场竞争中脱颖而出，及时抓住机遇有时比解决问题更重要。我们在制定目标时，不能只局限于解决某个问题。相较于“解决地图损坏的问题”，“为用户提供更高效的到达目的地的新方式”也许是更有价值的目标。
同步信息不等于达成共识
仅仅与合作方共享一份庞大的清单，很容易陷入设计师单打独斗的困境，产品和技术团队处于被动配合的位置，难以形成共同的目标和愿景，团队合作也难以顺利开展。
工作量不等于工作效果
我们可以直观地看到自己解决了多少问题（还不一定真正解决了），但仍然无法衡量这些工作后用户体验的实际变化。
那么，更完善的体验管理机制应该是什么样的呢？目前，我们团队正在运行的体验管理机制更注重全局性的体验洞察、可量化的体验指标以及团队共识的建立。我们把这种机制称之为“全局性体验管理”。
全局性体验管理的关键流程分为 5 个重要阶段：
全局性体验管理流程图
1. 俯瞰
在俯瞰阶段，我们需要获得用户体验的全貌，通过可视化模型制作体验全景图。以下几种可视化模型适合用于俯瞰全貌：
用户体验地图／User Experience Map
用户体验地图从用户视角出发，展现用户在整个旅程中的体验情况。当业务提供的是流程型服务，比如租房、找工作时，用户体验地图就很适合用来展现体验全貌。下图是我们为 58 同城租房业务制作的租客用户体验地图。
租客用户体验地图
（2）服务蓝图／Service Blueprint
服务蓝图从系统视角出发，展现业务系统和组织是如何运作并支持用户旅程的。如果业务仍然是流程型服务，并且后台系统相对复杂，可以在用户体验地图的基础上结合服务蓝图，帮助我们建立更完整的图景。
（3）生态地图／Ecosystem Map
生态地图能够从用户视角和系统视角出发，展现用户在不同维度上的体验状态及系统支撑方式，因此适合展现非流程型服务的体验全貌。
选择适合业务类型和观察需要的可视化模型，制作体验全景图，能够有效地帮助我们构建俯瞰视角，便于下阶段的观察。需要注意的是，全景图要尽可能展现用户全程体验的情况，而不局限于用户在产品中的行为。
用户体验地图是我们他们在业务中应用最频繁的模型，具体绘制方法不再赘述，以 58 同城全职应聘者的体验地图为例，说明基本概念和读图方法，便于后面内容的理解。
体验地图包含三个基础部分：满意度曲线图、感受量化图、倾向量化图。
（4）满意度曲线图
展现用户在旅程中各个关键接触点上的满意度值，对用户的体验做量化概括。
