6个步骤教你落地同理心地图

马化腾说过:不论是To B还是To G,最终还是To C,他们最终都是为了更好的服务C端用户;所以用户体验只会越来越受重视。想做好用户体验,同理心必不可少。

而同理心地图就是锻炼同理心的有力工具之一。

一、什么是同理心地图?

首先要说明的是,同理心地图不等于用户画像,我看有的文章将这两者等同,这是不正确的。同理心地图和用户画像都是用户研究的不同工具,应该是相辅相成的关系,目的都是为了更好地完善用户体验。

同理心地图是对用户假设的落地练习,这样你就可以与用户联系起来,从而理解他们的欲望/需求。当基于真实数据并与用户画像、用户体验地图等其他研究工具结合使用时,它可以:

  • 消除偏见,使团队在用户角色理解上保持一致
  • 发现研究中的缺陷
  • 发现用户自己都不知道的用户需求
  • 了解驱动用户行为的因素
  • 引导我们走向创新

这种抽象思维使得同理心地图可供不同的团队使用,并已被产品设计师/营销团队/销售团队等采用。

几乎任何人都可以从同理心地图练习中受益,因为它不需要具体的人口统计学或心理学数据辅助。

你甚至可以一个人进行此练习,但是,以小组或者团队的形式进行,将自己的思考与他人的理解相结合,将会更加有益。

简单的说,同理心地图将帮助你进入用户的头脑 – 无论他们是潜在客户、目标用户还是产品用户,将他们的想法、感受、所看、所说、所做、所听,绘制成一张大图。

二、怎么绘制同理心地图?

步骤:

  • 在一张A4纸上中央绘制你的用户头像,简单就好,不用过度美化,除非你时间很充裕
  • 在四个象限中分别标记:看,听,思,感,说和做

练习同理心地图形式不是最重要的,如果是个人/少数人讨论的形式,直接在A4纸上绘制就可以(如下图)。团队的话还是根据实际需要统一研究的点,再打印出来分发给成员会比较好。

三、高效进行同理心地图练习

1. 定义用户角色

结合用户研究等相关数据+团队脑爆,确定产品的用户角色(用户画像)——它是整个产品的服务对象。

如果有多个角色,则需按角色分别绘制同理心地图。

深入了解人物角色能够让你的设计团队和项目经理能够创建更好的产品和服务。这一点和用户体验地图制作前一样。

图片来源:破茧成蝶2

定义用户角色的好处:

  • 了解用户是谁
  • 深刻理解用户/客户行为和需求
  • 避免团队成员谈论自己、他们的朋友和家人作为用户
  • 更清晰、更好的决策 – 专注于用户需求
  • 与用户产生同理心,提高洞察力

2. 确定场景

通常产品涉及到多种使用场景,可确定5个左右的使用场景,分成5个小组/分5次讨论。本文主要介绍某个用户角色在一种使用场景下的同理心地图练习流程,不同使用场景下的练习方式同理。

3. 分发材料/准备工作

将之前进行用户调研收集到的数据和材料分发给参与者,并在开始练习之前为每位参与者提供足够的时间来研究和思考。

准备工作:会议室、白板、A4纸、5种颜色不同的便签和记号笔。

4. 开始练习

从定义用户的角度思考,每个参与者应该使用便签写下与4个象限中对应的内容。然后贴在自己的A4纸地图上。这部分练习最最好控制在5-10分钟。

5. 分类和讨论

团队成员依次大声阅读自己每个象限的便签,由Leader/主持人进行分类,并贴到大白板的地图上。然后对白板上每个象限的内容,开始讨论 – 有哪些不适合的点?在所有象限中重复了哪些内容(去同存异)?一个象限中只存在哪些内容?我们的理解存在哪些差距?

下面是云产品设计师为位于德克萨斯州奥斯汀的IBM设计总部的APP开发人员制作的“同理心地图”:

来源: IBM 摄影: Sarah Lim

6. 痛点、收获

随着讨论进行到尾声,团队成员开始提取有关用户的痛点/收获,加入到地图中,并继续对便签进行分组和对齐。最后给5分钟的总结分享。

