标签: 乔布斯

  • 为什么传统的用户调研只是在浪费时间?

    人们根本不知道自己想要什么,产品经理与其花时间做用户调研,不如为工程师撰写任务单。以下是为什么用户那些过于自信的预测毫无价值。

    史蒂夫·乔布斯讨厌用户调研是有道理的,因为他热爱“首次使用体验”。图片来源:AB Unsplash

    我从其他专业软件工程师那里听到了一个行业趋势,想在这篇文章中讨论一下。有时候,产品经理会更倾向于“与用户交谈”(用户研究),而不是花精力去识别并记录产品的功能和缺陷修复。

    我想这是因为,如你所知,写下工作项(“工单”)——事实上——本身就是工作。它既枯燥又令人厌烦,但却能帮助工程团队取得成功。然而,通过长时间的视频通话与用户“闲聊”并不“像在工作”——因为——嗯——它根本就不是。

    (平心而论,对于全职的用户研究员来说,他们通常会做一些事情,比如记录用户完成特定任务所需的时间,或者使用热力图来量化光标的位置;从我听到的小道消息来看,大多数产品经理所做的“用户研究”似乎只是结构松散的对话而已。)

    通常,当团队中没有全职、专业的用户研究员时,产品经理和/或产品设计师就会介入填补这一角色。这看似合理,直到工程师们为了等待任务而无所事事,并且还得替那些产品经理和设计师去编写任务单。

    “用户研究”听起来确实像是一项重要且与工作相关的活动,对吧?

    但用户研究不仅会占用支持工程团队的时间——这些团队普遍缺乏足够的技术人员——而且它本身其实就没有实际用处。史蒂夫·乔布斯也认同这一观点:

    “人们并不知道自己真正想要什么,直到你把它摆在他们面前。这就是为什么我从不依赖市场调研。我们的任务,是去读出那些尚未落于纸上的东西。” —— 史蒂夫·乔布斯

    这就是为什么我希望产品经理能把他们做“用户研究”的时间,用来为工程团队撰写任务单。

    产品经理的薪酬用来支付什么?

    在一个资源有限的团队中,尤其是那些没有足够软件工程师来按计划推进产品路线图的团队,总得有人来补位,把那该死的任务单给写了。

    在我们团队,写任务单是谁的活?在大多数有幸拥有产品经理的团队里,这主要是产品经理的职责。

    但许多产品经理显然把相反的理念奉为圭臬,即“工程师应该写任务单”。等等,什么?

    据在以这种方式运作的团队中有经验的人士透露,产品经理的“职责只是界定问题或机会”,而不是将其写成任务单。从我读到的相关讨论来看,产品经理们显然忙于与用户沟通及与利益相关者开会,无暇撰写任务单。

    当然,如果你有足够的软件工程师——尤其是相对于产品路线图而言存在富余工程师的情况(我从未见过,但据称在某些公司确实存在,尤其但不限于欧盟地区)——那么工程师们写出的任务单往往比产品经理的更好。

    在这种情况下,当然可以解雇产品经理,让工程师来写任务单。工程师可能讨厌写任务单,但把预算花在雇佣更多程序员和减少中层管理者上,是一种更高效的资源利用方式。

    如果真是这样,既然工程师已经在写任务单了,为什么还要留着产品经理?他们整天到底还能干什么?

    用户研究!(当然!)

    嗯,好吧,那通常是怎么进行的呢?“用户研究”通常指持续 30 到 60 分钟的非正式对话,涵盖以下主题,这些主题选自一篇关于定性用户访谈的 Hotjar 文章 :

    1. 你对这个原型的第一反应是什么?

    2. 你喜欢这个原型的哪些方面,不喜欢哪些方面?

    3. 你会如何改进这个设计?

    4. 在类似的产品中,哪些功能对你来说最重要?你喜欢这款产品的哪些方面,又不喜欢哪些方面?

    5. 这款产品是否具备你需要的功能?你还需要其他额外的功能吗?

    6. 你觉得这款产品与市场上的同类产品相比如何?

    7. 在 1 到 10 的评分范围内,您购买该产品的可能性有多大?

    8. 在 1 到 10 的评分范围内,您完成这一特定任务的难易程度如何?

    9. 在 1 到 10 的评分范围内,您向朋友或同事推荐我们的可能性有多大?您给出该评分的原因是什么?

    10. 什么能改善你的体验?

      你是否注意到,用户(无论是潜在用户还是现有用户)在自信满满地回答这些问题时,会(并非有意地)说谎?

      好吧,如果你还没意识到这一点,让我带你了解一下关于“过度自信”的研究,看看为何这些定性的用户访谈大多是在浪费时间,尤其是与产品经理撰写需求票证相比。

    过度自信是用户访谈毫无用处的原因

    别误会,我绝对是你在软件工程师中能遇到的最大的客户体验拥护者,正因如此,我的整个职业生涯都专注于 UI/UX(用户界面/用户体验)产品工程。

    但在软件开发与用户偏好中,存在太多普遍适用的真理,而用户在非正式的用户研究对话中绝不会提及它们,即使这些才是真正重要的东西:

    网站和应用应当快速且高效。
    网站和应用程序应对用户输入做出响应。
    网站和应用应当清晰且易于使用。
    网站和应用不应存在漏洞。
    网站和应用应适配所有屏幕尺寸。

    我敢肯定,用户更在意以上这5项,而不是之前那10个问题的清单。然而,这些项目并未出现在之前关于定性用户访谈的资料中。难道修复漏洞不该永远是第一要务吗?

    前一部分中我引用的那些定性用户研究问题,其实没有特别大的用处,因为人们在预测自己的生活时,往往会过于自信。

    “与用户交流”会促使用户针对某个用户界面(UI)设计和用户体验(UX)给出看似确定、实则有误的回答。

    这并不是一个好主意。

    毕竟,用户通常不是软件工程师、产品经理或产品设计师,他们怎么可能对 UI / UX 一窍不通呢?

    你认为那些仅仅因为有机会参与一对一用户调研就“受宠若惊”的用户,会详细列出你在软件产品中发现的所有漏洞吗?

    你认为用户的建议——这些建议往往在未来12个多月内都无法纳入产品路线图——真的算是“好主意”吗?

    你认为用户能够准确预测自己在面对软件产品“出色的新设计”时的未来行为吗?

    无论是从研究还是个人经验来看,都极其清楚地表明:“传统的用户调研”是有缺陷的——用户并非技术人员。

    让我们来看看基于失败公司实验(新可乐)和科学研究的证据——为什么人们会自信地做出预测,尽管这些预测通常被证明是错误的。

    “传统的消费者研究挖掘出谬误的可能性与其挖掘出真相的可能性一样大。事实上,行为科学已经证明,人类在理解自身行为动机方面是多么不擅长,并且表明大多数时候消费者要么不知道自己想要什么。”—— 亚当·克利弗 (Adam Cleaver) 于 WRAC

    这并不是什么新信息,维基百科引用2002年和2008年的研究论文作为“过度自信效应”的关键来源:

    “ 过度自信效应 是一个被充分证实的 偏见 ,指一个人对其判断的主观信心 始终可靠地高于这些判断的客观准确性 ,尤其是在信心相对较高的情况下。[1][2]”—— 维基百科

    用户会自信满满地向你撒谎,说他们想要什么,却并未意识到这一点,这一现象与达克效应有关,即每个司机都自认为“驾驶技术高于平均水平”。

    你的用户就是不愿让自己难堪——或是“浪费你的时间”——承认自己不懂。所以他们会给出看似笃定的说法,但多数时候不过是毫无价值的瞎猜。

    这就推翻了询问用户想在你的软件中看到什么功能这一做法的合理性,这或许可以解释为什么 iPhone 拥有 14.6 亿活跃用户 。

    “误区21:人们能告诉你他们想要什么”

    许多组织仍然依赖询问用户希望网站或服务做出哪些改变,却忽视了诸如“新可乐”或“艾龙椅”等历史研究失败的教训。

    “在询问用户时,你必须意识到,人们会对自己未来的行为做出自信却错误的预测,尤其是在面对一个陌生且全新的设计时。”

    当一家公司向你发出私密邀请,向你展示他们软件产品“令人兴奋的新设计”时,你觉得大多数人会说:“是啊,这糟透了 。别无缘无故地乱改!” 怎么可能!

    但如果你是一款软件产品的日常用户,而他们无缘无故地改变了整个用户体验,大多数人恰恰会这么说!

    “对 NI(以及计算机行业的所有其他人)来说,以下几点已经足够说明问题——请别再无缘无故地更改东西了。别再使用那些根本不起作用的开源库了。别再添加会伤害到诚实用户的反盗版保护措施。”——bergstein,在 Native Instruments(NI)论坛上写道

    这就回到了本文开头引用的那句(臭名昭著的?)史蒂夫·乔布斯的名言,此处再列一次以供参考。完整引文如下:

    “有些人说:‘给顾客他们想要的东西。’但这不是我的做法。我们的职责是在他们知道自己想要什么之前,就弄清楚他们将来会想要什么。我记得亨利·福特曾说过:‘如果我当初问顾客他们想要什么,他们会告诉我:一匹更快的马!’人们在你展示给他们看之前,往往不知道自己真正想要什么。这就是我从不依赖市场调研的原因。我们的任务,是读懂那些尚未写在纸面上的东西。”—— 史蒂夫·乔布斯

    史蒂夫·乔布斯和亨利·福特都说得很对:消费者常常不知道自己想要什么——至少,在你的新产品凭借出色的用户体验在社交媒体上走红之前,他们是不清楚的。

    正因如此,产品经理们才需要回归到写工单的本职!软件开发的目标,应当是打造高性能、无故障的体验,而不是因为“与用户的快速交流”而每隔6到12个月就“转向”一个新的方向。

    把用户研究交给专业的用户研究人员,他们会帮助你的团队优化应用,通过缩短用户完成任务所需的时间,让用户获得更佳的体验。

    哦,还有,请优先修复漏洞。对于你的品牌来说,没有什么比发布带有漏洞的软件,然后在数月甚至数年内都不修复这些漏洞更糟糕的了。显然,修复漏洞永远是第一要务。

    总结:史蒂夫·乔布斯与亨利·福特是对的

    最后,我们以一个假设的例子来总结:一家视频游戏公司有一支人手不足、资金有限的软件工程团队,该团队目前只有一款 PC 应用,但希望同时在 Xbox、PlayStation 和 Switch 平台上发布产品。

    在这种情况下,用户属于玩家群体,因此可以合理推测他们家中至少有一台游戏主机,更不用说他们还拥有手机,并且不会介意游玩该游戏的手机版本。

    如果与用户交流,他们很可能会表示希望获得主机移植版,并声称自己使用主机版的频率将超过现有的 PC 版——尤其是在你提出诱导性问题时:“相比现有的 PC 游戏,您会更频繁地使用主机移植版吗?”

    但在这个假设案例中,即使你真正为他们提供了所期待的主机版本,最终可能只会观察到极少数用户从 PC 端迁移至主机端。

    为什么?

    你的用户已经在使用 PC 版游戏了!他们熟悉它、信任它,并且更希望你在 PC 端修复漏洞,而不是转向主机平台。这完全符合用户的实际行为模式,却恰恰与大多数人在自由式用户研究“快速问答”中的回答相反。毕竟,你的主机移植版本是需要花钱购买的,对吧?

    所以,没错,移植版听起来是个好主意, 但你的用户和其他人一样,非常不善于准确预测自己未来的行为!

    正如内特·希尔弗在其著作 《信号与噪声》 的概要中所解释的那样:“无论是专家还是普通人,都会把更自信的预测误认为是更准确的预测。但过度自信往往是失败的原因。”

    由于你的产品经理、产品设计师和高管团队也和其他人一样,他们会理所当然地认为,用户研究中的那些“自信的陈述”就是关于用户未来行为的“准确的陈述”。

    他们也会陷入自身的达克效应,认为自己在本职工作中“高于平均水平”,尽管没有任何证据必然支持这一结论。

    由于对自己的技能过于自信,那些非专业的用户研究员(如产品经理、产品设计师、高管等)几乎总是会表面化地接受用户的陈述,而不理解人们所说的和所做的之间存在差异。

    每个人都对自己的能力过度自信,无论是作为利益相关者评估用户研究,还是作为参与用户研究的用户预测自己未来的行为。

    如果仅以定性用户访谈作为唯一的用户研究方法,而不结合定量可用性测试(观察并计时用户在产品中完成任务的过程),那就是垃圾进,垃圾出 。

    但用户访谈“看起来像是在干活”,而且比产品经理真正应该做的事情有趣多了。产品经理的真正职责是与利益相关者和设计师协作确定产品需求,然后撰写需求文档。

    产品经理:滚回去干活,别去打扰用户了。(用户根本不知道自己说的东西有多不靠谱,你告诉他们也不会领情!)

    高管们:请另外招聘专业的用户研究人员,他们的唯一任务是缩短用户完成任务所需的时间。

    软件工程师:别去听用户访谈了,因为那些访谈内容根本一点用都没有。

    工程师不想把时间浪费在毫无价值的活动上;他们不想因为用户研究而对产品路线图进行无休止的、最后一刻(“敏捷”?)的调整;也不想撰写大部分的任务工单。

    这就是为什么我认同史蒂夫·乔布斯和亨利·福特!

    你不能相信定性的消费者研究(“你想要什么?”),唯一值得相信的是销售数据(收入)以及真实用户在完成真实任务时的量化耗时。