翻译：Tinys wins

Tiny Wins 翻译

原文地址：https://joelcalifa.com/blog/tiny-wins/

The big benefits of little changes.

多年来，我参与了许多重要的大型项目，从制定高级战略和蓝天产品，到彻底检查核心流程和 IA，再到从头开始实施设计系统。

在这些大项目上工作可能会令人振奋。他们通常被公司领导和各种利益相关者认为是至关重要的，而且也确实被值得的被赋予关注。

and it’s validating to be trusted with and attached to something so visible and impactful.

我最近在 GitHub 上发布了两件东西，其影响超出了我的想象。从社区中溢出的感激和喜爱是我以前从未见过的。但我所发布的内容并不是那些庞大而充实的项目。他们很小。

首先，我们使 GitHub Pull Request 页面 favicons 图标变成动态的，现在它将始终显示 PR 的当前构建状态。在之前，用户必须定期点击回到选项卡以确认他们的构建是否已经完成，从而继续他们的工作。不耐烦的用户会频繁点击各种 PR 标签。

我将这个改动和 Jason 的实现（动态切换开关）一起作为一个功能。这个改动仅消耗不到一周的时间，就马上得到了上百人的关注。下面只是人们表达喜悦，非常少的一部分例子。

我的下一个改动，是将 PR 页面的 ... 指示，改成了标识合并方向的箭头指示，在此之前，人们可能会困惑，究竟是哪一个分支合并到哪一个分支。

这个改动仅仅耗费了我几分钟时间。我甚至没有重新设置箭头图表 -- 它已经在我们的 icon set 中了。

这个小改动似乎只是解决了一个小小的困惑，但结果证明，这对我们的大多数用户来说都很重要。而且，我还看到了数百个用户热烈的回应和分享。

Low effort, high impact

第一个改动只用了不到一周的时间，而第二个改动嗯则仅用了几分钟。而两个改动也都只改动了平台的非常小的一部分代码，但是，两个改动都如此让人感到高兴，甚至热捧。用户都很兴奋，

这不是说优化的影响力一定取决于用户喜爱的程度（受用户的个人喜好）。但从这么多用户的反馈从一定程度上说明了，这么小的调整对用户也是很有意义的。

我说不出来，这么多年，我在多少个论坛看到了下面这张图。

但很显然的是，这张图意在建议最好尽最少的付出，产生最大的效益。但我从没有看到有任何企业真正的把这个建议放在心上，想到这建议是如此的有价值，我更加想不通了。

因此，我们来讨论一下这样的改动可以为你带来什么。

One small change can add up to a big win

有些功能（比如 创建新的 PR 在 Github）每天被用户操作上百万次。这些流程可能会发生在用户的每周，每天，甚至每小时。这些流程变成了他们的生命中的一环。

如果有轻微的低效率或障碍，它会随着每次使用而累加。一个混乱的功能可能会产生数秒的焦虑和时间的浪费，而这种焦虑在一天可能会发生多次。

我想这是这些用户在最近几周感谢我们的原因。他们懂得这这些改动会在未来节帮助他们节省很多时间。

我们能从其他的一些例子看到这种效应。比如 Netflix 在视频播放时添加的一个跳过片头的按钮，以让用户不用在频繁的调节进度条来定位到片头。

chrome 之前发布了一个版本，可以通过标签栏中 icon 可以判断哪个标签在播放声音，用户不再需要点开一个个 tab 来检查到底是哪一个 tab 在播放声音。在释放这个版本之后，我们可以看到同样的现象。

类似与这种，通过很小的改动从而解决千万人日复一日经历的挫折，的例子还有很多。

想象一下，您的 20 个 Chrome 标签中有一个正在播放整个互联网上最令人讨厌的视频。解决此问题的方法是通过反复试验单击每个选项卡。 你第一次没有找到它。这怎么可能？ 呃，也许你在点击它的时候没有注意到在播放。让我们一次又一次地尝试，直到最终失败，您关闭了整个浏览器。在可预见的未来，你可能每天都遭遇此种烦恼。