最后,别忘了总结你们的发现并保存好同理心地图,以便于后期的项目相关成员查看。最好梳理下整个过程以及最后的收获。如下是来自Dave Gray的同理心地图模版,你可以按照此模版进行整理输出可视化文档。

原创: Dave Gray 汉化: 宛苏

四、总结

同理心地图解释了用户行为、选择、决定之后的深层动机,让我们可以找到他的真实需求,因为有些动机很难被感知或者用户不便于直接表达,更难被洞察。而它可以帮助我们在每个不同的场景下与用户换位思考、打开思路、提高洞察力。

参考文献

  1. How to Use Persona Empathy Mapping –作者:Nikki Knox
  2. Empathy Mapping: The First Step in Design Thinking –作者:Sarah Gibbons
  3. Empathy Mapping: A Gateway To User-Centered Insights –作者:Jared Wick
  4. What is an Empathy Map, and why is it valuable for your business?–作者:Germán Coppola
  5. 破茧成蝶-以产品为中心的设计革命 –作者:刘津、孙睿

福利:推荐一个制作同理心地图、用户体验地图、用户故事地图、商业模式画布等可视化文档的在线网站,个人使用是免费的。可以导出图片和PDF等。网址:https://realtimeboard.com

作者:宛苏,微信:wansuer,公众号:宛苏

本文由 @宛苏 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

结果导向设计方法论——学会定义产品最终体验

从互联网时代开始,产品设计场景化的思路被提出来,即要综合考虑三方面的因素时间、地点、人物。

但是对日需完善的体验设计来说,简单的场景化思路很多时候会让场景之间的切换缺乏流畅的连接,使得单个场景相对独立、薄弱。此时需要提出一种更加完善的设计思路,从目标与结果出发,先定义产品的最终体验,再去思考达到该体验会涉及到的功能点/机会点,拓展功能反推每个场景,相互关联组成闭环体验。

继续阅读

设计沉思录|改善产品的利器之用户体验地图

概述 

用户体验地图,是用于定位和描述一个完整服务过程中的每个阶段的产品或服务的体验情况。从用户角度,用户体验地图就是记录用户在整个使用流程中的行为和情感,比如:用户做了什么?感觉怎么样?以此来发现用户在整个使用过程中的问题点和满意点,并从中提炼出产品或服务中的改进点和机会。

主要以画图的方式产出。如图1体验地图的价值在于信息整理与可视化,提供一个整体视角,方便观察产品的优势与缺陷,然而它无法代替其他调研方式获取信息的作用。

继续阅读

如何做好引导体系,提升用户体验?

引导系统是导航的重要组成部分之一,高效易用的原则是工具性/企业型产品的核心竞争力和现阶段不可忽视的商业准则。如何做好引导体系,也是用户体验的要点之一。

对于注重效率的工作场景下,高效便捷就是产品易用性的最好体现,我们需要在产品中设计优秀的导引能力帮助用户更好的提前决策,更好的理解操作过程和结果。

导引体系的由来与构成

每一个购物中心都有自己的『导视系统』,导视系统再关键的时候指引用户下一步该怎么走,防止用户在复杂的楼层中反复需找商店,浪费时间或者干脆找不到。

而相对于线下的实体商场,我们应该联想到,每一款线上的产品,也都需要有自己的『引导体系』来保证友好体验,其中:

  • 『新手向导』主要是针对小白用户的功能层、内容层的初步介绍;
  • 『业务操作导引』主要是针对复杂业务操作的引导,降低使用难度,疏通任务流;
  • 『异常情况导引』是针对异常操作的容错机制,这一步往往需要用反常规的方式思考用户习惯;
  • 『复杂信息说明/提示』是对低频/专业元素的穿透解释;
  • 『帮助导引』或者叫问答机器人,就是针对用户的问题库;
  • ……

其中『业务操作导引』是产品日常使用中涉及到最高频的模块,接下来一起看看业务操作导引有哪些具体类别。

产品中的业务操作导引

