用戶權限管理是平台類産品的基礎，怎樣設計平台的用戶權限對後續的場景和拓展至關重要。本文通過簡單的例子總結幾點“用戶角色權限”設計思路供大家參考。

我是在2016年的一個B端管理項目中第一次接觸到用戶權限設計，因為當時是測試 需求分析的職責，所以隻是把這裡面的功能梳理明白，知道怎麼用，并沒有深入思考。

轉崗産品之後，經常會在社群裡看到有人問類似于用戶管理怎麼做，權限設置怎麼控之類的問題，這類問題幾句話也說不明白。

所以今天把自己對這部分的理解整體梳理出來，既能作為部門新入職同事的培訓材料，同時也希望對讀到這篇文章的你帶來一點幫助。

其實用戶權限設計對于C端産品也經常遇到，比如普通用戶、VIP用戶可能看到的功能就不一樣，或者同樣的頁面看到的數據也不一樣。不過更廣泛的應用還是在B端産品，或者C端産品的管理後台（平台管理端）

我們以B端産品為例，平台提供了200個功能菜單，500個功能按鈕，但是使用者的身份不同，或使用目的不同，有的人可能隻用到其中的一小部分功能。

或者對于企業來說，不同人員的分工不同，相同部門但不同級别的人員可操作權限不同、可查看的數據不同等等，這些實際的使用場景都最終指向了産品中靈活的、可自定義配置的權限管理功能。

這樣說可能比較寬泛，我們代入一個實際的場景（能理解的可以直接跳過看下一小節）。

一家兩百人的互聯網企業，分為研發部、銷售部、财務部、人事部，這家企業采購了一個數字化辦公軟件。

• 人事部用它對企業的人員信息、招聘信息、員工的入職、轉正、調崗、離職等進行管理；
• 财務部用它制定公司的成本預算、記賬報賬、核算并發放工資、歸檔發票等；
• 而全體員工也都使用平台進行OA辦公，線上流程發起及審批；
• 企業高管則通過平台的各類統計功能監控、查看企業的日常經營數據。

在這個場景中，平台的功能頁面可能有幾百個，但是針對不同的部門人員，登錄之後看到的功能菜單是不盡相同的，或者同一個菜單的操作權限也是有差異的。

• 比如【入職信息查詢】頁面，hr和行政都能查看，但是hr有【入職】的按鈕，行政卻沒有；
• 比如财務部的财務專員A和B，一個負責研發部預算，一個負責銷售部預算，雖然他們都能訪問預算功能，但看到的數據也是不一樣的；
• 而C作為财務部總監，全公司的預算數據都可以看到。

以上提到的場景都是實際應用中最常見的，我們一起來看看如何進行設計吧

我習慣于把權限分為以下幾類：

1）頁面權限

即功能菜單的權限，以一級菜單->二級菜單->三級菜單->四級菜單的級别依次呈樹形排列。勾選上的菜單即可訪問，同時被選擇菜單的上級也默認被選擇（好比沒有單元門，你怎麼找到家門？）。

2）按鈕權限

按鈕通常分為“增、删、改、查”四大類，增的類型有很多，涉及的業務面也很廣，比如新增員工信息、新增預算信息、新增發票信息等，都屬于每個頁面權限下的“增”。對于四類操作，一定不是擁有這個頁面就一定擁有所有操作權限，因為很多人可能隻有查的權限。所以要做好權限控制，一定要做按鈕的控制。

以上兩部分又可統稱為功能權限。

同時我準備了兩個常見的功能權限配置樣式，抛磚引玉，希望能給你帶來一點思路：

方案1

方案2

3）數據權限

最常見的數據控制手段是基于“組織架構樹”，組織架構（部門/分支機構）中的上級可以查看本級及下級的所有數據，或者可以指定某個組織的數據。

4）應用權限

這是後續衍伸出來的功能組集合。我們可以把一個功能組抽象為一個應用。比如按照上面的例子，可以把産品内的功能合并成以下幾類：包含了人事服務、财務服務、辦公服務、假勤服務、數據服務、客戶服務等幾大應用。我們可以先整體為這家企業賦予某些應用的權限，再在這些應用下為用戶分配不同的功能權限。

當然，如果我們把它定義為頁面權限中的一級菜單，也是可以的，隻不過當平台内的功能越來越多時，一級菜單的個數也會很多，菜單的級别也會很深。所以再單獨抽象一個新的功能組概念，不僅從理解上更清晰，看起來也高大上了一些~而且這些功能組後續還能作為增值服務為B端客戶設置開通、付費等衍伸場景。