你可以将之前描述的那些微小的改善视作一条条细小的溪流, (从一大堆 tab 中找到让你痛苦的那个，或者费脑的弄明白从哪一个分支合并到哪一个分支)。但在最终将他们加起来，这些改动将会变成一条浩浩殇殇的大河。

解决一些让你觉得频繁而恼火的问题，通常比增加新功能，更加的有效，尤其是对比付出和最后得到的回报后。

这就是我说 tiny win 的意义。

Tiny Wins can strengthen your business

首先明确一点，大型项目是有必要的，因为 tiny win 并不能完全帮助企业进行持续的创新。该文章也并不是鼓励大家以 tiny wins 来作为产品的路径规划。相反，划时代的产品，应当是那些有野心的大项目创造的。

但是大型的项目往往意味着调用的资源会非常庞大，而且还要付出巨大的努力，和大量的时间。这些事情并不是一夜之间完成的，在做这些大项目的时候，你的产品可能是一直处于停滞不前的状态。而对于一家初创公司来说，这往往意味着死亡。

为了解决这个问题，公司必须创造一种积极活跃的气氛，让他们的用户知道，这个公司一直在为产品的进步而努力。而用户确确实实一系列的小刺激来弥补在两次大的冲击之间空虚（时间）。

许多公司试图通过构建 MVPs, 并从这些迭代中来维系用户。理想情况下，这确实可以让用户看到产品的价值增长，但是，这些步骤中每一个都可能需要需要开发几周甚至几个月。而且每一个 MVP 的输出，内在价值如何，用户是否买账，也是未知。而且这更像一个产品通往下一阶段的过程。

相比之下，我上面列出的各种改进都是独立的，而且是显而易见有效的。

如：Netflix 的“跳过介绍”按钮本身对用户很重要。 Chrome 的噪音指示器和 GitHub 的动态图标也是如此。

正因为如此，这些变化被认为是新鲜的、功能完整的。它们向用户传达了他们的声音（意见）公司有认真的听取。这些特征培养了用户对公司兴趣，善意和忠诚度。而且它们，甚至可能为一些有机增长做出了贡献。

MVP 和迭代是让公司行动快速的强大工具。但在填补空白、提高留存率和培养用户社区方面，Tiny Wins 的作用要大得多。

Make Tiny Wins work for you

OK! Tiny Wins 很棒，而且他们有这个可爱的名字。显然你也认可了它的强大。但下一步，你如何做到频繁的发现，创造这些 tiny wins 呢？

现在，你的第一直觉可能是打开你的反馈通道，去给问题定优先级。但我得提醒一下，

我发现我们根据该种策略解决了不少问题，但都很奇怪，这些改动基本没有被报道过。

有成千上万人因我们在 PR pages 中加入标识合并方向的箭头而高兴，但在此之外，在我们的任务书中没有一项指出这个地方可能存在问题。而大部分用户在产生困惑的时候也是先想到是自己的疏忽导致没有 get 到 PR 的意思.

而其他一些人可能已经熟悉该流程了，甚至没有察觉到他们的困惑。如果他们遇到这个问题，只会觉得这是生命中的一部分，是现状，是生活，而不会去改善。

有多少人在日复一日的移动视频进度，而不觉得这里是可以优化的？有多少人想到请求 chrome 团队将声音的指示放到 tab 中。

“If I had asked people what they wanted, they would have said faster horses.” —Henry Ford

上面这些例子，旨在告诉你，你不能完全信任你的用户能发现一些小的，但是效果很显著的优化点，换而言之，你不能完全依赖客户的反馈，而需要你自己去深挖。

Make a list, check it twice

制作一个列表不是很难，但难的是很难保证解决列表中的收获值得你的付出。并不是每一个机会都能产生上面那样的效果。

Tiny Wins 是独立的改动，涉及的范围都是比较小的，而且它仅产生属于它自己的价值。如果改动本身没有吸引力，那么该改动也就不应该在该列表中。

