用户体验可视:全局观视角查看用户体验...

  • 经验类型经验/观点
  • 经验属性原创文章
  • 经验版权署名
2828 6 7 2021-01-27

     看到这个标题的时候大家会不会有一丝丝的疑惑,用户体验?这么虚的东西还可以可视化?那我们拆解一下问题:

      ·当我们收集了一大堆的用户信息,做了不少的用户调研,桌面研究,那我们应该如何将所有收集到的信息可视化呢,让团队的所有人能达成一致,快速回顾呢?

     ·大家经常会有用户旅程地图或者服务蓝图,那么还有什么可视化的图例可供使用呢?

01  为什么要将用户体验信息可视化?

      来,我们举个例子,小明某天收到一份保险缴费的费用清单,他发现这个清单是有问题的,想找相关部门核实账单,于是他给售后部门打了电话,售后部门的同事却告诉他,这个不是售后处理的范畴,需要找其他相关人处理。于是请销售代表帮他核算,销售代表表示不属于指责范畴。小明被当作皮球来回踢,就在这个时候,收款部门不知缘由发来了催款短信,小明很是生气,这保险明年不续了,XX¥%……&&&%¥*,真是令人生气的一家公司!具体流程如下:

    但是作为保险公司而言,根本都不知道客户到底遇到了什么问题,在那个环节上出现问题,面对客户的流失,不知所措,部门人员分工明确,划分界限清晰,殊不知在用户体验的全流程上有所遗漏。

      真正的问题本来源于结算清单,但潜在问题是——该组织无法跨部门解决团队问题 ,当组织面对巨大的系统问题,只有当我们从用户的视角审视体验时,问题才能得到解决。

“组织需要与其他服务对象的真实体验保持同步”

    那么问题来了,我们为什么要可视化出来呢?它可以解决什么问题呢?由上我们可以看到,当我们在提供服务时,大家想当然的将所有的可能场景做了分工,不同的部门相互合作,以为配合的天衣无缝,殊不知在用户使用的过程中,一定会出现更多的异常场景或者边缘场景,每个部门只对自己需要处理的事情负责,不是我们部门的事务,反正领导也没有分配给我们呀,更甚就是想当然在做事,按照自己的经验,技术条件等来判断处理问题。可想而知,每个人的经验,感受和语境都是不一样的。如此来说,公司就是一盘散沙,并没有相同的目标和大局观。从来没有站在用户的立场考虑问题。如果能有一张完整的体验可视化图示,从端到端的站在用户角度考虑问题,并且让团队所有成员与客户共情,完全了解用户在每个节点上的体验,和出现问题时,发生问题语境场景。是不是就可以减少大部分沟通时间,达成一致的时间,至少在对齐问题方面,是可以显著提高效率的。基于咱们不同部门对齐信息的一致性,朝着进一步提升用户体验的方向而努力,是不是更能促进良好对话的进行。

“大局观不一致会影响整个企业:团队缺乏共同目标,解决方案脱离现实,更专注技术而非体验,以及战略过于短视。”02  如何将收集到的信息可视化? 

       如何将收集到的信息可视化呢,来~可视化顾名思义,我们要开始画图了,一般我们把这个图叫作“共线图”,大家所熟悉的用户体验地图和服务蓝图就是其中的两种啦~为什么是“共线图”而不是其他的图来表达呢?那我们就要来介绍下“共线图”的概念了。“共线图”都是以某种方式来表达价值创造。表达以价值为中心的设计观点。这是用 word /excel 表达用户需求最大的差异。

“共线图(Alignment Diagram):将个人和企业之间的互动可视化形式有序的呈现出来。以某种方式来表示【价值创造】”

“共线图”具备以下特点:

  • 连接

更好地将以人为中心的设计和商业目标连接起来,将人的需求和企业需求连接起来。

  • 找关系

专注于这两者之间的关系。

  • 获益
    以价值为中心的设计始于个人和企业的良好互动,并且双方都能从互动中获益。
  • 沟通
    能够与商业领袖和相关人员,谈论设计实现商业目标中的重要性,具备全局观,跳出画面看画,不深入某一细节。

       当然,可视化的本身不能提供答案,它的作用是促进对话,图表是引人注目的产出物,可以唤起他人的兴趣和注意力,它能让其他人参与到讨论中来,指出潜在的可能,还可以作为进入创新的跳板。

      Hmm,以上这句话有么有一种似曾相识相识的感觉,什么是设计思维,设计思维本身不是一种思维方式,也不会提供答案,他只是一种方法论,通过不断的发散和收敛,帮助你和你的团队找到合适的解决方案。

