在系統設計中，賬号的用戶權限設計是最令人頭痛的，但又有着至關重要的作用。本文就B端産品後台的用戶權限該如何設計展開探讨，總結了自己在實戰中的相關經驗，希望對你有所啟發。

前一篇文章賬号篇跟大家聊了聊産品後台的基本邏輯和賬号體系設計相關的經驗。本文繼續聊最讓人頭痛的用戶權限設計。

開始之前，先回顧一下後台信息的分類，對于理解用戶權限設計有至關重要的作用。後台最核心的對象就是數據，B端後台一切的操作行為，本質上是對數據增、删、改、查的操作。

數據可以大體分為：

• 産品數據（文圖音視等數字内容、實體商品、算法模型等）。
• 用戶信息（個人資料、賬号、權限、組織等）。
• 用戶行為數據（PV、UV、點擊、用戶反饋等）。
• 業務數據（如用戶的訂單、商家的庫存、發布的内容等）。

帶有用戶信息的賬号訪問、使用服務商提供的産品數據，在整個過程中會留存大量的訪問、點擊、跳出等用戶行為數據，用戶購買産品、發布内容、提交表單等行為會産生業務數據。

一、系統權限的分類

根據筆者的經驗，後台的系統權限可以大緻分為三類：

1. 功能權限：該用戶在系統中，可以使用哪些功能模塊，使用哪些具體的功能。
2. 數據權限：該用戶在系統中，可以訪問哪些數據，是否可以對數據進行增、删改、查等操作。
3. 組織權限：對于B端産品來說，往往也涉及到組織架構。該用戶在不同的組織和不同的位置上，天然具有某些權限。比如在OA系統中的審批權限。與功能和數據權限有一些交叉，但是比較重要，所以單獨歸為一類。

為什麼說權限系統複雜呢？有過權限系統設計經驗的同仁可能深有體會。

首先，用戶前端、用戶後台、系統後台都有自己的一套權限體系，而且三者之間也會存在一定的關聯關系。三個系統的權限交織在一起，相互依存、相互限制，會導緻整體的權限系統極其難以設計。

其次，功能權限、數據權限和組織權限同樣是密不可分的。在一個組織特定位置的用戶，其權限一定涉及功能權限和數據權限。訪問功能的同時，一定會涉及到調取數據。而數據的訪問，也必然也要依賴數據查詢相關功能的支持。

最後，權限系統是要為業務服務的。需要根據業務合理設計權限系統，為相應的賬号賦予滿足業務需求的權限。但是不同的業務有不同的特點、流程、客戶&用戶需求，那麼權限系統必然也會因此産生各種個性化、定制化的需求。

二、系統權限的設計原則

既然後台權限的設計如此複雜和困難，那麼我們如何掌握設計後台權限的方法論呢？

筆者先介紹幾個設計原則，然後各位讀者可以結合後續的具體方法論進行實際的體會。

原則1 權限系統要為業務服務

這一條原則不證自明，也是最重要的設計原則。因此也自然要求涉及權限系統之前，一定要把業務邏輯梳理清楚。

原則2 權限系統設計一定要解耦合

無論在産品設計上還是技術架構上，務必注意功能權限、數據權限、組織權限之間和内部的解耦合。如果設計和技術架構不合理，将不同的權限耦合在一起，可能在未來業務變更的時候，出現大坑。

比如，如果将業務入口的權限和其内部具體功能模塊的權限耦合起來。一旦頁面需要調整業務入口，那麼其内部功能模塊都可能會受到影響。

原則3 權限系統設計要有兼容性

業務是不斷變化的，其相應的權限也一定會随之變化，因此權限系統設計要保證兼容性，避免因為寫死、沒有為新功能留後路等導緻無法适應業務的發展。

原則4 權限系統設計要盡量簡潔

奧卡姆剃刀原理告訴我們，“如非必要，勿增實體。”權限系統本身就是複雜性很高的系統，每增加一個要素，其設計和開發、測試複雜度都會激增。因此在滿足解耦合和兼容性的基礎上，權限系統設計要盡量簡潔。在成本和效率、長期和短期等之間尋找平衡。

