起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識權限管理的“前世今生”
編輯導語：“權限管理”在日常生活中十分常見，它規定了用戶各自的角色和可使用的職能。那么，在B端產品中，“權限管理”應該如何設計？本篇文章里，作者針對權限管理系統的發展和設計策略做了解讀，一起來看一下吧。
什么是權限管理？百度百科解釋道：權限管理，一般指根據系統設置的安全規則或者安全策略 ，用戶可以訪問而且只能訪問自己被授權的資源，不多不少。
何為“不多不少”？簡單來講，就是“用戶”可以“做什么”，以及可以“做到什么程度”，都是通過權限管理來控制。
一、“前世”的權限縮影
在我們的生活當中，大到國家、政府，小到企業、家庭，到處都透露著“權限”的縮影。
以企業為例，不同的員工，所對應的崗位職責（也就是權限）也不同：
- 人力資源部經理張三負責公司的員工招聘工作，崗位職責是招人及員工管理；
- 而李四作為人力資源部的一名人事助理，其崗位職責則是員工信息的檔案管理。
以上舉例，局限于崗位職責。還有一些更加豐富、更加細膩的權限管理。比如：
- 張三是北京分公司的人力資源部經理，他只能夠管理北京分公司員工和北京分公司下屬的子公司（海淀子公司、朝陽子公司等）的員工；
- 王五是海淀子公司的人力資源部經理，他也只能夠管理海淀子公司的員工。
這些崗位職責和資源（也稱為數據）直接相關，又稱為數據級權限管理。
二、“今生”的權限寫照
1、現實與權限管理的映射關系
在互聯網行業中，權限管理系統中的角色一般跟企業的組織架構是一致的：企業組織架構中的員工在什么崗位要做什么事情，跟權限管理系統中的用戶是什么角色被允許進行什么操作，是一種對應關系。
所以企業架構中的員工、崗位、職責和資源 ，分別對應了權限管理系統中的用戶、角色、權限和數據。
2、權限管理的分類
從控制力度來看，可以將權限管理分為兩大類：
- 功能級權限管理；
- 數據級權限管理。
從控制方向來看，也可以將權限管理分為兩大類：
- 從系統獲取數據，比如查詢訂單、查詢客戶資料；
- 向系統提交數據，比如刪除訂單、修改客戶資料。
系統層面的權限管理，主要還是從控制力度上來進行設計。
三、如何進行權限系統設計
權限系統主要由三大部分構成：用戶管理、角色管理、權限管理。
1、用戶管理設計
賬號作為一個用戶登錄系統的唯一身份標識，其主要通過用戶管理進行維護，一般包含有列表頁面、詳情頁面、新增頁面。
可以先設想下用戶管理大概需要用到哪些字段？梳理完的信息結構圖如下：
注：這里以最小可行性的字段設計為例，不同的企業所需要的字段要素會有所增減。
- 用戶編號：作為用戶的唯一標識，一般由系統自動生成，由低到高遞增；
- 用戶名：用戶用于登錄的賬號，一般支持字母、數字和下劃線，需區分唯一性；
- 密碼：賬號登錄密碼，支持字母、數字和特殊字符，需區分大小寫；
- 角色：數據來源于“角色管理”中已維護的角色，可支持多選。
“角色”為什么要支持多選？咱們下面再講。
為什么這里不設計一個詳情頁面？因為字段較少，列表已經能顯示下所有的字段要素，所以沒必要再新增一個詳情頁面。只有當列表頁顯示不下所有字段要素的時候，才有必要設計一個詳情頁來展示所有的用戶信息。
現在信息結構圖有了，接下來就可以開始設計原型，設計完的頁面如下：
（原型：用戶管理）
（原型：新增用戶）
2、角色管理設計
系統中用戶的權限是通過角色來控制，角色可以理解為具備一定權限的用戶組，也叫權限的集合，劃分角色的好處是可以大大降低用戶權限分配的重復性工作量。
“角色管理”的信息結構圖如下：
- 角色編號：角色的唯一標識，一般由系統自動生成，由低到高遞增；
- 角色名稱：主要用于識別，可限制不可出現相同的角色名稱；
- 上級：選擇所屬上級角色，用于搭建組織架構。
根據信息結構圖所設計的頁面如下：
（原型：角色管理）
（原型：新增角色）
做到這里，“角色管理”還稱不上結束，因為還差一個最關鍵的“權限”。
3、權限管理設計
上文中已經講過，“權限”分為“功能權限”和“數據權限”。
“功能權限”可粗可細，粗可以到菜單級別，細則可達到功能按鈕級別。
“數據權限”有兩種處理方式：
- 一種是自動繼承組織架構關系，這種不涉及頁面配置，由程序根據用戶的從屬關系自動關聯。比如：銷售部經理可以查看整個部門的銷售數據，而銷售部的普通員工則只能看到自己的銷售數據；
- 另一種則是由人工自行配置，劃分所需要查看的數據權限。
那么，“角色管理”的信息結構圖，加上“權限”后顯示如下：
（橙色為新增“權限”部分）
在企業中，一個員工可以身兼多個崗位，一個崗位也可能有多個員工，所以員工和崗位是多對多的關系，由此可以得出“用戶”和“角色”之間也是多對多的關系。一個“角色”可以分配多個“權限”，同樣一個“權限”可以分配給多個“角色”使用，故“角色”和“權限”之間也是多對多的關系。
如果一個用戶擁有多個角色，那這個用戶的權限則取的是這多個角色權限的并集。
“角色管理”的頁面加上“權限”后如下：
（原型：角色管理）
（原型：配置數據權限）
（原型：配置功能權限）
另外，頁面上的功能權限展示，建議與系統模塊、菜單頁面的順序來排列好，便于用戶理解。
到此，權限系統差不多就設計完了，后續系統在不斷的更新迭代時，權限系統也需要做對應的調整。大到功能模塊的增、刪，小到功能命名的變更，權限系統都需要做到同步變更，以求一一對應。
四、總結
權限管理對于B端產品來說必不可少，權限管理具體應該做到什么程度，跟企業運營息息相關。在設計權限系統時，一定要結合企業發展，提前做好規劃，才能滿足業務需求。
作者：WOWdesign，研究設計價值最大化，涉及用戶體驗、品牌體驗、空間體驗。
本文由 @WOWdesign 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Pexels，基于 CC0 協議
請問數據權限要怎么具體設計呢？可以展開講講嗎
有遇到同一個用戶對不同的數據范圍有不同的功能權限的嗎？好像說是完全數據驅動
通過角色管理功能權限，通過組織架構管理數據權限；數據權限管理的常用方式：1、 數據權限可以通過組織架構的上下級來繼承； 2、除了繼承，支持自定義：按 全部數據、本部門及下級部門數據、本部門數據、本人數據等； 3、在自定義數據權限基礎上更進階的設計，是數據權限的多維度配置，比如一個銷售訂單，有銷售員、銷售部門、銷售區域等部門維度，也有產品1、產品2等類型維度，多維度數據可以交叉，然后去交集就是最終的數據權限。
文章權限設計-頁面上線功能權限展示，這種比較適用于單個系統的權限管理配置。但權限管理系統基本可以抽象通用化，一般公司都維護一套權限管理系統，定義好與各個業務系統接口調用即可。如果多個系統共用，功能權限展示可以定義成樹狀結構，每個系統獨自定義菜單、子菜單和功能即可，通用性會更強~
這種需要公司各個系統用戶群一致吧？如果不同系統服務不同客戶就不行了。
請問一下，對于列表數據的增刪改查是屬于數據權限還是功能權限呢？??
功能權限
用戶可以跟部門掛鉤
但是關于數據權限我有一個問題，配置數據權限時是選擇角色，但是角色是活的可以隨意配置的，這些角色各自能看到哪些數據該如何規定呢？
給角色配權限就能滿足，比如財務這個角色只給他開放財務相關的權限
那如何定義哪些數據屬于財務方面的數據呢，是系統設計的時候定義好的嗎還是系統可以配置的？
作者的意思大概是：給當前角色配置數據權限，如當前角色下還有若干個子角色，選擇自定義配置時選擇可以擁有哪幾個子角色的數據權限！我是這樣理解的，不知道對不對??
太棒了！條理清晰，還有原型展示，多謝作者分享！
角色有上級 這個有點問題。個人感覺是把角色與崗位等同了，不太妥當
很多企業管理軟件都有這個設計，可能是方便使用
角色把崗位等同，會導致角色數量變多，比如銷售部門：一組銷售組長、二組銷售組長； 用作者的方法，需要設置兩個角色。實際上兩個組長的功能權限是相同的，都叫“銷售組長”，不同的是數據權限，一組可以看一組負責的客戶數據，二組組長可以看到二組負責的客戶數據。
對于數據權限，應該是掛到用戶上；通過用戶的部門、上級來維護一套組織架構，實現數據權限的繼承。實現自定義數據權限，就是直接把某個用戶的數據給到 另外一個用戶
對權限管理系統的發展和設計策略分析得很清晰，喜歡這種有思維導圖的文章。
角色管理為什么要有上級角色
什么時候權限管理的設計能夠真正做到維護用戶隱私呢，感覺互聯網時代個人隱私越來越難得到保障了。