除了權限的分類，為了最終達成設計目标，我們還會引入【角色】的概念。

1）角色

角色是上述幾類權限的集合

我所理解角色的設計目标是：為了解耦，為了可批量配置化（具體關系請看第三小節）。

• 比如财務專員角色，包含了10個頁面，25個按鈕，數據為隻能看到研發部；
• 人事專員角色，包含了20個頁面，15個按鈕，數據為全公司。

2）用戶

用戶是平台的使用者，用戶登錄之後能夠看到的，能夠操作的數據，都來自于我們為這個用戶賦予了哪些角色，這些角色中擁有哪些權限。

• 比如張三和李四都是财務專員角色，就可以在10個頁面中看到研發部的相關數據，并進行25種操作；
• 比如王五和趙六是人事專員角色，就可以在20個頁面中看到全公司的相關數據，并進行15種操作。

當然，如果張三升職了，變成了統管财務和人事的負責人（财務主管），那麼我們可以為張三同時賦予兩個角色，張三的功能權限和數據權限就變成了這兩個角色的“并集”。

（請自覺忽略我的“靈魂畫筆”）

通過【角色】将各類權限彙集起來，批量賦予每個【用戶】，再通過組織架構将每個用戶的數據權限進行篩選。

最終功能權限和數據權限結合，呈現給用戶。

組合的方式也有兩種，我們可以根據自己産品的實際情況進行選擇。

方式1（功能權限 數據權限=角色->用戶）

方式2（功能權限->角色 數據權限 =>用戶）

無論哪種方式，都可以保證設計的關聯性和清晰度，還能在修改時減少操作環節。

比如方式1中，企業現在有10個人擁有财務專員的角色，如果要給财務專員增加15個新的功能，并增加對銷售部的數據管理範圍，我們隻需要針對【财務專員】這個角色進行一次修改即可生效。

1. 對于企業多級部門的數據權限配置

上面寫到的是一些簡單的場景，實際應用中，會有很多企業存在多級部門的情況，比如研發部下分為研發一部、研發二部，研發一部又分為産品部、技術部。

對于擁有相同功能權限的張三和李四，在數據權限上張三需要查看研發一部所有數據，而李四隻能查看研發一部本級的數據。

所以後期我們可以在數據權限設置時增加對組織架構的設定的三種類型：

2. 初始化角色（預制角色）

用戶權限設置完成後，我們還需要考慮新用戶的預制角色，我們不能讓用戶從零開始一點點配置，因為這樣不僅費時費力，大部分用戶也配不明白，即便平台提供了培訓手冊或視頻，但是又有多少用戶會認真看呢？

所以不同的平台對于新入駐的用戶，要預制一套相對常規的規則。當然不僅是預制角色，其他的業務功能也需要按需預制，畢竟降低用戶的理解難度和操作難度，也是提高入駐率的關鍵方式。

後續我也會單獨整理我們可以采用哪些方法降低B端用戶的上手難度和準入門檻，歡迎持續關注~

3. 有些功能需要單獨維護訪問權限

有些場景不太好通過平台級的設計來解決，建議還是針對具體的場景進行特色化設計。

比如企業的合同管理功能，人事一部隻能看到員工的勞務合同，人事二部隻能看到員工的保密協議。這種按業務類型區分的數據分類，參照上文的設計模式就不好實現，所以隻能在合同管理功能中單獨增加以類型區分的數據篩選條件。

1. 盡量不要把特色化改動直接挂到“用戶”上

即便遇到一些偶現的用戶權限特殊處理，也盡量采用對角色的新增和配置形成權限集合後，再賦予用戶，而不是在用戶上直接進行修改。

2. 在最終測試驗證環境，一定不要隻使用【超級管理員】操作

因為超管一般不會出問題，我們需要使用新維護的角色，代入用戶的實際使用場景，對平台的功能進行全流程冒煙測試，在這個過程中才能夠發現更多的隐藏問題。

以上就是今天對用戶權限的設計總結。

設計思路是一回事，具體的解決方案又是另一回事，希望今天的分享能夠為你帶來一些幫助。

權限設置在後續的工作中和實際場景連接後，會演變出非常多的可能性，所以需要我們結合自身團隊的訴求，産品的目标和現狀，和研發人員一起讨論出更合理的設計方案。

作者：不想延期，公衆号：不想延期

本文由 @不想延期 原創發布于人人都是産品經理，未經許可，禁止轉載

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

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

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