2019-5-13 濤濤
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% 都不到。
在這類應用開發的周期中，前期完成了滿足大多數用戶的基礎功能，之后更多的精力會被分配在滿足少數付費用戶的需求上。產品的方向和目標都可能隨著不同的時期發生變化，帕累托原則是一個決策工具，但決策方向是需要經過我們充分思考以后得到的，切勿盲目地服從一個指標。