干货!产品微小改进带来的大收益

Posted

有时候,一个产品小小的改变往往能大幅度提升用户的体验。它可能不引人注目,但却比开发新功能更具意义。

国外开发者Joel有着丰富的产品开发经验,包括组建团队、完善战略,设计产品并编写代码等。

最近,站长之家看到了他写的一篇文章《Tiny Wins》,大致的意思是微小变化带来的大收益。

Joel在文中分享了几个案例,从网站细节的微小改进,带来用户体验的飞跃性的改进。

下面,不妨跟站长之家来看看一起来看看如何对网站等产品进行微小改进,实现惊人的改进,希望你能从中有所启发。以下是正文:

多年来,我参与了许多重要的大型项目,从制定高水平的战略和产品,到彻底检查核心流程和信息架构,再到从头开始实施设计系统。

从事这些大项目可能会令人兴奋。他们通常被公司领导和各种利益相关者认为是至关重要的。

低付出高收益的三个案例

最近,我在GitHub上发布了两个小项目,其影响超出了我的想象。而我所发布东西不是那些庞大而充实的项目。它们其实都是一些小细节问题。

首先,我们将GitHub Pull Request(下文简称PR)页面的图标设置为动态,使得浏览器标签将始终显示PR的当前构建状态。

在发布这个版本之前,用户必须定期点击回到选项卡查看他们的构建是否已经完成,以更好的继续他们的工作。不耐烦的用户会频繁点击各种PR标签。

(注:根据GitHub定义,Pull Request 是一种通知机制。你修改了他人的代码,将你的修改通知原来的作者,希望他合并你的修改,这就是 Pull Request。

Pull Request 本质上是一种软件的合作方式,是将涉及不同功能的代码,纳入主干的一种流程。这个过程中,还可以进行讨论、审核和修改代码。)

我把新的favicons放在一起,Jason负责实现动态切换。我们作出这一变化花了不到一周的时间,很快就有数百人注意到了。而这只是众多令人欣喜的反应中的一小部分。

(注:Favicon是favorites icon的缩写,亦被称为website icon(网页图标)、page icon(页面图标)或urlicon(URL图标)。Favicon是与某个网站或网页相关联的图标。)

我的下一个项目改变方向为:新PR页面上的指示器更改为指示合并方向的箭头。在发布这个之前,人们通常会混淆哪个分支应该被合并到哪个分支中。

而这个调整其实只需几分钟更改单行代码。我甚至没有设计箭头——它已经在我们的图标集里了。

这个小小的改变解决了一个看似很小的挫折,但对我们的许多用户来说却非常重要。再一次,我们看到了成百上千的热情回应和分享。

第一次改变只花了不到一周的时间,第二次只花了几分钟。这两个变化都只影响了平台的很小一部分,但两者都受到了热情、积极的反馈。

这并不是说影响力可以用获赞数来衡量,但是用户的反应告诉我们,即使微小的改变对你的用户来说也可以是非常有意义的。

多年来,我已经记不清有多少次看到下面这张不同形式的图表了:

从这个版本中可以看出,最明显的建议是,执行那些花不了多少时间却能产生巨大影响的事情。

奇怪的是,我还没有看到有多少组织真正把这条建议放在心上。我们来讨论一下这样的改变能给你带来什么。

微小变化带来的大收益

高频动作(如在GitHub上创建新的PRs)每天发生数百万次。一个给定的用户可能每周、每天甚至每小时都要经历几次相同的流程。这些流动成为他们生活的一部分。

哪怕是一点点的低效率或挫败感,它都会伴随着每一次使用。一个令人困惑的时刻多花5秒钟——当每天需要重复多次同一个操作——只会增加很多焦虑和浪费时间。

这就是为什么用户如此感激这些调整,他们明白节省未来时间的重要性。

我们可以看到类似的反应,Netflix增加了一个按钮,让用户跳过电视节目的片头介绍。随着这一改变,用户不再需要在视频中重复浏览片头等不想看的内容,而是准确直接跳到剧集中某一集正片开始的位置。

另外,在Chrome发布了一个音量图标来指示哪些选项卡发出噪音后,我们也看到更多类似的响应。随着这一变化,用户不再需要点击每个打开的标签来查找让他们不舒服的原因。

这些变化可能看起来微不足道,但它们解决了数百万用户反复经历的挫折体验。

想象一下,你的20个Chrome标签页中的一个正在自动播放整个互联网上最令人讨厌的视频。解决这个问题的方法是反复点击每个选项卡。你第一次没找到,经历了一次又一次地尝试,直到最终失败,无奈关闭了整个浏览器,这是非常恼人的。在这个过程中,用户的心理历程如下:

Chrome发布了一个音量图标后,与关闭带有杂音图标的选项卡的体验相比,用户的体验心理历程变得非常愉快:

你可以将前面提到的改进视为快捷方式。中间的步骤(比如随机点击你的许多标签,找出你痛苦的根源)是很小的事情,但它们累加起来,就足够令人崩溃。而这些改进消除了这样琐碎的烦恼。

解决你的个人烦恼是很很重要的,通常比新的、更实质性的功能更强大。想想所有这些小小的努力累积起来的影响。

