设计沉思录丨构建俯瞰视角,用户体验管理全局观

玩新媒体,引流、转化、留存3大难题如何破?通过6周系统学习,这些问题都能解决。了解一下>>

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

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

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

用户体验设计 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协议

给作者打赏,鼓励TA抓紧创作!
评论
欢迎留言讨论~!
  1. 想知道这些图是用什么软件做的!

    回复
  2. 产品系的人每天也是以差不多方式运作改进产品的,两边发现问题重叠了,算不清谁为产品贡献了,怎么办?
    发现的痛点要驱动功能大动了,跟产品的下一步思路冲突了,都觉得自己的问题最重要,怎么办?
    本质问题是,ux跟产品割裂,两波人做一样事,冲突,效率低下,管理上,怎么办?(这句是问你领导的)

    回复