手把手教你做B端的權(quán)限設(shè)計

WOWDesign
0 評論 5818 瀏覽 61 收藏 14 分鐘
🔗 技术知识、行业知识、业务知识等,都是B端产品经理需要了解和掌握的领域相关的知识,有助于进行产品方案设计和评估

權(quán)限設(shè)計對于大多數(shù)產(chǎn)品經(jīng)理來說都不陌生,屬于B端系統(tǒng)設(shè)計中一個至關(guān)重要的環(huán)節(jié)。有關(guān)權(quán)限設(shè)計的內(nèi)容浩如煙海,作者根據(jù)平時的項目實踐經(jīng)驗,探討了權(quán)限設(shè)計的定義、類型,詳細(xì)介紹了功能權(quán)限和數(shù)據(jù)權(quán)限的設(shè)計方法。希望能夠給你帶來幫助。

權(quán)限設(shè)計是B端系統(tǒng)設(shè)計中一個至關(guān)重要的環(huán)節(jié)。有關(guān)權(quán)限設(shè)計的內(nèi)容浩如煙海,筆者根據(jù)平時的項目實踐經(jīng)驗,總結(jié)出B端系統(tǒng)權(quán)限設(shè)計的以下幾點心得,共分為三大部分:

  1. 權(quán)限設(shè)計的定義;
  2. B端系統(tǒng)權(quán)限設(shè)計的分類;
  3. B端系統(tǒng)權(quán)限設(shè)計的方法。

其中第三部分為本文的重點,詳細(xì)介紹了功能權(quán)限和數(shù)據(jù)權(quán)限的設(shè)計方法。關(guān)于權(quán)限設(shè)計的用戶管理、用戶組管理、角色管理、權(quán)限管理等內(nèi)容,主要是列表頁、編輯頁、詳情頁等頁面流程以及增刪改查等操作,本文不再贅述。

一、權(quán)限設(shè)計的定義

權(quán)限設(shè)計是指系統(tǒng)為解決某一具體的權(quán)限分配問題而進(jìn)行的設(shè)計。

為什么需要分配權(quán)限呢?一般是出于職位職責(zé)和數(shù)據(jù)安全兩個方面的考慮。

例如,一個客服平臺的質(zhì)檢系統(tǒng)需要管理員、質(zhì)檢員、坐席等不同職位,不同職位擔(dān)任的職責(zé)均不相同,這就需要通過功能權(quán)限劃分進(jìn)行管理。

同時,考慮到系統(tǒng)的數(shù)據(jù)安全性,不同賬號被允許查看的數(shù)據(jù)范圍也不相同。管理員可以查看并操作全量數(shù)據(jù),而坐席只能查看個人數(shù)據(jù),因此,需要設(shè)計數(shù)據(jù)權(quán)限。

二、B端系統(tǒng)權(quán)限設(shè)計的分類

B端系統(tǒng)權(quán)限主要分為兩類:功能權(quán)限和數(shù)據(jù)權(quán)限。

功能權(quán)限是指用戶登錄系統(tǒng)后可以操作哪些菜單、哪些頁面以及哪些頁面元素。例如,質(zhì)檢員登錄W客服平臺的AI質(zhì)檢系統(tǒng)后,可以在質(zhì)檢詳情頁對AI質(zhì)檢結(jié)果進(jìn)行增刪改查,而坐席人員只能查看不能操作。因此,就頁面的功能權(quán)限而言,二者是不一樣的。

數(shù)據(jù)權(quán)限是指用戶登錄系統(tǒng)后可以查看的數(shù)據(jù)范圍,即能查看多少數(shù)據(jù),什么類型的數(shù)據(jù)。例如,W客服平臺的AI質(zhì)檢系統(tǒng)的質(zhì)檢記錄列表,管理員能查看所有坐席人員的質(zhì)檢記錄,而坐席人員只能查看自己的質(zhì)檢記錄。因此,二者的數(shù)據(jù)范圍不同。