低付出，高回报，这些项目简单明了，作用范围广泛，而且只需要很短的时间。如果更改需要大量时间和精力，则它也不属于列表。

Tiny Wins 具有很高的影响力。 它们会影响大多数用户定期与之交互的事物。如果更改不会产生我们讨论过的复合效应，则它不属于该列表。这意味着解决系统的黑暗角落之类的事情虽然重要且值得，但并不适合此列表。

Tiny Wins 通常是捷径。它们通过消除执行操作所需的现有（身体 / 心理上的）步骤 — 来节省用户的时间。对于考量一个改动是否是 Tiny Win 改动，这是一个非常有用的办法，也是评估列表中项目的方法。

至少在最初，用户仍然会记得他们曾经不得不处理的令人沮丧的经历。 他们会发自内心地记住他们。 这就是爱的来源。

Tiny wins 通常是捷径。它们通过消除用户在心理，物理上的困惑来节省时间。从上面的例子能很容易的看清楚这一点，这也是将不属于清单中的条目筛选出来的方法。因为在最开始的时候， 用户会记得他们曾经不得不处理的令人沮丧的经历。 他们会发自内心地记住它们，并爱上它们。

因此，首先你需要召开一次会议，尽可能的把一些眼光比较深远的人召集在一起。设计师、开发人员、PM、客户成功人员和支持人员在这里都能发表有价值的见解，任何能够了解您的用户群脉搏的人尤为重要。

问问自己：

你产品被频繁被用到的特性是哪些？

这些特性中有哪些地方经常会使人感到困惑？

什么环节经常会占用人的认知负荷？

如果你的点符合以上这些特点中的某一个或者多个，这往往是一个令人激动的优化点。

这些时刻有多令人沮丧？ 解决这些小问题所节省的时间或挫折的总和是多少？ 有多少用户会受到影响？

优化会很明显吗？ 会让人产生分享的欲望吗？ 会创造快乐吗？

在回答这些问题时，未接触过该项目的新人是非常有用。当我将箭头添加到 PR 页面时，我只在 GitHub 呆了几个月。我这样做恰巧是因为它还没有在我的脑子里面形成固有映像。

设计师和用户一样，习惯了他们的产品及其各种怪癖。随着时间的推移，可能会越来越难以看到可以改进的地方。因此，请尝试在会议中引入新员工。 使其成为您团队入职培训的一部分。并营造一种氛围，鼓励您的团队在了解产品的同时继续质疑现状。

一旦你输出了 initial list, 你就可以自己验证 list 中的项目，并根据工作量/影响对它们进行优先级排序，就像其他任何事情一样。

Now do the things on the list

任何一个组织都是不同的，所以这个过程没有一个通用的做法。但是，对于一个组织，这样的活动应该是有节奏的。而这种活动会给用户创造一种感觉，公司在持续的倾听用户的心声，并解决用户的诉求。而最终它会让用户对公司的产品产生信任，依赖。

在每一个 sprint 中都包含一个 Tiny Win，或者从 list 中挑选几个来填补发布产品的间隙。确保时刻让产品保持一个鲜活的状态。

通过向新人征求意见，添加新特性，分析关联特性，以及经常性的复盘该 list , 使 list 保持鲜活状态。

在对话的早期，请务必包括您的运营方面的人才。 以正确/有趣的方式宣传这些功能也是非常重要！

就是这样，并不需要造火箭的技术，也不完全新潮，但是作用到产品中非常有效。

我相信养成 Release Tiny Wins 的习惯可以为您的品牌创造奇迹。它可以使您与竞争对手区分开来。它可以向您的用户表明您正在倾听他们的声音，并且他们可以信任您。它可以将这些相同的用户转变为推广者，提高您的 NPS，并导致有机增长。最重要的是，它会让你的产品和用户的生活变得更好。

想象一下，所有的这一切，只需要你去努力做好这些 Tiny wins。

所以 ... 你明天准备 fix 哪一个 tiny wins？