03  有哪些可视化图例?

      说了这么多,来一一介绍下共线图家族吧~

  服务蓝图      那先从大家熟悉的服务蓝图开始说起吧~它适合在什么时候用呢?比如说,当我们的场景是0-1 的时候,需要梳理咱们场景里面的各个系统的组成关系,还涉及到新的系统对接,使用服务蓝图是一种很好的选择,那我们用小明的例子来理解一下:

      图中所展示的例子,有所简化整体流程,我们将用户可以接触得到的工作人员列为前台工作人员,将无法和用户直接接触的工作人员分为后端工作人员,图中略过使用的系统或者第三方支持设施,如图所示,能清楚的看到当用户发现清单存在问题时候,无法申诉,流程被中断,无法想相关部门发起对话,如果在设计服务体验之前,就能对用户的整体流程以及咱们公司对客户提供的前后台的服务进行梳理,是不是用户就不会出现体验上的断点了呢?

       当然啦,这是一个相对简单的小例子,在实际场景中,通常会复杂很多,产品的流程也往往不止一条,可能会有多条流程。


  • 下面简单总结下服务蓝图的使用场景,划重点啦
  • 全渠道服务提供:对用户来说涉及多触点体验(线上/线下/实体/虚拟)
  • 后台系统:涉及多部门,跨部门协作工作
  • 支持过程:涉及多系统对接,或者需要第三方平台提供支持
  • 适合B端系统,或者C端涉及跨部门协作服务,后台的服务如何影响影响到用户的需求

  • 服务蓝图使用目的:
  • 发现弱点。准确的帮助公司分析,谁在做什么,用户的整体行为旅程上是否存在断点或者支持薄弱的环节
  • 消除冗余。可以对内部流程/工作分配等进行简化,寻找更优解决方案
  • 达成一致。服务蓝图的可视化表示方式,能清楚明了的展现各个部门之前协作状态,帮助各部门快读达成一致,推进下一步决策。


用户旅程地图

     它适合在什么时候用呢?这种方式有点类似写游记,或者是做旅游计划,一种是梳理人们已经发生的行为,另一种是规划未来发生的。它更关注于用户行为,习惯,观点和感受,可以更好的和用户共情,所以大多数用户旅程地图可以基于用户画像(Persona)绘制,针对不同类型的用户画像,绘制所属他们的用户旅程地图,将他们的情绪变化融入地图。还是以小明的例子来解释一下:

      图中所展示的例子,有所简化整体流程。值得注意的是,所有的用户行为,不是单一用户的反馈,而是某一类型的用户的整体反馈,比如这里的对象时“小明”,一般情况下,他是这一类用户的代表。例如在购车这个场景中,资金雄厚的人和追求性价比的用户,可能是需要绘制两类不同的用户画像的,随之,其用户旅程地图也是两个。

体验地图


  •       不得不说,我刚开始看这个图的时候, 满脸的疑惑和不解,这个和用户旅程地图的差异是什么?百思不解,除了顾客的行为从线变成了多条线,hmm,这个就是差异,嗯更疑惑了,那是不是说,其实用户旅程地图更多的是讨论单一场景下,用户的线性旅程是什么样子的,而体验地图更多的则要展示全渠道体验给用户带来的差异。
           多渠道:举个例子,当你去星巴克买咖啡,从还没有进门的那一刻,你的体验地图就开始被标记了,首先,星巴克里面的各种陈设,透过橱窗你看到了各种各样的人,他们在品鉴咖啡,有的沐浴着午后的阳光和他们的小伙伴谈笑风声,有的则选择了角落盯着电脑屏幕,好像在思考着什么,门口的招牌赫然写着,下午茶时间段买一份咖啡送一块新口味蛋糕,你开心的走进了店里,瞬间,研磨咖啡豆的香气扑面而来,还有悦耳的音乐感觉心里暗想下午在这里度过,应该是一个不错的选择吧,但由于限时活动,慕名而来的小伙伴太多了,现在队伍都转了好几个弯,看着前面漫长的队伍,不禁心中有一些焦虑,这时你发现你排队的地方可以挑选星巴克的杯子、周边,于是你没有开始那么焦虑 。由于排队的人是在太多了,星巴克的服务人员,拿出二维码挨个给你们介绍,可以扫码下单,不用排队啦,你…  嗯有没有发现从你进入店门的那一刻起,你身边的一切都可以影响你的决策,都可以与你互动,周围的人/物/环境都产生了联系,在描述你的用户行为时候,再也不是单一的线性行为,不讨论比如付款购买咖啡这个单一的过程行为,而是更体系化的讨论从进店到购买,到离开店,整体体验系统的行为,你也不仅仅是和单一媒介进行互动。
          更多抽象 Persona:还是上面那个例子,当你去星巴克是为了这个限时活动,直接打包带走,其他人去可能是为了星巴克舒适的空间,可以安心的办公或者开会,还有人可能只是想去买一个星巴克的杯子,每个人来星巴克的行为,消费方式,诉求可能都是有差异的。那这张地图应该可以包容不同诉求的群体,他们在星巴克可以完成哪些事情。它会比用户旅程更加多纬度的展示,当然不排除它有可能是多个用户旅程构成的体验地图。
          我们来看一个欧洲铁路体验地图的经典例子,只要你搜用户体验地图,一定会出来这张图。可以很明显的看到,阶段/感受/想法/机会点等要素和用户旅程图是一样的,主要的差异就在于行为这栏。它体验的就是多渠道,在产品研究阶段,可以通过查阅时间表,和朋友商量,对比机票价格等多种方式去完成。在行为部分就体现了交互。