我們在做權(quán)限設(shè)計時,一定要區(qū)分系統(tǒng)的功能權(quán)限和數(shù)據(jù)權(quán)限,不要糅合在一起。

三、B端系統(tǒng)權(quán)限的設(shè)計方法

(一)如何設(shè)計B端的功能權(quán)限

RBAC模型

RBAC模型(RBAC,Role-Based Access Control)是指基于角色的訪問控制,該理論于1995年由計算機科學(xué)家Ravi Sandhu提出來的。主要描述了一套用戶、角色、權(quán)限的設(shè)計理論,已被業(yè)界廣泛使用。

RBAC模型理論的核心思想是:在用戶與權(quán)限之間增加一個媒介,即角色。通過給每個用戶賦予一個或多個角色,再給每個角色分配相應(yīng)的權(quán)限,從而將角色關(guān)聯(lián)的權(quán)限賦予給用戶。

為什么要引入“角色”這個概念呢?為了更好地說清楚RBAC模型的核心思想,我們來看個B端設(shè)計案例。W客服部門做了一個AI質(zhì)檢系統(tǒng),起初由于業(yè)務(wù)量少,質(zhì)檢系統(tǒng)只安排了1個質(zhì)檢員小明,讓他負(fù)責(zé)審核AI質(zhì)檢結(jié)果并確認(rèn)質(zhì)檢。管理員給小明創(chuàng)建了系統(tǒng)賬號,并直接綁定了質(zhì)檢權(quán)限。

后來,隨著業(yè)務(wù)量的不斷增加和坐席團隊的日益壯大,W客服部門已增至幾十個質(zhì)檢員,每次有新增的質(zhì)檢員,管理員都需要給其綁定相應(yīng)的權(quán)限,后續(xù)有修改也無法進(jìn)行批量操作,需要對每一個賬號操作一遍。這樣,管理員的重復(fù)性工作太多,工作效率大打折扣。

試想,如果設(shè)置一個角色,并把相關(guān)權(quán)限賦予該角色,那么在添加新賬號的時候,只需將該賬號綁定該角色,就能擁有該角色所具有的權(quán)限。如果需要調(diào)整權(quán)限,也無需操作每個賬號,只需修改該角色綁定的權(quán)限即可,所有賬號的權(quán)限跟著改變,這將極大地提高管理員的工作效率。

關(guān)于RBAC模型的核心思想,圖示如下:

關(guān)于RBAC模型,還有很多延展性理論。例如:根據(jù)模型的復(fù)雜度,又可分為RBAC0、RBAC1、RBAC2、RBAC3。其中,RBAC0是上面介紹的基礎(chǔ)理論。后面幾個涉及到角色繼承、角色約束、用戶組等概念,我們可根據(jù)自己業(yè)務(wù)的實際情況選擇合適的理論模型,在此不再贅述。

根據(jù)RBAC模型理論,我們怎么設(shè)計B端系統(tǒng)的功能權(quán)限呢?

1、設(shè)計合理的角色。合理的角色設(shè)計是權(quán)限設(shè)計的前提。在此基礎(chǔ)上,只需要配置每個角色能查看哪些菜單,訪問哪些頁面,操作哪些頁面元素就行。

例如,通過業(yè)務(wù)分析,W客服平臺的AI質(zhì)檢系統(tǒng)的角色有:管理員、質(zhì)檢員、坐席、游客。管理員負(fù)責(zé)系統(tǒng)配置和管理。質(zhì)檢員負(fù)責(zé)對AI質(zhì)檢結(jié)果進(jìn)行檢查和確認(rèn)。坐席可查看自己的質(zhì)檢結(jié)果,提出復(fù)議。游客可登錄系統(tǒng)查看質(zhì)檢模塊介紹。

2、明確需要做權(quán)限控制的功能點,以權(quán)限表的形式羅列出來。