1. 步骤型导引

将复杂的任务分解成有序的任务操作流,每个简化后的任务都可以快速完成,以帮助用户顺利完成整体任务。

很多时候一步式的页面信息交互就可以了,那为什么还需要分步式的导引设计呢?

理由很简单,就是综合考虑用户的易用性和情感化因素,过多的信息难以让用户聚焦,同时产生抵触情绪,同时在校验上也承载了极大的分险,因为数据越多,修改校验后的错误信息的难度就越大。

面对这种交互信息繁多的情况,分步分解任务后,用户只需要按着机器预置好的一系列步奏,每完成一步对于用户情绪上会有成就感加成,同时聚焦每一页关键任务,分步校验,避免用户挫败感,高效完成表单的填写。

在上图中,金蝶云苍穹产品里的出差类应用,原来的长单据填写被拆解成三步填写,降低决策成本与用户风险,用户只需要关注当前步奏的结果。该方法同时适用于PC端、移动端等各终端。

对于移动端而言,需要时刻注意在录入表单的场景中,键盘弹起后剩余的界面空间,此时保证信息出现在界面上方,也是易用性的细节保证。

把产品设计得简单直观,让用户按部就班地顺利通过,是提升转化率的关键。其中很多细节点的挫败感都会让用户放弃操作。另外需要时刻切记,当在使用者已经学会使用以后,如果程序还让带领用户一步一步执行,只会让用户感到很厌烦。

2. 内容驱动型导引

内容型导引可以通过标签、超链接、人员头像等维度形成链接入口,在不影响主流程的情况下,对其中的节点进行相关内容的导引和连接,增加用户对于主场景目标的了解程度和决策能力,满足用户心理上的『可控感』

在Google Play礼品卡的购买界面,下方的特性介绍卡片内置了相关内容导引超链接,将用户短暂引导去Google Play音乐模块,尽情体验后返回礼品卡购买页面,增加购买欲望。

在内容导引的设计中,可以针对相关链接的内容制定一个小场景,营造『小场景沉浸式体验』,在游戏中经常使用该导引设计,不仅需要保证无缝无干扰的连接过去,也要保证沉浸体验和顺利返回。

3. 任务驱动型导引

任务驱动型导引主要表现在用户需要完成相应任务操作才能继续往下的场景,设计原则体现在正确易懂的文字说明和直接有效导引方向,同时需要减少不必要的操作次数,达到最快解决问题的体验目标。

「饿了么」「美团」中,当用户未填写收货地址时提交订单,系统做出提示反馈,笔者认为此时应该直接导引(跳转)至收货地址新增/维护界面,节省操作成本。

而在「盒马鲜生」中,这个导引细节处理的相对合理连贯,更加符合用户的操作流

对于新手用户而言,使用产品本身就是在学习的过程,其中的小磕碰可能都会导致不少时间端的浪费,而产品如果做到适时自动导引去相应的任务操作,就是在极大提高操作效率。

4. 前置导引

对于一个人而言,主动展示自己、善于表达自己,一定会在社交场或者足够的欢迎,相同的道理,一个产品如果可以主动的展示和表达,必定会让用户觉得是个友好的人机交互。

前置导引主要讲的是一个场景下初次人机交互时,产品自动展示相关内容的预估展示,例如”需完成”操作或者”警示”信息,从而让用户提前了解预期,保证操作风险。

在金蝶云苍穹资金模块场景中,当初次进入账户信息界面时,系统自动校验任务项,前置导引,让用户快速处理,避免用户手动处理任务后再进行判断和导引,优化体验与明确目标。

此外一些常见的场景如:注意事项、转账须知等都是前置导引的最简化体现。在支付宝中的转账场景,系统预判到”收款方”长时间未登录支付宝,前置提醒,告知用户风险项,帮助用户做决策。

5. 反向导引

《用户体验五要素》 将产品分为5层,其中在结构层中所讲的就是页面之间的流转关系,即『页面流』,整个产品的体验贯穿与页面流中,所以,页面流的合理设计是影响用户体验的重要因素之一。