原則5 從前台到後台依次設計

建議從用戶前端、用戶後台、系統後台的順序，從前到後、由易到難的順序設計權限系統。從簡單的權限開始設計，上手會比較容易，而且在設計過程中也能為更複雜權限的設計提供思路。而且一旦設計出現問題，局部優化或推翻重構的成本會更小。

各位讀者可以看出，以上的五個設計原則其實也是産品設計原則通用的一些原則。符合用戶習慣、易用性、可讀性、即時反饋等設計原則權限系統設計同樣要遵守。 不過在筆者的過往經曆中，認為以上五個原則是最重要的且容易踩坑的地方，因此特意拎出來加以強調。

三、系統權限的設計方法

權限系統的設計一般可以分成如下幾種思路：

• 完全寫死。對于非常簡單、基本不需要疊代的系統，可以直接寫死權限。
• 設置可選模闆。固定幾種權限角色，比如超級管理員、管理員、一般用戶等，直接将模闆關聯給賬号。适用于權限劃分清晰、業務相對簡單的系統使用。
• 可配置的模塊化權限系統。将權限通過梳理、歸納，設計為一個個獨立的可配置項，允許為每個賬号靈活配置權限。該方法最為靈活、普适，但是設計和開發難度最大。

筆者選取難度最大的可配置的模塊化權限系統，并且綜合功能權限、數據權限、組織權限，講解權限系統的設計思路。

掌握了最複雜的情況，其它相對簡單的權限系統設計自然手到擒來。

1. 系統權限分析

在着手設計之前，建議首先對系統的業務流程和需求、并結合權限進行完整的系統權限分析。

如何合理地分析系統的業務流程和需求，計劃放到後續的業務系統重點講解。如果該系列大家喜歡、且投票踴躍，筆者會堅持繼續更新。 分析腦圖的樣例如下。

腦圖中涉及的概念解釋如下。

• 部門：服務客戶的組織架構，可能存在多個層級。部門内的員工賬号關聯到對應的部門下，以和實際的組織架構保持一緻。
• 角色：每種角色作為一種權限設置的集合。可以通過為賬号配置角色，讓賬号獲得相應的權限。系統：提供服務不同的系統，可能為用戶前端、用戶後台、系統後台。
• 模塊：系統中的功能模塊。可能存在多個層級。比如旅行軟件，可以分為機票、酒店、火車票出行等，出行又可以分為網約車、租車等。
• 功能：根據業務需求，需要管控功能的最小顆粒度，比如網約車可以分為快車、專車、拼車，以及因公付款、個人墊付等。注意功能拆分一定要遵循MECE原則，完整且獨立。
• 數據：某些功能可能涉及到數據的增、删、改、查，比如說賬号管理、用戶發布内容管理等權限。

需要特殊說明的是，考慮到組織是客戶實際存在的組織架構，且有可能用到多個系統。因此把部門作為第一層級。

這樣去做梳理，可能對産品經理的全局觀和邏輯思維能力要求比較高，但是更符合實際業務情況。最終完成的權限系統兼容性也更強。

如果隻負責一個系統，那麼也可以以系統為第一層級，先把自己負責系統的權限梳理清楚。

注意如果多個系統是統一的賬号體系、且存在一個部門使用多個系統的情況，也需要與相關的産品同時做好同步，保證大家都設計思路一緻。否則萬一後續要做系統之間的整合，那麼重構的工作量會大大增加。

2. 系統權限設計

根據梳理出的權限系統腦圖，就可以比較清晰、方便地完成系統權限的産品設計工作。

筆者簡單模拟了一個系統權限的線框圖，以方便各位讀者理解。

首先設計部門列表，根據客戶的組織架構設計各級部門的列表和顯示重要的字段即可。對部門的操作同樣包括增、删、改、查。

然後是部門下的員工列表。每一個員工即代表一個可使用系統的實際賬号。那麼如何快速為不同的賬号配置權限呢？

