对于「用户研究」的常见误解

– 本文章属于 Fight for User Research 系列 –

英文原文:uxmatters.com/mt/archiv

用户研究(User Research)虽然已非常成熟,但对于用户研究的价值,以及具体如何通过用户研究方法去理解用户,挖掘用户需求,业界仍旧存在一些常见的误解和迷思。

误解 1: 用户研究总是能提供惊艳的发现。

刚接触用户研究的人,总是对于用户研究本身抱有不切实际的幻想,认为通过这个方法,就能找到未被发现的重要事实,惊艳四座。有时候为了说服客户或项目组增加用户研究环节,我们通常会不自觉地夸大其作用和效果,以至于对方产生不切实际的期待。

真相:用户研究的核心价值是提供有用的信息,其中有可能会包括一些惊艳的洞见。用户研究确实有可能会揭示一些之前没有发觉的,但又非常有价值的信息,但通常而言,其揭示的事实很可能都是一些常规的,甚至跟你之前的个人猜想和假设相符合的。项目组成员由于长期投身于业务之中,对用户有自己的理解和认知,所以要么他们会高估自己的认知,并把这些认知用于辅助自己做决定;要么他们会认为这些是常识,不具备任何价值。用户研究揭示的那些事实,则恰好是平衡这两种极端情况,让项目组成员更客观冷静地看待事实。

用户研究的目标不是去挖掘不为人知的惊人秘密;用户研究的目的,是帮助我们更好的理解和认知我们的用户:他们的目标是什么,他们使用什么样的工具,以及他们的工作环境。这些事实无所谓是惊艳的还是已知的,对于后续做设计决策都是非常重要的支撑。

误解 2:用户研究可以指导我们该如何设计。

提供设计决策的依据,跟提供直接的设计方案还是有很大区别的。而用户研究的作用是前者,不是后者。

真相:用户研究是提供有价值的用户信息,帮助产品设计师更全面的了解和认知用户,它并不能提供解决方案。解决方案需要结合用户研究提供的信息,以及其他相关信息(市场数据、行业数据、人类学数据,等等)做出综合的判断。设计方案是迭代出来的,不是用户调研出来的。

误解 3:用户研究就是随机搜集用户的常规信息。

用户研究之前,我们往往不可能知道我们会拿到什么样的信息,所有很多新手用户研究员会先入为主的认为,用户研究就是搜索用户的常规信息,看到什么就记录什么。

真相:用户研究之前,请明确你的调研目的。没有明确调研目的话,你会发现可被记录的信息实在太多了,到最后可能就是一堆信息,不知道如何下手。当然,理论上来说,提前去收集所谓的全部信息是可行的,前提是你提前定义好信息的结构,以备后续使用。但从实际情况来看,我们通常在有限的预算、有限的时间内去搜集有限的用户的信息,所以一定要提前设计好你的调研,你希望获得用户哪方面的信息。比如工作环境是什么,比如用户自己是如何解决某个难题,等等。

误解 4:用户研究就是去问用户他们想要什么。

有的人会认为,用户研究就是去问用户他们想要什么,遇到了什么问题,以及他们期待的解决方案。这种方式更像传统软件开发商做需求及市场调研的做法,他们会在这个过程中去咨询用户对新功能的意见和反馈。但用户研究不是这样的。

真相:用户研究旨在探索用户需求。用户研究过程中,我们确实可以看到用户的明确诉求,但不是通过直接提问的方式,而是在我们采访和观察中用户在真实坏境中的行为看到的,但这些结论不是目的,而是素材,最终帮助我们去推理用户的真正需求,然后我们根据用户的需求去设计产品,之后再通过可用性测试来验证我们的假设和解决方案。

用户研究强调观察法和采访(interview),而不是问答(ask),因为问答存在以下缺陷:

1)用户很难准确口述自己的行为,所以不如真实的操作来得准确和直接。

2)用户不具备提供解决方案的能力。他们非常了解自己遇到了什么困难,但他们不知道该如何解决。

3)对于潜在的需求,用户也几乎不太可能给出有效的反馈。这完全需要用户自己靠想象去揣测自己是否会遇到这个困难,以及这个新功能能否解决这个想象出来的困难。

用户研究通过自然观察法,挖掘用户的潜在需求;通过访谈,更好的了解用户的处境。两者结合后,我们再去做产品设计,以解决用户痛点,满足用户需求。

误解 5:不要听用户的,用户研究没用。

如果你认为用户研究就是问用户他们遇到了什么困难,他们想要什么的话,确实限制了产品设计的创造性。但用户研究不是,所以也自然不会限制设计师的创造力。

真相:用户研究提供生产资料,生产资料促进生产,而不是限制。用户研究不能直接得出结论,而是去搜索有用有效的信息,所以它并不妨碍创造性地提供解决方案。老话说得好,「需要是发明之母」,需求促进创新,而不是限制。

误解 6:不要听用户的,用户研究没用。

正如前面所说的,用户很难觉察自己真的的需求是什么,也很难自己想出解决办法来,所以会有人提出较为极端的言论,即:「不要听用户的」,以至于后续发展为「用户研究没用」。有一些设计师信奉自己的判断,觉得根绝自己的诉求去做设计就可以了,且常常引用乔布斯以及福特先生的名言来证身。事实上,「不要听用户的,用户研究没用」是一种误导。

