權限的設計對於B端產品來説,是一個系統的底層設計,在初期設計時,一定考慮到未來權限的可拓展性,否則一旦改動起來,就是傷筋動骨的大事。本文從六個方面分析權限設計,對權限設計感興趣的童鞋不要錯過。
權限設計的原則:
基於用户的真實工作場景對數據權限和功能權限進行的邊界條件設計。
權限設計的目的:
在做權限設計時,建議將數據權限與功能權限進行分開設計,方便自由搭配,靈活配置。因此會存在低數據,高權限的情況和高數據,低權限的情況。
一個角色對應一個功能權限,一個角色對應多個用户,每一個用户都有屬於自己的數據權限;
權限的設計思路需要先設計角色盒子,每一個盒子有相同的工作場景,因此所具備相同的功能權限;然後再在盒子裏面添加對應權限的用户。每一個用户均可以建立自己的喬梁,從而匹配自己所見的數據權限範圍。
功能設計,需設計兩部分內容:
很多公司的權限設計會基於公司的組織架構進行匹配。這種更適合對於組織架構直接影響用户權限的應用場景,並且根據組織架構對權限的高低進行了劃分,但用户真實的使用場景並非完全基於組織架構所對應的權限關係,其靈活度較低,但優點是組織架構調整後,權限也可實時進行同步調整。
另一種是對完全自定義操作的界面以及權限的高低,如下圖:
當角色類別較為固定時,可以進行初始化預置,完成對應權限的匹配,節省工作量。當然允許對權限進行修改和調整。
在設計數據權限時,需要找到人與數據的橋樑,針對不同的業務場景,其橋樑也不同。比如以電商後台為例,可將人會與對應的店鋪進行關聯,從而可以看到關於該店鋪的相關數據。
要點:注意橋樑合理性,橋樑不能為死數據,如果任何因素影響橋樑時,也需對用户對應的數據權限同步進行調整。
舊數據清理:如果權限並非從0-1的規劃設計時,將存在已有的歷史用户數據,因此,需要重新將歷史數據匹配到新的權限規則中,這也是產品經理需要在方案構思中要考慮的問題。
對IT管理員和日常運維人員角色進行補充:在設計權限角色時,需要考慮到IT管理員和日常運維角色的使用場景,並根據場景不同,匹配對應的數據和功能權限。畢竟他們也是整個項目團隊中非常重要的角色,也需要基於數據進行問題排查和用户答疑。
以上就是筆者對後台權限部分的梳理。權限部分的調整要做到靈活性,可配置性,兼顧未來的可拓展性,否則每次的改動對開發和測試人員來説都是一件費時費力頭疼的事情。
本文由@黑心老巫婆 原創發佈於人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基於CC0協議