關鍵在于角色這個字段的設計。在實際組織中，雖然一個部門内有很多的員工組成，但是可以按照其工作屬性進行分類。比如從職級維度，部門長、組長、員工、實習生等等。從職能上劃分，财務、會計、銷售、售前、售後等等。 有了角色，我們便可以根據該角色在系統中承擔的業務範圍，為其分配不同的系統權限，避免相同權限的賬号要重複配置。

下一步就是角色管理。根據業務需要，可以為該部門在不同的系統中設置角色，以滿足該部門員工在不同系統中的業務需求。

為了使用方便，可以提供一些系統中最常見的角色模闆，方便客戶的管理員直接使用，比如超級管理員、管理員等。

其中比較特殊的是超級管理員，其是一個系統中配置賬号的最基本、默認要有的角色。其最起碼應當有最全的賬号管理權限，以為其它同事創建賬号、分配權限。故該角色不應當被編輯和删除。

如果默認的角色模闆不能滿足業務需求，還可以再新增角色，完成個性化的權限設置。

最後也是最重要的，就是角色具體的權限設置。包括角色名稱、角色權限配置、角色備注等字段。

權限配置就是将腦圖中拆解的各模塊的功能權限和數據權限羅列出來，以為該角色勾選需要的權限。

為了使用方便，還可以有複制角色權限的功能（也可以放到角色列表中），可以直接沿用已有的、近似的角色權限，再進行微調，就可以快速完成一種新角色的添加。

3. 系統權限拾遺

本文主要講統一的設計方法論，也不宜結合具體的業務案例講。因為不同業務的差别太大，一旦過于具體，通用性和可遷移性就比較差。

“授人以漁，而不是授人以魚”，一直是筆者的經驗分享之一。

雖然本文看起來可能也沒有想象的那麼複雜。但是等到結合具體業務執行的時候，各位同仁就能發現很多困擾和難以取舍的點。

就比如做系統權限分析時，功能權限拆分到什麼顆粒度？如何做到MECE原則要求的完整性和獨立性？

拆得越細，自然越靈活，但是開發成本越高，也越容易出現功能耦合的情況；但是拆得過粗，可能無法滿足業務權限的精确管控，後續需要拓展時，就需要考慮到新老數據的兼容性問題。

還有賬号的角色變更或角色權限變更的時候，是否要即時生效？

如果需要即時生效，就需要每個功能在執行的時候都要校驗權限，系統開銷會很高、效率也會很低。

如果隻在登錄時候訪問權限，那麼系統權限變更就會存在較大的延遲。

折中的方案可能是定時刷新賬号的權限，那麼也可能涉及到主動通知系統前端時機的問題。

而且當賬号使用過程中出現了權限變更的情況，那麼該如何處理？刷新頁面隐藏功能還是有新的請求時候報錯？

管理員做删除和禁用操作的時候也存在類似的問題。而且删除和禁用的時候一定要判斷是否滿足删除的條件。

比如删除部門時，要考慮部門下是否還有子部門和賬号，如果有是否允許删除？

再比如删除角色時，如果有賬号關聯着該角色，是否允許删除？如果需要先取消所有賬号的關聯才允許删除，那麼如何方便地批量操作？如果允許直接删除，那麼如何方便地為受影響賬号分配新的角色？

這些問題，筆者也很難給出标準的、普适的答案，要根據具體的業務情況具體分析。

本次關系到系統權限的設計經驗就這裡。相信大家都能看到筆者的用心，不僅毫無保留地介紹經驗，還貼心地自己畫了線框圖，以幫助大家理解。碼字不易，請大家投票支持，給筆者繼續分享下去的動力！

為我投票

我在參加人人都是産品經理2022年度作者評選，希望喜歡我的文章的朋友都能來支持我一下~

點擊下方鍊接進入我的個人參選頁面，點擊紅心即可為我投票。

每人每天最多可投35票，投票即可獲得抽獎機會，抽取書籍、人人都是産品經理紀念周邊和起點課堂會員等好禮哦！

專欄作家

一直産品汪，apmdogy，人人都是産品經理專欄作家。邏輯型産品經理，緻力于将科學思維與産品經理方法論結合。關注人工智能、教育領域，擅長産品孵化、需求挖掘、項目管理、流程管理等産品技能。

本文原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部