Appearance
帕累托原则 Pareto Principle
简介说明
对于许多事件，大约 80％的影响来自 20％的原因。
要点
输入和输出往往不是均匀分布的。一个大的群体可能只包含少数几个对预期结果有意义的贡献者。将大部分精力集中在能为最多用户带来最大利益的领域。理论背景
1896 年，意大利经济学家帕累托出版了《经济政治学课程》(Cours d’economie Politique)，其中描述了他所观察到的一些现象，比如意大利 80% 的土地掌握在 20% 的人手中；比如花园里 20% 的豌豆荚产出了 80% 的豌豆。
上世纪 40 年代，美国一位管理顾问 Joseph M Juran 观察到一个在商业以及生活中普遍存在的现象：在某一过程中，80% 的影响来自于 20% 的投入。他将这一现象以帕累托为名，称为“帕累托原则”。
80/20 虽然只是一个相当不精确的数字，在很多具体情况之下，这个数字会有细微的波动，但这个数字背后所蕴含的思想或是规律却是不变的：更集中的投入将产出大于预期的结果。
投入和产出大致的曲线如下图所示： 
设计案例
将时间投入到用户常用的页面
一般来说，一个 APP 大多拥有几十上百个页面，但是这些页面并不是用户都能用到的，有时候大多数用户只会常用那么几个页面，所以将有限的时间和精力投入到这些页面将为你获得更大的收益。
尤其是在页面迭代的时候，我们没办法一次性迭代所有，包括那些细枝末节的页面，所以这时候将精力投入那些主要的页面是个明智的选择。 
案例 1：网易云音乐的 UI 迭代
最近网易云音乐迎来了大版本更新，UI 设计也几乎重新设计了一遍，但我们所看到的重设计，只局限在那些关键的页面上，次要的页面基本没改。像首页这种重之又重的页面不仅风格、排版大改，连产品逻辑都改了 (比如快速入口由四个变为五个，改变了私人 FM 的位置等)，但是等级页这种无关紧要的页面，除了头部的全局性改动其他地方一点没改。
奥卡姆剃刀的另一种诠释
那我换个角度想，如果我们的应用已经存在了这么多需要花费时间和精力的页面，现在产品经理希望增加另一项需求量小但确实存在的功能，我们应该怎么办？奥卡姆剃刀指出“如无必要，勿增实体”，这是我们对此欲增加的功能的终极评判标准。
要知道，页面中每增加一个元素，对于用户体验的影响是巨大的，这意味用户需要花费额外的时间去理解新增加的元素是什么；在所有元素中寻找特定的一项又多了一些备选；浏览页面时的视觉噪声又多了一些。
所以到底要不要增加这个功能，关键在于能否很好地控制上述的用户体验成本，以及后续的迭代成本。从帕累托原则的语境来看，小众但是确实存在的需求大概率不足以产生能够克服用户体验损失的收益，哪怕我们投入了一定的精力去做，日常依然无法给它 (或它们) 百分之二十以上的关注去修改，去完善，去迭代，所以这个功能也大概率不需要增加。
长尾模型与帕雷托原则的对抗
说起帕累托原则就不得不提到长尾模型，长尾模型的分布曲线与帕累托长得很像，但是结论却完全相反，长尾模型提醒我们无法忽略那条长长的尾巴的影响，虽然它收益低，但架不住数量多，比例高。所以我们可以看到「尾巴」所占据的面积几乎和「大头」相当。 
长尾模型原理示意
04 年长尾模型刚被提出来的时候，很多人认为长尾模型是对帕累托原则的颠覆，诸多例子都侧面佐证了长尾模型的正确性，比如 Google 目前约有一半的生意来自小网站，比如亚马逊图书的总盈利中少数畅销书占一半，绝大多数的冷门书占另一半。
听起来好像很有道理，长尾模型好似在控诉着开发者不去关注那些小众而众多的琐碎需求；然而事实真的如此吗？
长尾模型本身隐藏了两点不可或缺的前置条件，一是尾巴真的足够长 (小众需求真的有这么多)，二是这么长的尾巴能被用户发现。无论哪一点，都建立在海量的用户资源之上，所以中小型 APP 大多无能为力。能够有余力去关注长尾模型的都是用户量达到一定规模的产品，比如之前例子中所举的 Google 、亚马逊，国内的微信、QQ、淘宝、支付宝、京东，这些产品的用户量足够多，用户类型足够广，尾巴足够长，哪怕再隐蔽的功能入口也能拥有不错的曝光度，所以才能发挥长尾模型的作用；不然的话，想都别想。
所以在用户量达到一定程度之前，长尾模型看看就好，帕累托依然是主要的指导原则。
注意事项
注意点 1：不得不做的需求
虽然我们要将精力放在重要的事情上，但有些功能和标识即使对于用户意义不大，和产品的增长也没有任何实际联系，但我们也依旧需要花费大量精力投入。最常见的就属于法律规定和平台规则相关的需求了。
比如 18 年的大事件，欧盟推行《一般数据保护条例》
注：2018 年 5 月 25 日正式生效的欧盟通用数据保护条例，要求从设计系统开始就需考虑数据保护，而不能之后追加。该条例拥有治外法权。
俗称 GDPR ( 不是 CDPR！)，所有国际版的应用都需要针对这个条例对注册流程做出大改，感兴趣的同学可以看一下「GDPR 合规下的 App 产品设计——启动页面和账号注册」这篇文章。
注意点 2：最重要的 “少数人”
满足大多数用户的需求是一个必要条件，但不代表在任何情况下少数人就是可以被忽略的群体。对于一些工具应用而言，真正为应用带来收入和传播的，恰恰是占比较低的付费用户，可能连 20% 都不到。
在这类应用开发的周期中，前期完成了满足大多数用户的基础功能，之后更多的精力会被分配在满足少数付费用户的需求上。产品的方向和目标都可能随着不同的时期发生变化，帕累托原则是一个决策工具，但决策方向是需要经过我们充分思考以后得到的，切勿盲目的服从一个指标。
结论总结
- 将时间和精力投入到用户常用的页面；
- 根据地方政策和应用本身的付费用户特征，可以选择为小众需求投入时间；