而在谷歌的Materia design中,页面流下定义了前进导航、横向导航、反向导航;前两者说的是递进式的钻取与水平层级的跳转,而反向导航可以是时间(操作路径)上或者结构上的回退导引,注重反向导引才能为用户提供更为完整的页面操控跳转能力。

在PC端,人人都是产品经理的文章阅读场景下,右下角会有「返回顶部」的操作,这样的设计就是保证用户在操作路径上的回退导引,快速返回,高效便捷。

同样对于PC端的电商类产品中的面包屑的设计,同时承载了层级结构和操作路径上的回退任务,,灵活结合,保证在电商类复杂层级、多部操作下的不迷失。

而单纯的层级结构上的反向导引较常出现在移动端设计中。主要是用户在一系列操作之后,由于种种原因,可能是已经完成操作或是需要放弃操作流,而决定退出/回退,这个时候需要在界面上有相应的反向引导:「取消」、「撤销」、「返回」等。

此类操作在移动端需要时刻注意,因为移动端页面空间匮乏,弱导航设计情况下的反向导引变得无比重要。

总结

产品中的信息由页面承载,而页面中的信息流转由导引承载,页面流的合理组织、复杂任务的操作分解、导航模式的巧妙运用、内容元素的灵活钻取等都是业务设计中的向导设计体现。

避免用户没路走和走弯路,是导引设计的核心所在。

本文由 @小伟同学 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

怎样用数据分析方法应用KANO模型?

本文从数据分析的角度,重新解读如何应用kano模型。

一、 kano模型简介

KANO 模型是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的工具,以分析用户需求对用户满意度的影响为基础,体现了产品性能和用户满意度之间的非线性关系。KANO模型将需求分为五种类型,下图展示了不同类型的需求对用户满意度的影响。

图中的横坐标代表一个需求的实现程度高低,越往右越高。纵坐标代表用户的满意度,越往上越高。

这里的满意度从低到高就是从不满意一直到满意,在中间是没有不满意和没有满意的中间状态,也就是用户觉得理所当然的状态。

图上标出了五种不同类型的需求实现带来的用户满意度变化,分别是必备型需求、期望型需求、魅力型需求、无差异需求和反向需求

这五类需求,简单地说就是:必备型需求关心能不能用,期望型需求关心好不好用,魅力型需求关心是否惊艳,无差别需求用户根本不关心,反向需求关心的是这功能什么时候撤掉

二、 如何确定一个需求属于哪种类型?

KANO模型的应用目前最常见的是问卷调查法。

通过问卷分别询问用户,如果提供某功能时用户的感受,以及不提供某功能时用户的感受。用户答案和功能的分类对应如下表。

根据最终用户的反馈比例,选出分数最高的一类,确定其需求类型。这里面的计算方法比较复杂,不是本文的重点,有兴趣的同学自己百度。

通过问卷调查的方式进行需求分析有一个很大的缺点,问卷类型的数据容易出现幸存者偏差”的情况,即反馈的用户本身就有较强的反馈意愿,无法体现全体用户的真实情况。

不光如此,用户在回答问卷的过程中,得到的结果也并非可靠

说个案例:在过去,电视台统计收视率是通过日记调查法。所谓日记调查法,简单地说就是在被抽中的样本中留一本日记,可以是一张纸,卡片或者小册子。请样本家庭中的每一户成员及时填写一周自己收看电视的情况,内容包括观众姓名,收看的频道,收看的时间等等。然后每周反馈给调查人员。

随着科技的发展,机顶盒大规模地应用,调查人员可以直接通过机顶盒的数据获取用户收看电视的情况。调查人员发现,那些黄金时段的节目、知名度较高的节目,日记法的数据相比更精准的机顶盒的数据要高得多

出现这种情况的原因是因为人们在回忆自己看过的电视节目时,往往会放大那些名气更大的节目的收看时间。因此问卷法得到的信息往往是不准确的,而真实的用户行为数据却不会说谎

所以用数据来反应用户的行为将会更为准确,我们完全可以尝试通过用户行为数据进行kano模型的分析。

