标签: 用户研究

  • 创始人用户研究速成:挖痛点、验假设、做对产品

    当创始人还处于产品上线前、探索想法的阶段时,这段时期是公司建设中最关键的阶段之一。对于有志创业者来说,在这些萌芽阶段有很多事情需要重点关注——从寻找创业点子 、 找到合适的联合创始人 ,到尽快与用户交流并推出 MVP。

    你可能已经注意到,我们最近在 The Review 上更频繁地报道这些主题。这是因为我们越来越发现,尽管初创创始人需要应对的宏观领域相当清晰,但在实践中,如何具体执行公司创立清单上的每一项任务,其细节往往要混乱得多。

    以与用户交流为例。在我们的经验中,我们发现,客户发现这一环节是创业流水线上最具挑战性的方面之一。与潜在客户交谈,以便弄清楚该做什么,听起来足够直接明了——但这个过程有太多地方可能出岔子。

    首先,找到合适的人来交流——并让他们回复邮件——绝非易事。接下来,还要面对如何设计访谈、提出有针对性的问题的挑战:既要避免常见偏见,又要能产出可执行的收获。然后,还要跨过淹没在大量反馈中的门槛。提炼洞见、梳理主题,从而提炼出更清晰的产品策略,是一道尤其棘手的障碍——尤其当相互矛盾的回答把方向引向不同路径时。

    即便已经看到了一个更成熟的产品想法,仍然会有不少潜在难题——从获取原型反馈、排查早期版本为何无法打动用户,到弄清楚为多类用户构建产品的复杂性。

    当然,虽然这对首次创业者来说可能是全新的领域,但在这个赛道里,有许多专家 and 经验丰富的创业公司运营者拥有深厚的实战经验:专注于定性研究艺术的 UX 研究员。不过,这一职能通常只会在达到一定规模后才会建立起来,即便如此, 它的角色也常常不够清晰,且被低估 。 当然,在公司从 -1 到 0 的构建阶段,创始人必须独自承担这项关键工作——通常几乎没有任何相关经验、没有培训,也不太清楚该从哪里开始 。

    我们认为 Jane Davis 是这里最适合请教的人。目前,Davis 是 Zoom 的 UX Research 和 UX Writing 总监,她曾在一系列令人印象深刻的初创公司任职,并在不同公司阶段积累了丰富的企业经验。(她此前曾在 Zapier 领导 UX Research 和 Content Design,并在 Dropbox 负责增长研究团队。)

    在这次独家采访中,Davis 以令人印象深刻的细节带我们完整走了一遍端到端的研究流程,涵盖了从明确目标、设计访谈,到选择参与者和整合洞察的方方面面。她先带我们了解了自己如何在早期探索阶段应用这套方法。接着,她分享了原型设计和迭代的最佳实践,以及创始人稍后阶段会遇到的一些障碍,包括当人们对你的产品不感兴趣,或者没有频繁使用它时该怎么办。

    尽管 Davis 涉及了一些重要概念——比如确认偏误,或陈述偏好与显露偏好——但她非常出色地深入讲解了如何开展这项工作的具体细节:从她在客户对话中总会问的那些特定必备问题,到为什么你应该为用户访谈的文字记录付费。

    对于正在与潜在客户交谈、希望培养研究者思维的新晋创始人来说,这是一门极好的速成课;但对于希望提升自身技能的产品构建者和设计师来说,这也是一份实用指南。继续往下读,深入了解如何将从研究中获得的信息转化为更好的产品决策 and 更强大的初创公司。

    Jane Davis,Zoom 的 UX 研究和 UX 写作总监。

    早期探索:在考虑创业点子时,始终聚焦问题,而不是你的解决方案

    有些创始人一开始就进行天马行空的头脑风暴, 最后却在自己并不擅长的领域创办了公司 。另一些人则带着基于多年行业专业知识 and 经验的明确判断进入市场。无论哪种情况,偏见都无处不在。

    “这里有一个很好的例子,就是去思考围绕某个单一解决方案的工作流程。我有个朋友正在打造一款金融科技工具,”戴维斯说。“他们当时关注的是工作流程中的一个非常具体的环节,并且他们觉得自己已经为这个环节想出了一个很强的解决方案。但他们一直很难获得市场反响。后来不断冒出来的问题是,人们并不是只想解决工作流程中的那一个环节——他们真正想要的是一个更端到端的解决方案,这样他们就不用总是在不同工具之间来回切换了,”她说。

    “这就是为什么早期的创意探索绝不会、绝不应当表现为向潜在客户展示某个解决方案 。即便你之后确实想做解决方案验证,我也从不会把它作为这一轮研究的一部分来做,”Davis 说。下面,她还提到了其他常见错误,以及创始人需要牢记的更多经验教训:

    错误 1:产出带有你自身解决方案偏见的短期研究。相反,要挖一口以后还能回头再用的深井。

    “我最希望早期公司专注的一件事,就是培养对问题的深刻理解,”Davis 说。“很多时候,你是从一个解决方案出发的,觉得自己有个能解决问题的好点子。这也许没错。但你是否真正识别出了一个需要解决方案的问题?在我看来,这才是更难的部分。关键在于退后一步,不要急着讨论概念,也不要把解决方案想法摆到潜在客户面前,而是要更深入地理解你真正想解决的实际问题,以及那些你想为之解决问题的人。”

    当你脑海中有了一个感觉很强的想法时,要退一步说:“让我们先不要只关注把这个想法想出来所带来的那种进展感,而是把大量时间花在真正深入理解我们想要进入的领域上。”这其实是很困难的。

    当然,更深入的理解有助于避免确认偏误。但它还有一个额外的好处。“它实际上会为你以后在同一领域的增长和创新做好铺垫。如果你真的非常深入地理解了这个问题,而且你确实有一个强有力的解决方案,那么你也能理解下一步的机会会是什么,”她说。

    “所以你可以说,‘好吧,我们会先构建这一个解决方案,但我们知道,还有另外三个与我们正在构建的解决方案相关的机会。并且如果我们最初的想法取得成功,我们还有这些内置的产品扩展,或者其他可以推进的业务线——或者如果需要的话,还有一个转型的机会,’”她说。

    这种研究就是我们所说的“挖井”——它非常强调建立一个洞察库,让你在客户发现的最初一轮访谈之后的很多年里,都能从中持续汲取信息。

    错误 #2:没有为研究设定范围。相反,应通过寻找共性来缩小受众范围。

    有了正确的思路,下一步就是实际选择你要交谈或研究的人群。“我看到很多初创公司在这方面挣扎的一点,是在为产品/市场契合广撒网和先选择市场之间的张力。当然,这两种做法各有优势,”Davis 说。

    “我非常相信二手研究,尽可能利用文献综述和市场研究,借力已经完成的工作。如果你能找到一些材料,帮助你非常宽泛地评估那些不同机会的规模,你就能发现这样的情况:‘哦,已经有很多其他初创公司在这个市场里运营了,但另一个市场的渗透率还很低,而且还没有真正满足这一需求的工具。’”

    从二手研究入手,并看看你是否能缩小潜在市场范围,会为你节省大量时间——因为理想情况下,一旦你把范围缩小,就会想与这些不同潜在市场和细分中的相当多的人进行交流。

    本质上,你不可能和每一个人交谈。“你真的必须对潜在受众进行细分。而做到这一点最有效的方式——与其只看人口统计特征——不如看他们有哪些共同点,以及他们参与了哪些相似的行为,”戴维斯说。

    为了更好地解释如何细分机会,她通过一个虚构初创公司的例子来说明:这家公司想要打造一款帮助用户研究员的软件(我们将在整篇文章中多次回到这个例子)。“公司可以先问自己几个问题:我们是否认为,帮助企业内部的职业研究员完成工作是一个机会?还是帮助自由职业者和顾问?又或者是帮助非研究人员开展研究?”戴维斯说。“这些都不是人口统计特征。你可能会在每一类中看到跨度很大、背景各异的人,但他们都符合你的目标细分标准。”

    “然后你就可以说,‘我们认为机会在这三个细分群体中最大。所以让我们先和六七位不同的人聊聊,他们不是研究员,但会做研究,了解他们今天是怎么做的。现有工工具有哪些?他们有哪些问题?这个问题是否严重到足以让我们认为,他们愿意为一个工具付费来完成这件事?学术界把这称为针对用户习惯的挖掘。’”

    真正重要的是,要从整体上理解这个问题领域。但让这些内容变得容易消化、真正有用的关键,在于你已经找出了一群有共同点的人。

    错误 #3:带着太多具体假设进场。相反,先从零开始,再逐步深入。

    “我会尽量让创始人从绝对的零开始。 先假设你对这个人的生活或他们如何工作一无所知,并尽力全面、细致地了解他们是如何把事情做成的。 这可能意味着要了解某人工作中的所有流程。或者,如果你要进入消费领域,就了解他们在工作之外是如何度过时间的。你永远不知道会挖掘出什么样的洞见。把范围放得非常宽,会让你有机会发现那些你本不会想到要问的相关问题,”戴维斯说。

    “在这个探索阶段,我更关注那种看起来有些漫无目的、间接路径的访谈,因为它们能让你有机会全面了解一个人在日常生活中试图解决的所有问题。而且这也能让参与者来主导谈话,”她说。

    如果你一上来就说:“告诉我你在这个话题上遇到的所有问题”,他们甚至可能根本不会把你想解决的那个事情当成问题——这其实很能说明一些事情。接下来,就该判断你是否真的在研究正确的方向了。

    错误 #4:没有明确列出你希望从中获得的收获。相反,随身带着这些问题,以便发现机会。

    但这并不是说早期的客户发现访谈就应该完全漫无目的。Davis 说:“我总会带着一组我希望在访谈结束后能弄清楚的事情,通常是三到五个要点。它可以具体到像‘你是否曾经在你使用的任何平台上为定制内容付过费,比如 Facebook 表情包或 Discord Nitro?’ 也可以宽泛到问‘你是否会与组织外的人共享文件?’,然后再深入了解他们是怎么做的。”

    我进行用户研究时,总是基于这个问题:我们需要根据所发现的信息做出哪些决策?

    “回到打造一款新用户研究工具的例子,我最想了解的首先是:人们现在是如何完成研究的?其中哪些部分运行得很好?哪些部分又不太好?同样,我非常喜欢把具体问题设计成围绕工作流程或项目,因为这样你可以更有针对性地深入挖掘,同时仍然保留那种讲故事式的体验,”她说。

    这里有一个可能的提问脚本:“我会先说,‘好,带我梳理一下你最近做的那个研究项目。’然后他们可能会说,‘嗯,我把它搭建起来了。我先拉了一份参与者的邮件名单。’接着我会问,‘你为此用了什么工具?跟我详细说说这个过程是怎样的。有遇到什么问题吗?接下来你做了什么?’”她说。“到最后,理想情况下我应该能完整了解他们的研究项目工作流程。所以从最开始——你是怎么获得研究项目的?想法从哪里来?你怎么知道需要启动一个项目?——一直到最后,你怎么处理研究结果?研究项目结束后,接下来会发生什么?”

    “还有一个你可能会觉得有用的小技巧:很多时候,在我们交谈时,我甚至会把那个叙事脉络草拟出来。所以到最后我会说,‘如果让你圈出这个项目里最困难的部分,请告诉我是哪一部分,以及为什么。’然后我会问,‘这个项目里哪一部分最省力?为什么?’”

    如果你还想为你的客户访谈工具箱补充更多更具体的问题,Davis 已经帮你准备好了。以下是她在访谈用户时会一再回到的常用问题:

    告诉我你昨天都做了什么。“我会让人从头到尾带我回顾他们的一天——光是深入聊这个,我们就能多聊一个小时,”Davis 说。“他们会说,‘我拿起手机看了看邮箱。’然后我们就可以继续追问——‘你回复了什么吗?这是你每天都会做的事吗?’——并深入挖掘那些不同的时刻。”

    告诉我你上一次想到‘这肯定有更好的办法’是什么时候。“我很喜欢这个问题,因为它会让人开始回想,上一次技术让他们失望,或者他们遇到某个本该被解决的问题是什么时候。另一个变体是:‘你上一次觉得某件事应该是可以做到的,但实际上却不行,是什么时候?’”

    跟我说说你上一次有过非常棒的体验是什么时候。 “关键在于,我不会说‘与技术相关’——我会直接说,‘跟我说说你上一次有过非常棒的体验是什么时候,’因为这能告诉你他们看重什么。了解人们在体验和互动中看重哪些东西很重要,因为这可以为许多设计决策提供依据,也会影响你最终把资源投入到哪里。”

    如果你能挥动魔法棒,改变你今天做这件事的一个方面,你会改什么? “当我想更深入了解人们具体的工作流程时,我非常喜欢这个‘魔法棒’问题。它能挖掘出更有针对性的机会,以及人们最在意解决的那些问题。”

    跟我说说你理想中的体验吧。你现在有什么想做却做不到的事情?“对于我所说的这类愿望型问题,我并不是想得到他们的解决方案想法,而是想了解他们真正想完成什么、最看重什么,以及当下最困难的部分是什么。如果他们提出一个具体的解决方案或功能想法,我总会问:‘你为什么会觉得自己需要一个能做到那样的工具?那个想法的什么地方会对你特别有帮助?’”

    我有一个总的原则:我不会听早期 UX 研究访谈中冒出来的任何解决方案想法——这么说出来也许有点争议。但实际上,我会转而追问他们为什么会想到那个点子。

    弄清楚该往哪里发力:在不妨碍自己的情况下整合你的发现

    在与几十个(甚至几百个)潜在用户交谈之后,你可能会以为创始人会对下一步行动有清晰的判断。但往往,拉远视角去发现其中的模式,才是用户研究中最棘手的阶段。除了要收集过多(且常常相互矛盾)的想法,并找出真正能让产品脱颖而出的功能之外,创始人往往还必须面对客户和自己各自的偏见——从隐藏的偏好,到在根本不存在模式的地方硬看出模式。继续往下读,看看 Davis 关于如何理清这团乱麻的建议。

    错误 1:追逐主题。相反,应该朝相反方向去做。

    自然的下一步,是开始在宏观层面将收获转化为产品策略,或在更微观的层面转化为新的潜在功能。“没有一种统一的综合方法能适用于每一个人,但我指导他人的方式,以及我一直推荐的方法,是先拿到文字记录,”Davis 说。

    无论你在早期创业公司里还会做什么来省钱,请一定、一定、一定要录音并转写你与用户和潜在客户的访谈,这样你之后就能回头提炼出其中的共同线索。这会让一切都容易得多。

    “当我亲自做更严谨的综合分析时,我会把那些我想从每次访谈中学到的关键要点摘出来,通常会建立一个文档,把这些要点作为标题。然后我会把转录文本里的所有信息提取出来,直接复制粘贴到这些部分里。一旦我把所有内容分好类,我就会逐部分查看,寻找共同主题,”戴维斯说。

    她回到我们虚构的用户研究初创公司。她说:“所以在招募环节,一个常见的痛点可能是要等别人去拉取邮件名单。或者在项目结束后,可能是要弄清楚把研究结果放在哪里,才能让六模块后别人还能找到它们,”她说。“而如果我没有发现任何共同点,那其实也同样很值得注意。这意味着,要么是我对市场的细分没有我以为的那么有效,所以我没找到有任何共同点的人;要么就意味着我们没有挖掘出任何重大机会,因为没有人有相同的痛点。”

    戴维斯说,这种发展尤其令人担忧,因为它违背了我们的自然倾向。“人类非常擅长发现模式,常常甚至会因此害了自己。更常见的是,我们会在不该有模式的地方找到模式。”

    以下是她为防止这种诱惑而提供的更具操作性的建议:

    把潜在主题先放到“停车场”里 。如果你已经做了三次访谈,并开始想着“我开始听到这个话题里有个主题了”,那就试着创建一份持续更新的综合记录,而不是等到最后再整理。“那是我放那些可能是主题、但我还没有验证过的东西的地方。比如,我一直在研究自定义内容以及人们如何使用自定义表情。我只做了几次访谈,但我已经听到了一些事情,我觉得这些大概会成为持续出现的主题,”Davis 说。“把它写下来会让我更清楚地意识到,它已经出现在我的脑海里了。我实际上在桌上放了一块可擦写白板,我就直接把它们写在上面,这样之后我就可以回头把它们纳入我的综合分析过程。”

    不要追逐主题。 “尽可能地,当我开始听到一些主题时,我不会去追它们。我根本不会改变我的访谈流程,”戴维斯说。“我会提出相同的问题,保持相同的结构,即使信息不断进来。对于非常早期、范围广泛的访谈,这确实是我会采用的策略。当然,在某些情况下,你会希望利用人们告诉你的内容——比如当你在进行快速迭代的评估性测试,并在各轮之间更新原型时,”戴维斯说。

    把自己往相反的方向推。 “我接下来会问自己的问题是,接下来几次访谈中,什么条件必须成立,才能让我觉得这并不是一个主题?我经常会主动去寻找与我所听到内容相矛盾的信息,以此来对它进行压力测试,”戴维斯说。

    如果我觉得我听到的一个主题是:招聘是研究项目中最困难的部分,那么我会刻意朝相反的方向走,问:“招聘最容易的部分是什么?”这样我就给了人们一个机会,让他们给出一个我并不预期的答案。

    错误 #2:忽视已显露的偏好。相反,应将其反映到你的产品中。

    在权衡潜在客户的反馈时,一个经典问题是区分事实与虚构——无论是无意还是有意,用户告诉你的内容与他们实际行为之间往往存在差距。尤其是在收集对新概念或商业想法的反馈时,这一点更为明显。(这也是经典书籍《The Mom Test》的副标题是“how to talk to customers & learn if your business is a good idea when everyone is lying to you”的原因。)

    举个有点小而且有点滑稽的例子:假设某个用户告诉你,他们很喜欢看历史纪录片,但当你翻看他们的 Netflix 观看历史时,却发现他们看的节目更像《Too Hot to Handle》这一类。

    “我从不轻视人们口头表达的偏好——即使数据表明的是完全不同的东西。我其实非常喜欢那些陈述偏好和揭示偏好出现分歧的时刻,因为这能告诉你关于一个人是谁、以及他们希望如何看待自己的一些极其有意义的信息,”Davis 说道。“在很多方面,当我们设计和打造产品时,最大的机会之一就是帮助人们感觉自己成为了那个更好的版本。即使你仍然想确保他们有能力观看《Too Hot to Handle》,但把历史纪录片作为 Netflix 首页的一部分呈现给他们,确实很有道理,因为这符合他们希望向世界展现自己的方式。”

    理解一个人希望如何看待自己实际上极其有价值。它能让你很好地判断,如何在满足他们真实偏好的同时,用你的产品把那种感觉再映射回给他们。

    构建早期产品:在始终以用户为中心的同时进行验证与原型设计

    在完成研究结论后,Davis 先会从高层面指出团队可以解决的问题。“通常我会带回这个特定工作流程中存在的重大机会。然后在我的发现里,我会开始说,‘以下是我们可能解决这些问题的一些方式,’但只要可能,我都喜欢把团队拉进会议室,然后说,‘好吧,我们听说他们希望我们解决这个具体问题。我们有哪些方式可以为他们解决这个问题?’”

    理想情况下,大家会一起推进解决方案空间的探索。研究发现也有空间为其增添细节和层次。有些东西从设计角度来看是不可能实现的,或者有些想法产品团队可能非常热衷,但从技术上我们根本做不到。

    Davis 总结了她给团队的最佳建议,帮助他们在设计、构建和发布时始终忠实于研究发现:

    错误 1:跳过评估工作。相反,应制定设计原则和一套启发式标准,以确保始终保持正确方向。

    “有一件事真的可以大大缩短迭代过程,并帮助你避免每次做出新原型时都重新开展一轮研究,那就是在一开始就花时间制定一套设计原则和一套用于评估更新的启发式标准,”戴维斯说。

    “启发式评估是一种让你自己评估产品的方法,而不是由别人来评估。它是围绕一些问题进行自我发现,比如它是否易于访问?是否清晰?是否简洁?”戴维斯说。“启发式评估还包含对该语境中‘清晰’含义的定义。例如,是否能让三年级阅读水平的人理解?为你的启发式标准设定非常具体的定义很重要,这样大家才能用同样的标准来评估。本质上,它就像一个评分细则,你可以说:‘好,这个新功能满足了这四项标准,错过了另外五项标准,所以它得了9分中的4分。’”

    如果你正在寻找灵感,Davis 已准备好推荐。“Jakob Nielsen 有一套很棒的 。Abby Covert 也有一套非常强大的用于评估产品的启发式准则,”她说。“但说到设计原则,团队应该自己制定,因为它们也反映了公司的价值观、你希望在用户面前呈现的形象,以及你想向人们做出的承诺。”

    如果你已经有了一套启发式准则和设计原则,就意味着你们已经就想要实现的一系列目标达成了共识。因此,与其对每一个迭代都进行可用性测试,不如在这些护栏的约束下,让团队自己完成评估过程。

    “一个团队可以针对工作流程中的新变化进行评估,然后说:‘这是否符合我们对清晰度的标准?这是否符合我们对可发现性的标准?这是否符合我们通过展现善意来体现设计原则的标准?’”Davis 说道。“我知道,作为一名研究者,我提出这个建议可能会让人觉得有点奇怪。很多团队担心,在这类自我评估中,自己未必能保持客观和诚实。但我至今还没遇到过一个使用启发式原则和设计原则的团队,会不把自己要求得比用户更严格。”

    以下是将其付诸实践的方法:“每个冲刺或每次发布都是一个很好的做法。无论你如何决定组织开发流程,都要把启发式评估纳入其中,让它成为一项周期性进行的工作,”Davis 说。“每当你有一次重大的版本变更时,就像进行 QA 和漏洞测试一样,问问自己,这一部分工作流程是否符合我们设定的这些标准?并且务必要作为一个团队一起过一遍,这样你们就可以现场讨论——因为显然,即使有指导和关于如何应用它的示例,仍然会有讨论的空间。”

    这些争论可能会是这样的:“这会在多大程度上影响用户成功使用产品的能力?如果我们继续推进,会发生什么?坦白说,有些时候,在是否满足启发式原则这件事上稍微放松一点也是可以的,”戴维斯说。“它是一种帮助实现特定目标的工具,也就是让用户能够成功使用你的产品,但其中也需要权衡取舍。如果你想在市场上抢占先发优势,那么你会希望尽量满足大部分启发式原则。如果你的受众非常细分,而且他们对问题被解决这件事感到格外兴奋,那么他们也许会对产品本身的一些小瑕疵更宽容一些。”

    有些时候,在启发式原则和设计原则上要求稍微不那么严格也是可以的。它们为团队提供了一个行动基线,也提供了一种定期聚在一起、按照固定节奏讨论的方式,并问自己:“我们是否达到了自己为成功所设定的标准?我们知道用户需要我们满足这些标准,才能成功使用产品?”

    错误 #2:纠结于判断某个新功能是否具有差异化。相反,应识别所有切换产品的障碍,并深入研究竞争对手。

    再来看一个(高度具体的)产品假设:把时间拨回到几年前。你想打造一款新的消息应用。你有一个想法,打算引入一种全新的能力——发送会消失的消息。你该如何判断,这项新功能是否足以让客户愿意尝试一款新产品?

    “人类对自己未来行为的预测能力实在太差了。如果你问我明天会不会去健身房,我会说会,”戴维斯笑着说。“所以与其去想到底是什么会让人去切换,我更倾向于把它拆解成所有会阻止某人切换的因素。一个人要做出这个决定,究竟需要哪些条件都顺利满足?这样一来,问题就会变成一组更小、更可管理的问题,对吧?”

    例如,价格必须让人负担得起,入门体验必须简单,导入和安装体验也必须尽量减少阻力。她说:“这就变成了一个研究项目——研究的重点不是你让别人去使用的新应用,而是他们现在是如何完成这件事的。”这时,竞品研究就派上用场了。

    “你的竞品要完成的工作是什么?我会直接和人坐下来,说:‘好,带我看看你现在用的消息应用。你以前换过消息应用吗?是什么促使你换的?’关键在于找到这种类似的行为。如果你很难找到曾经换过消息应用的人,那就说明这里的惯性有多强。”戴维斯说。

    “然后你就可以开始深挖哪些东西是缺失的,并了解你设想中的新功能,是否是人们自己会主动想到并想要的东西。所以他们可能不会想到阅后即焚消息,但你可以问一些问题,比如:‘你有没有后悔发出过某条消息?你当时怎么做的?’”

    戴维斯说,这正是概念测试可能更合适的地方。“如果我已经做了十几次概念测试,却没有一个人主动说‘哦,太棒了,我明天就想安装这个’,那我就会开始质疑自己的假设。当你向人们展示新概念时,他们通常会表现得非常热情。对某项新功能缺乏兴奋感,其实就是一个相当强烈的信号。”

    获取反馈:如何从现有用户那里更多了解哪些有效、哪些无效

    当然,研究过程并不会在一个新产品线或新功能推出后就结束。“显然,和你产品的用户交流有很多理由。公司应该以相当规律的节奏这样做,但这确实取决于具体目的,”戴维斯说。在这里,她深入探讨了当你处于诊断模式时,研究可以帮助解决的常见挑战:

    错误 1:只解决了问题的一部分。相反,要追根溯源,弄清楚为什么你的用户不是拥护者。

    一种常见情况:公司打造出一款人们喜欢,但并不热爱的产品 。

    “在那种情况下,我做的第一件事就是试着找出根本原因。如果这款产品确实相当不错地解决了人们的问题,那为什么人们不会对它感到特别兴奋?”戴维斯说。“有些产品就是没那么令人兴奋。用户希望把它设置好然后就忘掉——他们可能永远不会对它赞不绝口,但他们仍然深度依赖它。网络附加存储(Network attached storage)也许就是个不错的例子——我确实需要它,但我永远不会对这项备份服务特别着迷。所以关键在于弄清楚,这只是你所处的市场如此,还是你所构建的解决方案类型本身就有问题,”她说。

    但有时问题出在你解决问题的方式上。“我认为很多公司之所以会陷入这种处境,是因为它们只部分解决了问题。对我来说,那是最危险的地方。”

    如果我在和一家已经取得一定成功、但还没有那种非常稳固用户群的公司交谈,我会立刻去了解是不是因为他们只解决了问题的一部分——因为那正是人们会离开你的时候。

    要弄清你的产品处于什么位置,在客户访谈中可以问这些问题:

    告诉我这个产品为你做了什么。你是怎么使用它的?

    你还会把它和哪些其他工具搭配使用?

    这个产品替代了你原来用的什么?

    你最初是为什么开始使用这款产品的?“他们真正喜欢它的是什么?我们不想在不知不觉中偏离这一点。”

    如果你能挥一挥魔法棒,它还希望为你做一件什么事?

    你最希望了解这款产品的一件事是什么?“我在 Dropbox 做研究时,经常听到的一句话是:‘我知道它能做更多,但我不知道该怎么发现。’而这其实是一个极其常见的问题。很多所谓的缺乏热情,最终都源于教育不足和认知不足。”

    如果一款产品没有为某个人解决整个问题,通常并不是因为你没有做出什么东西,而是因为引导流程出了问题。你还没有传递出他们试图从中获得的全部价值。

    错误 #2:将价值与使用频率混为一谈。相反,应专注于帮助用户实现他们的目标。

    “我在增长领域工作了很长时间,产品团队经常设定的一个关键指标是用户使用产品的频率。但这取决于你想解决的问题;频繁使用实际上可能意味着他们并没有获得他们想要的价值,”戴维斯说。

    以 Zapier 为例。“它是一款自动化产品。所以可以说,如果有人每天甚至每小时都在使用 Zapier,这可能意味着他们正在创建更多的 zaps——但也可能意味着他们在设置过程中遇到了问题,没能以一种能交付他们所期望价值的方式把它配置好。所以我通常会从我们如何实际衡量并理解传递给用户的价值开始?”

    侧边栏:正如 Davis 分享的那样,这要求在产品开发流程一开始就提出一个问题: 当你增加新功能时,问题不应是“这对某些人可能有用吗?”而应问:“这如何帮助我们的用户实现他们的目标?” 很容易一味追求“价值增量”,结果直接把自己做出产品/市场契合。

    回到这个具体的频率问题:“拥有强大的分析能力在这里会是一个非常有用的切入点,因为这取决于你能获得多长时间跨度的数据。如果你的产品是两个月前才上线的,你大概无法做真正有用的基于时间的建模,但你至少可以问:人们在我们的产品里反复做的事情是什么?然后你就可以开始理解他们为什么这么做,”她说。“如果有人一天登录你的产品三次,他们这样做是因为他们真的从产品中获得了价值吗?还是说他们只是总是不小心把浏览器窗口关掉了?”

    理解用户行为背后的原因和方式,识别哪些行为真正体现了价值,哪些则可能是糟糕体验的前瞻性信号。

    当然,戴维斯在访谈中有一个她常问的、可靠的用户研究问题:

    如果没有这个产品,你会怎么做?假设这个产品从未存在过,带我了解一下你会怎么做 。“这会告诉你很多他们真正会怀念你的哪些方面,以及你在哪些领域在提供价值。”

    错误 #3:没有就哪些用户更重要做出艰难决定。相反,应列出清单并承认取舍。

    另一个经典难题是为多个用户群体构建产品,尤其是在企业领域,涉及买家、管理员和终端用户。“第一步其实是了解所有正在使用你产品的不同人。我说的‘了解’,字面意思就是先列个清单,这样当有人说‘嗯,我们的用户习惯……’时,你就可以问‘ 哪些用户?’”戴维斯说。

    她警告说,接下来这部分听起来会有点功利主义。“要弄清这些用户中哪些对你的目标最重要。 作为一家企业,总会有取舍,而最常出现取舍的地方,就是产品管理员和产品使用者之间。首先要了解不同的激励因素,并建立一种清晰的决策方式:当它们发生冲突时,就明确说我们的首要关注是这个,次要关注是那个。从长远来看,这会帮助你避免很多那种人们说‘用户’、其实却指完全不同事情的情况。”

    许多公司不会做区分,因此也就不会作出艰难的决定。这听起来很苛刻,但你必须愿意说:“我们更重视某一类用户,而不是另一类。”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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