下面简单总结用户旅程/体验地图的使用场景,划重点啦

  • 转化视角:以用户旅程作为第一视角切入主题,而非将公司作为第一视角
  • 研究用户行为:⽤户旅程的核心就是用户在旅途中的行为和习惯 & 想法和感觉。 这些数据点应该基于定性研究,如实地研究,情景调查和⽇记研究等⼀⼿材料。 

适合C端的体验形产品,以用户体验为基础,无时无刻的带入用户视角思考问题


用户旅程地图使用目的:

  • 发现⽤户体验的差距,建立同理心,然后采取对应的行动去优化体验
  • 帮助设计师梳理信息,从信息中探索深入思考的路径 


来回顾一下服务蓝图和用户旅程/用户体验地图的差异

  客户旅程和体验地图,更多的是聚焦在用户行为,习惯,观点和感受。了解用户,描绘用户故事,建立同理心。

      服务蓝图会具体到提供服务的系统内部是如何运转的,技术是如何实现的。

      它们在工作中可以同时使用吗?可以的!当公司处于对用户了解较少的前期准备阶段,我们需要理解用户,理解用户体验服务的场景,理解用户的类型,以及用户在不同的体验阶段的感受。这个时候,客户旅程和体验地图就能派上用场。当我们的整个服务旅程梳理得较为完善,也完全理解我们的服务是提供给哪些用户,他们的使用过程,感受如。我们就需要进一步优化如何提供这些服务,公司需要给用提供哪些支持,各个部门,各个角色之间应该如何正常的运转。这时服务蓝图会帮助你全盘的考虑问题。理清复杂关系。一般来说,服务蓝图可以在用户旅程顺理清晰之后使用。

心智模型


上述的服务蓝图,用户旅程和体验地图想必在很多文章上都有所涉及,相比大家都比较熟悉,但我发现心智模型图就讲的比较少了,下面可以重点来看一下心智模型图。

心智模型是什么?

      根据百度百科的解释,心智模式又叫心智模型。所谓心智模式是指深植我们心中关于我们自己、别人、组织及周围世界每个层面的假设、形象和故事。并深受习惯思维、定势思维、已有知识的局限。心智模式是简化的知识结构认识表征,人们常用它来理解周围世界以及与周围世界进行互动。
      说人话,就是当你看到一个水龙头,你就会假设这个水龙头是怎么使用的。为什么会出现这个假设呢,就是基于你从小到大使用过的所有水龙头的认知,你有印象,知道不同形态的水龙头是如何使用的,他早已成为你直觉的一部分。


心智模型与设计的关系?

        我们无时不刻的在和这个世界发生着交互,当我们的直觉假设和设计的物品不相符的时候,你就会发现这个设计是不符合心智模型的,不是我们不会用,而是它设计的又问题啊。还是以水龙头举例子,在上海江滩的某一公共洗手间,当我准备洗手的时候就发现,这是一根光秃秃的水龙头,一个垂直圆柱体中间穿插了另外一个横向圆柱体,就像一个大写的T,浑然天成,没有任何的提示和表识(描述这一段的时候特别后悔没有拍照),我当时第一反应就是,hmm 感应的,直接把手伸过去,咿怎么不出水啊,坏掉了吗?换一个,怎么第二个也不出水啊!我开始试图转动上面的圆柱体(它真的可以转!),但是还是不出水啊,无意之间我尝试一个把上面圆柱体“掰断”的动作。hmm没有看错,往左“掰断”是热水,往右“掰断”是冷水…看着“掰断”过去的圆柱体。冷静了三秒的我,环顾四周,发现第二位过来的用户也完全不知道这个水龙头如何使用。这样的水龙头设计就是完全不符合用户心理预期的。
      也就是说,当我们在设计一款产品或服务时,需要站在用户的角度来考虑,他们是怎么使用理解它的,这将决定了他们使用该产品或者服务的表现方式。


