白癜风能治愈吗 https://m.39.net/disease/a_5602607.html洞察=靠直觉?靠灵感?
今年7月底,我接手了一个比较复杂的任务:探索羚珑视频应用能力的体验发展方向,能够让更多人来使用羚珑这个视频功能。和很多羚珑其他项目一样,我是从整理电商场景的视频应用领域开始,基于假设找设计机会点,发散点子,找用户,做访谈....
但是当我进入到整理访谈内容的阶段,“洞察”这个老生常谈的问题终究开始困扰了我--我对照着用户调研的基本方法,归类、统计,问“为什么”,想“可能解决的方法”,思考“需求的合理性和可行性”...似乎都按部就班地做了,但是感觉还是得出的是浅层的发现,而不是什么“WOW”的洞察。
不知道大家有没有这样的经历,看别人得出洞察,框架也有,思考路径也对,但是结果就是很灵活乍现,也说不清楚怎么就出现了。感觉过程仿佛如下图所示。
我在用户调研后的一到两周的时间里,经历透视“洞察”的过程。我复盘了这两周的思考,在一系列常规的设计思维操作之外,对如何通过用户调研结果推导出“洞察”,做了一个总结。
这篇文章也只是集中分享这一步,不太会涉及到前期用户调研的准备,访谈的提问技巧,或者后期如何根据洞察进一步导出设计方案。本文只探索,如何从用用户的原始数据,一步步导出“洞察”的。后期如何从“洞察”推导出设计结论,也暂时不做探讨。
项目背景
这次的项目背景主要集中在羚珑的视频功能模块。这次是一次比较大的愿景导向的项目,注重在整体上做出更合理的设计,而不是只是针对某些用户体验细节的优化。
这一次用户调研的前期工作,我对目标用户的现状做出了假设,并且草拟了几个机会点,根据机会点鼓励用户去谈他们希望有的功能内容,有什么样的顾虑和偏好,对现有的功能体验如何,帮助团队更加了解用户的习惯和倾向,从而调整已有的假设,作出方向性的选择。
透过用户调研数据,推导“洞察”
当用户访谈结束后,我收到了很多用户数据和反馈的意见,但是这些数据和意见都错综复杂,里面的内容最终能推导出什么根本不知道,根本就是“黑盒”。
首先需要梳理用户表象,也就是搞清楚用户究竟说了什么。但用户阐述自己的情况和喜好时不一定会把背后的细节和因果都清清楚楚地说出来,所以更重要的是,透过用户所说的这个表象,看清楚黑盒子里,有哪些变量以及它们之间的因果关系。
我的具体做法如下,第一步是梳理用户的表象,也就是最大程度还原用户所说的话。
1.梳理用户的表象
面对搜集到的用户数据,我在处理过程的总结主要有三点。
1、因为我的访谈是通过qq聊天进行的,第一步是要把用户的观点逐字逐句整理成访谈文档,包括我当时采访的时候问的问题。这样可以高度还原用户对话的场景,之后方便提供用户的具体观点作为论据。
2、对于用户说的话需要进行分类整理,也需要留出空间记录自己对于用户声音的观点和看法。例如你认为用户提出的问题是否是真的问题,背后是不是有另外的原因造成的。
3、可以根据整个用户体验流程区分不同的信息(使用不同的颜色进行标记,例如下图,红色字是用户提及次数较多,并且重要程度较高的问题),用户提及次数最多的,用户说的vs你认为的,你认为重要程度、优先级的排列等等,这样方便后期可以快速制定设计方案。
2.寻找核心变量
首先是寻找核心变量。这次是通过扫描、归纳、交流三步来做的。
2.1三维度扫描
面对用户提供的意见反馈,第一步要做的就是扫描。从第一个扫描到最后一个。但是问题来了,看到用户提供的意见或者建议,应该思考些什么?这是一个思维黑盒,也是我们拿到反馈应该问自己的第一个问题。
常见的方法有以下几种:黄金思维圈、抽象阶梯、5W1H
其实不难发现,他们的共同点都是从三个方向去思考:what类澄清概念,why类追溯原因,how类解决问题。所以拿到用户的反馈,第一步就是扫描他们,并且利用这三个方向拓展出更多的信息量。
1、what轴。往上问:概括用户在讲什么问题;往下问:用户说的问题包含了哪些细节。
2、why轴。往上问:用户这样做的原因是什么;往下问:这导致了什么结果。
3、how轴。往上问:用户当前是用一种什么样的方式解决问题;往下问:对于这个问题可能有多少种解决方法,以及每个方法的步骤是什么。
举个例子,例如在这次用户访谈中,用户提到说认为找不到自己合适的视频模板:
1、what轴。往上问,用户是在讲模板没有合适的,主要指的是在品类分类下找不到自己商品的模板而不是风格筛选不到。往下问,模板数量比较少,可以挑选的不多。
2、why轴。往上问,用户为什么会觉得没有合适的视频模板呢,是因为没有看到跟自己的商品品类一致的示例模板。往下问,导致的后果就是用户流失。
3、how轴。往上问,找不到合适的模板的时候用户该怎么办呢,用户会说根据自己商品适合的风格或者颜色来寻找。往下问,用户定位自己需要的模板的大致路径会是:品类,然后是风格或颜色。如果这两个都找不到合适的,就放弃使用。
为什么这个方法是有效的呢?
之前我们可能会一掠而过某些用户提供的信息,认为没用,但其实有可能只是我们不会分析这个信息,或者说是读懂了,但是没理解这个信息。
用户在访谈的时候“随口”说出来的话,是需要被分析的。重要的不是用户表面上说了什么,更重要的其实是需要从设计的角度来分析和拆解--新的信息才有“信息量”。→交互设计师或者说是产品经理(在我们组这两个岗位合二为一了)的职责不是如实汇报用户讲了什么/做了什么,而是阐明你认为用户在说什么/做什么/怎么做的。
分析和拆解,拆解即思维,这里谈到的“三维度扫描”的方法结构,当然也有别的思维方式(欢迎大家一起交流)。what、why、how都需要跟用户了解清楚。在分析问题的时候,我们非常容易把重点集中在why。但是其实在这个分析过程,what是帮助定位需求,非常重要。但也别忘了也要询问how,了解用户在遇到问题的时候,他们是怎么解决的。他们的一些解决方案可能能给到我们对于改进产品非常大的启发。例如这次在访谈中,我发现有用户会根据模板的颜色进行筛选,因为他们想选出跟自己商品颜色比较融合的模板,这对于我们优化模板筛选器有了非常大的启发。
这些方法都能很好地帮我们拓展信息。为之后归纳问题和解决问题打好基础。
2.2归纳公因素
通过上述说的三维扫描完所有用户提及的反馈之后,就要归类的。把大量用户提出的反馈归为不同的类别。此时,我们需要问自己的问题就是,如何归类用户访谈中得到的反馈呢?
我自己的归类方式是“用户怎么说怎么做”+“我怎么理解”归类到共同点。
我的两种归纳思路--“自上而下”和“自下而上”。
1、“自上而下”的归纳:也就是从用研目标和问题出发,用用户给我们的反馈来回答我们提出的问题。这一些的回复非常有针对性,我们也相对容易归纳得出结论。
2、“自下而上”的归纳:也即不带任何问题,撇去假设,直接用原始数据开始看。有的时候直接从原始数据看,会有意外的收获。一些一开始没有被