三、 利用数据应用KANO模型

由于大部分产品提升用户产品的满意度的目的主要是为了提升用户的粘性,表现在数据上就是产品的留存率提高。如果一个功能用户感到更加满意,那么这款功能的留存率必然会上升,或者当天的人均点次数上升。总之,用户会更有意愿使用该产品

那么根据页面的数据信息,我们可以大概推测出该功能目前所处的满意度水平,从而确定后续调整的优先顺序。这种方式相比问卷法最大的优势是信息的来源真实地反映了用户的实际反映,而不是被用户的情感因素加工过的二手信息。

不过通过数据的方式进行KANO模型的思考也有不足之处,即数据只能分析当前存在的功能用户是不是爱用,而不能发现用户目前并不存在的需求

如果该产品连基本的必备型需求都没有满足,那么在产品页面上没有用户的需求点,数据也就无法找出用户究竟需要什么样的需求。当然,我们可以通过其他功能的使用数据去发现用户的需求,不过这种情况下需要用产品思维去揣摩用户心理,有一定猜测的成分,数据不是决定因素。

另外数据也很难预测出魅力型需求

还是以iPhone为例,如果当时的诺基亚有用户的数据分析,那么数据必然可以得出用户有更大屏幕,更便捷交互的需求。但是这种方向如果没有配合上产品经理的创意,最终诞生的可能也只是更大屏的带触控笔的塞班机而已,这依然在用户的预期范围之内,最多只能算期望型需求

要想成为魅力型需求,需要数据提供方向 + 产品提供创意。在用户意想不到的方向解决用户需求才能成为魅力型需求。

这样的表述有些理论,我们看几个例子。我们首先看一下现状分析的情况。

例子一:某产品或功能的留存率非常低(多少算低,每个产品有不一样的标准),那么这个功能很可能处在下图中的蓝色框线位置。

此时用户的状态是不满意,结合kano模型进行分析,必备型需求只要基本满足即可以大幅提升满意度,那么很有可能是该产品的必备型需求的方向是错误的,用户根本没有这样的需求。

在找到用户的必备型需求之前,不管是调整当前页面的排版,还是增加相同类型的信息等都无法从本质上提升用户的满意度。因此这时页面改版最优先的方向是找到用户的真实需求。只有找到了用户的真实需求,那么改动带来的效益就是指数型增长的。

面对这样的产品状况,数据分析是很难帮助产品经理找到用户的真实需求的方向的。因为前面提到过数据分析的优势在于找到当前页面上用户感兴趣的功能,当前页面如果没有满足用户的需求,数据也无法告诉我们用户到底要什么。这时候就需要复盘产品经理当时上线该产品时的用户需求分析,找到问题所在。

再比如:

例子2:某产品或功能的留存率较好,那么这个功能很可能处在下图的蓝色框线位置。

在这个位置上,用户的必备需求基本得到了满足,再增加必备型需求的意义不大,我们需要找到期望型需求。

我前面提到过,期望型需求是必备型需求的升级版,那么找到用户最感兴趣的必备型需求,然后给出优化的方向就是该必备型需求的升级方向。

这个区域可以说是数据分析的舒适区,这类产品的数据不仅可以反映出大部分的问题,并且还能给出进一步的方向。

当留存率继续向上升时,产品已经相当成熟,用户达到了“满意”的状态,接下去可以开始尝试一些魅力型需求,这类需求无法从数据中得出,只能通过产品经理的创意进行试验,上线后再进行数据验证。

可以看出,KANO方法告诉我们数据分析在产品分析中的适用范围,在产品未找到用户的必备需求之前,数据分析是不太容易帮助产品提升满意度的。只有在产品找到用户明确的需求后,数据才能协助产品对产品进行优化。而在产品已经非常成熟时,数据也是很难找到突破口的。

数据最佳的发挥空间是把产品从四五十分提高到八九十分。太高或太低分数的产品,更多地需要创造性的产品思维。

 

本文由 @Jason 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自 Pexels ,基于 CC0 协议