功能權(quán)限包括菜單權(quán)限、頁面權(quán)限和頁面元素權(quán)限。將需要做權(quán)限控制的功能點以菜單、頁面、頁面元素的層級羅列出來。如果菜單、頁面有多個層級,則將每個層級都羅列出來。以下表格是W客服平臺的AI質(zhì)檢系統(tǒng)的智能質(zhì)檢模塊需要做權(quán)限控制的功能點:

3、列出角色,找到權(quán)限與角色之間的對應(yīng)關(guān)系,完善權(quán)限表。我們再把W客服平臺的AI質(zhì)檢系統(tǒng)的角色列在權(quán)限表后面,并勾選每個角色擁有的權(quán)限,完善角色與權(quán)限的對應(yīng)關(guān)系,具體圖示如下:

從以上權(quán)限表,我們可以看出:

  1. 在質(zhì)檢記錄列表頁中,管理員和質(zhì)檢員這兩個角色可以操作所有篩選條件,而坐席只能操作“時間段”、“客戶名稱”、“客戶手機號”、“狀態(tài)”4個篩選條件。
  2. 在質(zhì)檢詳情頁中,質(zhì)檢員可以操作“添加質(zhì)檢類目”、“添加質(zhì)檢項”、“刪除質(zhì)檢類目”、“刪除質(zhì)檢項”、“確認(rèn)質(zhì)檢”、“提交質(zhì)檢評論”、“編輯質(zhì)檢評論”、“刪除質(zhì)檢評論”、“查看質(zhì)檢評論”、“查看復(fù)議”11個按鈕;管理員能操作“查看質(zhì)檢評論”、“查看復(fù)議”2個按鈕;坐席能操作“查看質(zhì)檢評論”、“提出復(fù)議”、“編輯復(fù)議”、“刪除復(fù)議”、“查看復(fù)議”5個按鈕。

以權(quán)限表的形式將各角色與功能權(quán)限一一對應(yīng)呈現(xiàn)出來,清晰明了,不容易遺漏。

(二)如何設(shè)計B端系統(tǒng)的數(shù)據(jù)權(quán)限?

數(shù)據(jù)權(quán)限是建立在功能權(quán)限基礎(chǔ)之上的。沒有功能權(quán)限,就不會有數(shù)據(jù)權(quán)限。

例如,某個角色在W客服平臺的AI質(zhì)檢系統(tǒng)中如果不能查看質(zhì)檢記錄列表,自然也談不上能看到多少數(shù)據(jù)量的問題。

關(guān)于數(shù)據(jù)權(quán)限,一般包含兩種情況。

一種是無組織架構(gòu)的數(shù)據(jù)權(quán)限。這類數(shù)據(jù)權(quán)限設(shè)計相對簡單。根據(jù)不同的業(yè)務(wù)情況,可以選擇直接在創(chuàng)建角色時選定相應(yīng)的數(shù)據(jù)權(quán)限范圍,也可以將規(guī)則以文字描述的形式羅列在權(quán)限表后面。

例如,W客服平臺的AI質(zhì)檢系統(tǒng)各角色間不涉及上下級的層級架構(gòu),因此,只需在功能權(quán)限表后新加一欄數(shù)據(jù)權(quán)限,將各角色的數(shù)據(jù)權(quán)限規(guī)則描述出來即可,具體圖示如下:

第二種是有組織架構(gòu)的數(shù)據(jù)權(quán)限。

組織架構(gòu)是指,一個組織整體的結(jié)構(gòu)。企業(yè)的組織架構(gòu)是企業(yè)的流程運轉(zhuǎn)、部門設(shè)置及職能規(guī)劃等最基本的結(jié)構(gòu)依據(jù)。

例如,A公司營銷部門的組織架構(gòu)為:營銷總監(jiān)下設(shè)營銷部經(jīng)理和業(yè)務(wù)部經(jīng)理,經(jīng)理分別下設(shè)兩個主管,主管下設(shè)專員,上級領(lǐng)導(dǎo)下級,下級對上級負(fù)責(zé)。具體圖示如下:

A公司營銷部的業(yè)務(wù)訴求是:營銷總監(jiān)能查看營銷部的所有數(shù)據(jù),部門經(jīng)理能查看本部門的所有數(shù)據(jù),部門主管能查看所有下屬的數(shù)據(jù),專員只能查看自己的數(shù)據(jù)。

那我們?nèi)绾瓮ㄟ^組織機構(gòu)樹進(jìn)行數(shù)據(jù)權(quán)限設(shè)計呢?

1、根據(jù)業(yè)務(wù)訴求,我們創(chuàng)建管理員、部門管理員、部門主管、普通用戶4個角色,并定義這4個角色在組織機構(gòu)樹中的權(quán)限范圍,具體如下表所示:

2、給相應(yīng)人員創(chuàng)建賬號,并將對應(yīng)的角色賦予賬號,具體圖示如下:

3、系統(tǒng)通過讀取這棵組織機構(gòu)樹上的節(jié)點來實現(xiàn)數(shù)據(jù)權(quán)限的控制。

  • 賬號0被賦予管理員角色,該賬號處于整棵組織機構(gòu)樹根節(jié)點的位置,且數(shù)據(jù)權(quán)限是“當(dāng)前節(jié)點及其所有子節(jié)點”,因此,賬號0可以查看整個營銷組織的數(shù)據(jù),并能對其進(jìn)行增刪改查等操作。
  • 賬號1被賦予部門管理員角色,該賬號處于營銷部經(jīng)理的根節(jié)點,且數(shù)據(jù)權(quán)限是“當(dāng)前節(jié)點及其所有子節(jié)點”,因此,賬號1可以查看營銷部的所有數(shù)據(jù),并能對其進(jìn)行增刪改查等操作。
  • 賬號2被賦予部門主管角色,數(shù)據(jù)權(quán)限是“當(dāng)前節(jié)點及其所有子節(jié)點”,因此,賬號2可以查看本人及其下屬的所有數(shù)據(jù),并能對其進(jìn)行增刪改查等操作。
  • 賬號3被賦予普通用戶角色,數(shù)據(jù)權(quán)限是“當(dāng)前節(jié)點”,因此,賬號3只能查看并操作本人的數(shù)據(jù)。

至此,根據(jù)組織機構(gòu)樹已實現(xiàn)對整個營銷部門的數(shù)據(jù)權(quán)限管理。

四、結(jié)語

本文探討了權(quán)限設(shè)計的定義、類型,著重介紹了功能權(quán)限和數(shù)據(jù)權(quán)限的設(shè)計方法。然而,這些只是權(quán)限設(shè)計的冰山一角。在接下來的B端系統(tǒng)的設(shè)計生涯中,期待我們更多的理論探索和實踐驗證!

作者:WOWdesign,研究設(shè)計價值最大化,涉及用戶體驗、品牌體驗、空間體驗。

本文由人人都是產(chǎn)品經(jīng)理合作媒體 @WOWdesign 授權(quán)發(fā)布,未經(jīng)許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于 CC0 協(xié)議。

該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù)。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發(fā)揮!
专题
18049人已学习15篇文章
签到功能是培养用户习惯的好办法。本专题的文章提供了签到功能的设计指南。
专题
12423人已学习16篇文章
栅格系统在页面排版布局、尺寸设定方面给了设计者直观的参考,它让页面设计变得有规律,从而减少了设计决策成本。本专题的文章分享了浅析栅格系统。
专题
12158人已学习11篇文章
本专题的文章分享了消息通知系统设计指南。
专题
12893人已学习12篇文章
“私域流量”概念火爆的背后,既有企业焦虑,也有赛道风口。而巧的是,在线教育同样面临增长获客难的问题。本专题的文章分享了在线教育行业如何做私域运营。
专题
32152人已学习10篇文章
社交产品是大坑?没get到这些知识点,可能你才是个大坑。
专题
12924人已学习12篇文章
营销数字化与数字化营销,是两个不同的概念,很多容易混淆。本专题的文章分享了关于营销数字化的解读。