真相:我们探索的是绝大多数人都受用的方法和框架,所以用户研究的价值不可忽略。与其说「不要听用户的」,还不如说「不要只听用户的」。聆听,是用户研究中很重要的一个手段,我们仔细听用户描述他们遇到的困难,他们在操作过程中的情绪变化,等等,随后深入思考背后的含义和真实诉求。拿福特的案例来说的话,我们可以先观察用户如何骑马车,以及问他们为何需要一匹更快的马,以反推出他们想要快速到达某个地方的诉求,从给发明公共交通或者私人汽车。

误解 7:用户研究耗费太多,也耽误时间。

磨刀不误砍柴工。有时候我们无法推进一个设计方案,不是因为方案本身不够好,而是大家内心对用户的需求没有达成共识。各自怀揣自己的假设去评估一个方案,当然很难达成一致,且止步不前。

真相:对用户的正确认知,是一切的基础。用户研究确实消耗资金和时间,但反反复复无意义的讨论,导致项目延期,本质也是一种高成本的消耗。消耗不可怕,关键在于投入产出比是否划算。用户研究本身不是目的,而是手段,一套成熟的方法和框架,帮助我们更好的理解和认知用户。如果项目组不愿意花时间去做所谓的用户研究,那么也需要花时间找到一个可以达到同样目的的替代方法。

误解 8:用户研究就是可用性测试。

刚开始接触用户研究的设计师,往往最先接触到的是可用性测试。就会形成用户研究=可用性测试的错误认知。

真相:用户研究包括但不限于可用性测试。也许设计师们都有这个常识,即可用性测试只是用户研究的一个部分,但并非所有人都这么理解。认为用户研究=可用性测试的,也许大有人在。所以设计师除了执行用户研究以外,对外科普用户研究也是一个重要的责任,只有当我们的合作伙伴,上级,客户真正理解了这套科学的方法,他们才能理解为什么用户研究是从项目立项就开始,一直延续到下一个迭代。

误解 9:实地研究能够 100% 还原真实的状况。

实地观察用户在实际环境中如何工作和生活,肯定会比邀请他们到实验室更真实。但实际情况来看,当用户知道自己正在被观察或记录的时候,他们的表现往往会异于平常。

真相:请用户研究员们一定记住,即便是不干涉用户为前提的实地观察,也是有别于用户的常规表现的。一定要保留这个意识,尽最大可能做好 0 存在感,并且辩证地看待一些易于常规的状况。

误解 10:用户研究嘛,做做总比不做好。

如果你无法说服项目经理实施一套完整的用户研究,那就做个简单的问卷调查也行啊,做做总比不做好,说不定会收集到有价值的信息。

真相:say no is a better choice。实施一套完美的用户研究方案,依赖天时地利人和,所有有时候会走捷径,或做阉割版。但这是一个风险很大的事情,耗费常规用户研究一半成本的调研,拿到的数据不一定就是有效数据的一半。如果你遇到了这样的情况,尽量说服负责人预留完整的用户研究方案所需的时间,如果不行,索性不作更好,不要给非专业人士留下一种,随便做做也是做的错误印象。

扫除迷思,正确认知用户研究才是王道。

让客户或项目负责人充分理解用户研究的价值,并设定合理的理性的期待,是用户体验设计师启动用户研究前必不可少的功课。意识到用户体验重要性的人,越来越多,但他们以为的用户体验,可能跟专业领域定义的用户体验有偏差。市场给了体验设计师发挥的机会,但设计师万不可自己乱了脚步,坚持科学的、专业的做法,才是长久之计。

系列文章:

产品策略可行性测试


原文:

Jim Ross, 2015, 10 User Research Myths and Misconceptions.

拓展阅读:

Isabelle Peyrichoux, 2020, 10 Best UXmatters Articles on Foundational User Research.

产品策略可行性测试

– 本文章属于 Fight for User Research 系列 –

可用性测试几乎耳熟能详,但产品策略可行性测试,可能会稍显模式。但从随着产品和设计工作结合越来越紧密的现状来看,后者显得越来越重要。那么问题来了,如何执行产品策略可行性测试呢?

答案:以可用性测试框架为基础,只需稍微改动一点点即可。

产品策略可行性测试 v.s 可用性测试

测试产品策略的可行性,跟测试设计方案的可用性,是完全不同的。产品策略可行性测试通常在项目前期,设计正是开始之前,用以探索整个产品大方向的可行性;可用性测试则是对于特定任务的,鉴定其用户体验的方式,通常在设计开始之后。

产品策略可行性测试与可用性测试在测试方式上非常接近,所以我们只消稍微改动一下,就能完成。但设计师必须非常清楚这两者的本质差异,避免在执行过程中走偏。

为什么要用快速原型去测试产品策略可行性?

  1. 一个快速原型,可以帮助用户在操作中更好的表达自己的诉求。纯文字的抽象沟通对用户而言门槛太高。
  2. 快速原型成本低,迭代快,适合前期的探索。
  3. 几乎所有人都希望设计师尽早给点东西出来,索性一举两得。

执行框架

1:1 的定性调研通常都遵守相同的框架(图1),产品策略可行性测试与可用性测试相比,存在以下 2 点特殊性:

1)访谈:你需要去设计一些能启发用户回答更高层次的问题,而不是可用性层面的。

2)任务还原准备(测试任务的设计):不做提前预设。

图1

具体执行建议如下:

设计策略依托于产品策略,产品策略是一切后续工作的基础。不管是用上述的方法,还是借助其他方法论,设计师通过科学的用户体验研究方法,提前介入产品和业务,推进项目往正确的方向挺进,都是用户体验设计价值的范畴。

系列文章:

 

 

参考资料:

Michael Hawley, 2012, uxmatters.com/mt/archiv

拓展阅读:

Isabelle Peyrichoux, 202010 Best UXmatters Articles on Foundational User Research.