心智模型图是什么?

        一般来说我们的心智模型图将被分为两个部分,上半部分是问题域,下半部分是方案域。

        问题域(行为呈现域):将用户为了达成某个目标所有的行为方式,感受,需求,列举成一张张的小卡片,并将一张张小卡片归类成组。

        方案域:提出这个需求的多个解决方案,当然我们可以非常灵活的呈现这些信息,并对这些信息的优先级进行排序。

心智模型图和用户旅程/体验地图的差异是什么?     
    
      心智模型图提供了对独立于组织的人更广泛和更深入的理解。而用户体验地图更专注于这一类型的用户在特定的场景或者组织下,是如何运作的,它的重点是理解用户要处理或者完成某一项活动时,可能采取的无数路径和可能性。


如何结构化心智模型图?

心智模型可以结构化为三个层级,每个层级逐层归因:

  • 1.行为/盒子层级:直接记录用户的行为,感受,目标和情绪
  • 2.聚盒成塔:通过亲和图的方式讲相似的行为,观点,聚合起来,他需要解释是什么驱动了这些行为
  • 3.心智层级:再往下深入,为什么他们会做出这样的行为,根本动机是什么

      三种层级依次递进,按照分类来排列,没有具体的时间顺序,更多的是关注到用户的需求/行为/感受而非流程。心智模型帮助我们理解人们如何推理、感觉。反之也能更好的了解他们正在努力实现的目标即他们行动背后的意图。对用户进行划分和用户画像的建立,心智模型也能带来一定的帮助。例如下面的图示,有些人更喜欢看到更多的工作机会,而有的人对工作机会的态度更加专注,他们希望看到的信息更少一些。与此同时,我们可以将心智模型的信息进行细化和分层。

心智模型使用范围:

  • 范围广,包括个体多方面视角

心智模型图使用目的:

  • 证明你的设计:构建的设计是基于用户事实的
  • 明确方向:心智模型并不关注于某一个场景或者某一个服务,心智模型是基于用户所有的经验判断的
  • 深入了解人类行为:发现创新设计


空间地图

   

      空间地图就是体验以三维的形式标记出来,不是按照时间顺序排列,也不是按照分层顺序排列的。空间地图适合做多维度信息流梳理,多触点梳理,或者庞大的系统例如ERP,关注信息流的流动状态,知道每个阶段每个部门需要什么样子的产出物。

      从我的理解来看,是不是可以理解成构建一个更加信息化的服务蓝图,我们 X/Y 轴在讨论用户/前台/后台系统的支持过程(可以适当简化),而 Z 轴在讨论前后台,用户之间的数据支撑(突出重点)及流转的关系。

     空间地图,由于还没有在工作中使用过,不好给大家更为详尽的例证。给大家贴几个示意图,可以感受一下~

空间地图使用范围:

  • 整体的,捕捉交互的很多层面的体验元素

空间地图使用目的:

  • 获得关于不同角色和触点的现有体验的整体了解
  • 通过信息叠放,突出一个系统内的鸿沟和低效之处


  • 总结
  •       以上,介绍了 5 种共线图,每种图表类型都以不同的方式表达了以价值为中心的设计的故事。横向对比来看:

说了这么多,希望各位看官在能在设计的路上越走越远,在选用共线图的时有理有据,不再盲目

——————————————————————————————————

本文大多数观点及结论来源《用户体验可视化指南》及《Designing With Mental Model Diagrams — An Introduction》,并结合自己的经验和理解加以阐述、总结~如各位小伙伴有其他观点和想法,欢迎来评论区讨论,谢谢



参考文献:

  •   1.《用户体验可视化指南》 作者: James Kalbach
  •   2.《Service Blueprinting: Top Questions Answered》
  • https://www.nngroup.com/articles/service-blueprinting-faq/
  •   3.《Designing With Mental Model Diagrams — An Introduction》
  • https://medium.com/seek-blog/designing-with-mental-model-diagrams-an-introduction-5eadd21daf54


Powered by Froala Editor

全部评论:6

更多作品

发表评论

取消

点击右上角
分享给朋友吧

分享到

取消

每人每天仅限5票,快给你心仪的作品鼓励的一票。

投票