这就是我所说的小小的改进。

微小的改进大大增强产品活力

开发大项目固然重要的。如果一个公司想要继续创新,像上面这样的微小迭代并不能完全解决问题。所以,我并不是建议大家开始围绕这些微小的改进展开规划路线图。所以应该以项目核心功能开发为首要目标。

但是大型项目需要协调、勤奋,最重要的是需要时间。这些事情不是一蹴而就的。在发展到一定阶段,产品开发会陷入停滞不前的阶段。对于一家初创公司(尤其是有竞争对手的公司)来说,停滞可能意味着死亡。

为了解决这个问题,公司必须创造一种氛围,并向用户证明他们在倾听意见和改进。这就需要用一些小的改进填补大项目推出前停滞状态。

许多公司试图通过构建mvp,并从那时开始迭代来达到平衡。理想情况下,每一步都为用户提供了的常规价值。但是这个过程中的每一步都可能需要两周到几个月的时间,而且不能保证每一步的产出都有内在的价值。

相比之下,我在上面列出的各种改进都是独立的。Netflix的“跳过介绍”按钮本身对用户很重要;Chrome的噪音指示器和GitHub的动态favicons也是如此。

正因为如此,这些变化被认为是新的、完整的功能。他们向用户传达倾听到的信息。这些功能会让用户对产品产生兴奋、好感和可能的忠诚度,甚至可能为有机增长做出了贡献。

mvp和迭代是强大的工具,希望快速行动的公司应该好好利用它们。但在填补空白、提高留存率和培养用户社区方面,微小变化带来的大收益(Tiny Wins)做法则更有优势。

如何让微小的改进获得回报?

知道这一点后,接下来就是定期利用微小的改进,收获回报。

现在,你的第一反应可能是打开你的用户反馈渠道,开始确定需要优先处理问题。建议不要这样做。

我注意到通过这种方式解决的问题并没有什么效果。

当我们在PR页面上添加那个箭头时,数百人欣喜若狂。其中,没有一个人指出这种改变是令人困惑。

其他人习惯了原有的流程,甚至没有注意到让自己焦虑的操作。

试想,之前有多少人认识到Netflix的“跳过介绍”按钮是可以改进的?又有多少人想过让Chrome团队解决嘈杂的标签问题?

简单的说,你不要指望用户会发现所有问题,不能能完全依赖现有的用户反馈和,而是需要自己深入挖掘。

列出改进清单,重复检查

快速列出清单并不困难,但要确保所构建的东西都是有价值的就较困难了。并不是所有改进都能产生上述影响,这也是搞清楚微小变化带来的大收益(Tiny Wins)法则的意义所在。

微小变化带来的大收益(Tiny Wins)有以下几个评判标准:

独立的。这些变化很小,范围很广,并且提供了它们自己的价值。如果改变本身不能被欣赏,那就不符合要求。

低成本。这些项目简单明了,有一定的范围,并且需要的时间很短。如果这个改变需要大量的时间和努力,那就不符合要求。

高影响力。它们影响着大多数用户经常与之互动的事物。如果改变后没有达到我们讨论过的复合效应,同样也没有满足条件。

便捷的。它们通过消除一些现在所需的繁琐操作来节省用户的时间。这是一个判断是否属于Tiny Wins非常有用的方式。至少在一开始,用户仍然会记得他们之前遇到个各种令人沮丧的体验。而成功的微小改变,会让他们发自内心地记住了变化。

那么如何合理的列出需要改进微小问题的清单呢?

你可以从安排一个能提供尽可能多观点的会议开始。包括设计师、开发人员、项目经理、支持人员在这方面都有同样有价值的见解,任何了解你的用户基础的人的看法都特别重要。

你可以问自己这些问题:

在回答这些问题时,新视角是非常有用的。

当我在GitHub上工作了几个月后,便在PR页面上添加了箭头,这么做是因为我觉得它没有意义。

和用户一样,设计师也习惯了他们的产品及其各种奇怪的设计。随着时间的推移,可能会越来越难看到有什么可以改进。所以试着让新员工参与到这个过程中来,成为你团队的一部分。培养一种氛围,鼓励你的团队在了解产品后继续质疑现状。

一旦完善初始需要改善的列后表,就可以与用户逐个验证单个项目,并根据工作/影响对它们进行优先级排序。

每个组织都是不同的,所以没有一个通用的流程。我能说的是,让产品成功的关键因素是有规律的节奏。这将创造一种公司正在倾听并迅速行动的感觉,并在用户群中培养信任。

通过让新人员参与,增加新的改进项目,重新验证它,经常调整它的优先级来保持列表的活力。

大致就是如此,虽然这样的做法不是最科学,也不是创新的,但效果非常强大。

微小变化带来的大收益(Tiny Wins)能够为你的品牌创造奇迹,它可以让你从竞争对手中脱颖而出。它可以向用户表明,你在倾听他们的意见,他们可以信任你。

想象一下,在如此微小的持续努力下,你的产品会发生什么?

来源:站长视界公众号


此文章 短链接: http://dlj.bz/sfhdjw