2019-5-13 资深UI设计者
1. 理论表述
对于许多事件，大约 80％ 的影响来自 20％ 的原因。
2. 理论背景
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、淘宝、支付宝、京东，这些产品的用户量足够多，用户类型足够广，尾巴足够长，哪怕再隐蔽的功能入口也能拥有不错的曝光度（总会有用户发现它），所以才能发挥长尾模型的作用。
所以在用户量达到 QQ、淘宝的级别之前，长尾模型看看就好，帕累托依然是主要的指导原则。
注意点1：不得不做的需求
虽然我们要将精力放在重要的事情上，但有些功能和标识即使对于用户意义不大，和产品的增长也没有实际联系，但我们也依旧需要花费大量精力投入。最常见的就属于法律规定和平台规则相关的需求了。
比如 18 年的大事件，欧盟推行《一般数据保护条例》俗称「GDPR」，所有国际版的应用都需要针对这个条例对注册流程做出大改，比如这篇文章介绍的：《GDPR合规下的 App 产品设计——启动页面和账号注册》。
注意点2：最重要的「少数人」
满足大多数用户的需求是一个必要条件，但不代表在任何情况下少数人就是可以被忽略的群体。对于工具化的应用而言，真正为应用带来收入和传播的，恰恰是占比较低的付费用户，可能连 20% 都不到。
在这类应用开发的周期中，前期完成了满足大多数用户的基础功能，之后更多的精力会被分配在满足少数付费用户的需求上。产品的方向和目标都可能随着不同的时期发生变化，帕累托原则是一个决策工具，但决策方向是需要经过我们充分思考以后得到的，切勿盲目地服从一个指标。