分类: 需求洞察

  • 25个用户体验失败的原因

    从客户生命周期视角看用户流失

    尽管我写了很多关于病毒式营销的文章,但不可否认的是,良好的产品留存率对于产品的成功同样(且极其)重要。因此,除了讨论用户获取方面的问题,也必须对用户流失问题展开类似讨论。

    在客户生命周期视角下,你需要从用户的角度审视产品,即用户从新手开始,逐步进入高级角色所经历的一系列体验。除了研究成功案例,分析失败案例也很有启发性——你应当分析产品中可能导致用户退出的关键节点,并将其与定量和定性指标联系起来。关于客户生命周期概念的更多内容,可参阅 First Round Capital 的 Josh Kopelman 撰写的此处 。

    无论如何,这里有一个来自游戏行业的好例子:在去年的奥斯汀游戏开发者大会上,达米恩·舒伯特(他也在此处撰写一篇犀利的博客 here)就玩家为何离开大型多人在线游戏做了一场精彩的演讲。Massively 网站上有一篇非常方便的整理文章 ,总结了此次演讲,其中包含一个很棒的清单。我鼓励大家完整阅读 。显然,面向网页类产品所面临的挑战截然不同,但可以采用相同的方法。

    社交产品中的用户生命周期

    我想许多读者正在开发社交产品——对于这类产品中的任何一个,用户在生命周期中通常会经历多个模糊的阶段。这些阶段可能包括:

    • 首次体验

    • 单人使用与单用户价值

    • 偶遇好友

    • 达到社交关键规模

    • 成为网站元老

    显然,每个产品都有所不同,但上述大致思路适用于所有社交类产品。在早期阶段,初次体验的关键在于用户是否能在产品中看到价值,以及产品是否“看起来还不错”。随后,用户往往会因为没有足够多的好友来让网站发挥作用,从而退回到单人使用体验。一旦他们开始在网站上遇到其他用户并结交朋友,如果操作得当,网站就会达到临界点,变得具有黏性。最后,在部分产品中,一定比例的用户会转变为版主、管理员,或成为产品中的元老级用户。

    25个退出节点

    现在,让我们看看用户在任何一个阶段可能离开的各类原因——显然,在每一个阶段,留存率会变得越来越高,因此像“这个网站太让人上瘾了!”这类原因的影响力会逐渐减弱 🙂

    总之,以上就是这25个原因:

    首次体验

    • “我不明白这个网站是做什么的”

    • “这个网站不适合像我这样的人”

    • “颜色/设计/图标看起来很奇怪”

    • “我已经在用 X 做这件事了”

    • “我不想注册”

    单打独斗与单人用户价值

    • “我没时间参与这样的网站”

    • “我很孤独,没什么新鲜事发生”

    • “我忘了密码”

    • “我不知道怎么聊天或认识新朋友”

    • “我每隔几个月才登录这个账号看看,万一有什么新动态呢”

    遇到了一些朋友

    • “这个网站上的人都很刻薄”

    • “我不认识的人老给我发消息,什么鬼?”

    • “我想让我的朋友用这个,但他们都没留下来”

    • “我收到太多来自这个网站的邮件了”

    • “我只有3个好友,这个网站还是很无聊”

    达成社交产品的临界规模

    • “这个网站占用了太多时间”

    • “太多半生不熟的人来加我好友了”

    • “有人根据我的照片和活动记录在跟踪我!”

    • “这个‘最佳好友’功能引发了太多纠纷”

    • “无论谁做了什么,我都会收到一堆邮件轰炸”

    成为网站元老

    • “运营这个网站的人没有开发我们真正需要的 X 功能!”

    • “运营这个网站的那帮人开发了功能 Y,这会把网站毁掉!”

    • “我做了很多工作,但什么回报也没得到”

    • “我觉得很无聊,因为没什么可做的了”

    • “欺负新人挺好玩的 :)”(等等,这或许算是一种好处!)

    显然,这只是一个快速头脑风暴的列表,但关键在于,用户流失的原因往往因其生命周期阶段的不同而有很大差异。就留存而言,你能为产品做的最好的事情之一,就是对新手非常有利,但在其他方面可能会带来副作用。你需要根据产品和业务目标,在这些因素之间始终保持平衡。

    我还漏掉了其他显而易见的问题吗?欢迎随时提供评论和建议!

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

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

    史蒂夫·乔布斯讨厌用户调研是有道理的,因为他热爱“首次使用体验”。图片来源: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 端修复漏洞,而不是转向主机平台。这完全符合用户的实际行为模式,却恰恰与大多数人在自由式用户研究“快速问答”中的回答相反。毕竟,你的主机移植版本是需要花钱购买的,对吧?

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

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

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

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

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

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

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

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

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

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

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

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

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

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