關(guān)于大后臺(tái)的權(quán)限管理設(shè)計(jì)

19 評(píng)論 29836 瀏覽 323 收藏 16 分鐘

編輯導(dǎo)語:大后臺(tái)是多個(gè)產(chǎn)品后臺(tái)的域名入口,如今很多產(chǎn)品都采用了這種方式進(jìn)行管理,可以使產(chǎn)品得到各方面的一致性;大后臺(tái)的搭建也可以讓產(chǎn)品得到更好、多層次的體驗(yàn);本文作者分享了關(guān)于大后臺(tái)的權(quán)限管理設(shè)計(jì),我們一起來了解一下。

一、何為大后臺(tái)?

本文講述的大后臺(tái)是基于作者的實(shí)際工作需要而提出的后臺(tái)整合型的概念,是內(nèi)部多個(gè)后臺(tái)系統(tǒng)的集合。

具體是指,多個(gè)產(chǎn)品后臺(tái)通過一個(gè)域名入口,接入集團(tuán)通訊中心,實(shí)現(xiàn)統(tǒng)一的登錄和權(quán)限管理,采用類似的UI規(guī)范展示;并在這過程中形成統(tǒng)一的產(chǎn)品矩陣,形成技術(shù)影響力。

因此,用戶可更加便捷訪問相關(guān)產(chǎn)品,管理員也可以在權(quán)限設(shè)置上達(dá)到事半功倍的效果。

二、為什么要進(jìn)行大后臺(tái)的整合?

在兩年多的時(shí)間內(nèi),產(chǎn)品技術(shù)部開發(fā)了多款不同領(lǐng)域的產(chǎn)品,目前負(fù)責(zé)開發(fā)和運(yùn)維的產(chǎn)品后臺(tái)有6個(gè)。

早期的產(chǎn)品都是獨(dú)立域名、獨(dú)立登錄賬號(hào)系統(tǒng)、獨(dú)立的UI視覺和交互。后期的幾個(gè)產(chǎn)品在進(jìn)化過程中,有部分功能進(jìn)行了統(tǒng)一,但是并沒有達(dá)到完全的統(tǒng)一化管理。

不同的后臺(tái)系統(tǒng)采用不同的登錄形式、不同的結(jié)構(gòu)框架。沒有統(tǒng)一的入口,沒有標(biāo)準(zhǔn)的交互規(guī)范,操作日志和權(quán)限沒有統(tǒng)一管理。

造成了交互體驗(yàn)斷層,內(nèi)部使用效率低、管理混亂的局面。

所以,需要進(jìn)行大后臺(tái)的整合,以便達(dá)到體驗(yàn)、交互、管理上的一致性。

三、大后臺(tái)整合的目的是什么?

作為產(chǎn)品開發(fā)者和運(yùn)維者,你需要一個(gè)統(tǒng)一的大后臺(tái),對(duì)所有的產(chǎn)品進(jìn)行權(quán)限管理、角色設(shè)置和員工管理,并且統(tǒng)一記錄所有的操作日志。

  1. 統(tǒng)一登錄態(tài):一鍵登錄,可訪問有權(quán)限的所有產(chǎn)品和服務(wù),提升訪問和操作效率。
  2. 權(quán)限管理:將各個(gè)產(chǎn)品的后臺(tái)納入到大后臺(tái)進(jìn)行統(tǒng)一的管理,指定管理員,并設(shè)置該產(chǎn)品的角色,統(tǒng)計(jì)角色數(shù)量,可進(jìn)行自定義的設(shè)置。
  3. 角色管理:可靈活地為多個(gè)產(chǎn)品配置不同導(dǎo)航和操作權(quán)限,一個(gè)角色可設(shè)置多個(gè)員工賬號(hào)。
  4. 員工管理:每個(gè)員工賬號(hào)都通過內(nèi)部通訊工具實(shí)名認(rèn)證登錄,歸屬于某個(gè)(或多個(gè))角色,具有操作某個(gè)(或多個(gè))產(chǎn)品相關(guān)功能模塊的權(quán)限。某個(gè)員工賬號(hào)允許綁定多個(gè)角色。
  5. 日志管理:統(tǒng)一記錄所有產(chǎn)品、所有角色、所有員工的所有關(guān)鍵操作記錄。

除此之外,在產(chǎn)品表現(xiàn)層,還可以嘗試做到以下兩點(diǎn),來提升整體的產(chǎn)品調(diào)性。

1)打造統(tǒng)一的視覺交互UI,強(qiáng)化產(chǎn)品矩陣

  • 設(shè)計(jì)Logo
  • 創(chuàng)造Slogan
  • 設(shè)計(jì)“歡迎頁”
  • 統(tǒng)一頁面框架結(jié)構(gòu)
  • 統(tǒng)一UI視覺
  • 統(tǒng)一交互體驗(yàn)
  • 統(tǒng)一操作邏輯

2)傳播團(tuán)隊(duì)影響力

  • 產(chǎn)品介紹展示
  • 操作手冊(cè)下載
  • 團(tuán)隊(duì)風(fēng)采展示
  • 技術(shù)支持通道
  • 需求提報(bào)通道
  • 意見反饋通道

由此將產(chǎn)研團(tuán)隊(duì)的服務(wù)更好地傳遞給用戶,同時(shí)讓用戶的心聲能更好地反饋到產(chǎn)研團(tuán)隊(duì)。積極建立和用戶的緊密聯(lián)系,打通產(chǎn)研團(tuán)隊(duì)與用戶之間的溝通路徑。

我想,這大概就是大后臺(tái)提供的的超預(yù)期的用戶體驗(yàn)了。

四、何如進(jìn)行大后臺(tái)的規(guī)劃設(shè)計(jì)?

本文的權(quán)限管理模塊,采用RBAC權(quán)限模型。

RBAC:即基于角色的訪問控制(Role-Based Access Control),主要通過角色和權(quán)限建立管理,再賦予用戶不同的角色,或者角色下添加不同的用戶賬號(hào),來實(shí)現(xiàn)權(quán)限控制的目標(biāo)。

利用該模型來配置權(quán)限,直接優(yōu)點(diǎn)是角色的數(shù)量比用戶的數(shù)量更少,先把權(quán)限賦予角色,即可完成權(quán)限的分配。再為用戶分配相應(yīng)的角色,即可直接獲得角色擁有的權(quán)限。

在本文的大后臺(tái)產(chǎn)品中,權(quán)限顆粒度僅限于菜單維度,只需定義有限的角色擁有哪些菜單權(quán)限即可。

大后臺(tái)的產(chǎn)品構(gòu)架圖如下:

角色權(quán)限邏輯:

1. 統(tǒng)一登錄態(tài)

本文的統(tǒng)一登錄態(tài)是指登錄流程前置,在訪問產(chǎn)品前進(jìn)行登錄態(tài)的判斷。登錄后,根據(jù)角色定位有權(quán)限訪問的產(chǎn)品,并給出定制化的產(chǎn)品列表。

觸發(fā)登錄的兩種行為:

1)主動(dòng)觸發(fā)

用戶主動(dòng)點(diǎn)擊【登錄】按鈕,在未設(shè)置角色前提下,所有登錄大后臺(tái)的用戶均為“游客”角色,僅有查看首頁、相關(guān)信息頁面的權(quán)限,不能進(jìn)入后臺(tái)產(chǎn)品。

2)被動(dòng)觸發(fā)

用戶點(diǎn)擊產(chǎn)品入口,先判斷登錄態(tài),未登錄的需跳轉(zhuǎn)到登錄頁面。

2. 權(quán)限管理

本文的權(quán)限管理,指多個(gè)產(chǎn)品是否納入了權(quán)限管理的范疇,并對(duì)已有的產(chǎn)品進(jìn)行管理。被添加的產(chǎn)品或系統(tǒng),可被劃分權(quán)限,設(shè)置管理員,下設(shè)角色和員工賬戶。

該模塊主要的功能點(diǎn)包括:

  • 添加系統(tǒng)
  • 配置管理員
  • 系統(tǒng)名稱
  • 系統(tǒng)描述
  • 啟用/停用狀態(tài)設(shè)置
  • 二次編輯

在系統(tǒng)管轄權(quán)內(nèi)統(tǒng)計(jì)角色的數(shù)量,設(shè)置啟用和停用的狀態(tài),因?yàn)槟壳暗漠a(chǎn)品數(shù)量有限,暫時(shí)不設(shè)置翻頁組建和刪除功能。

3. 角色管理

角色是具有相同權(quán)限的賬戶的集合體。

該模塊主要的功能點(diǎn)包括:

  • 添加角色
  • 添加員工
  • 角色名稱
  • 角色描述
  • 啟用/停用狀態(tài)設(shè)置
  • 二次編輯

4. 員工管理

員工管理指的是登錄系統(tǒng)的獨(dú)立賬號(hào),被賦予一個(gè)或多個(gè)角色,享有一定的權(quán)限,可進(jìn)行相關(guān)的操作。

該模塊通過內(nèi)部IM工具登錄之后,自動(dòng)獲取其系統(tǒng)賬號(hào)、員工姓名、工號(hào)、注冊(cè)時(shí)間。

初次登錄屬于“游客”角色,需要管理員或者超級(jí)管理員賦予角色才能執(zhí)行操作。

員工賬號(hào)正常使用是屬于“已啟用”的狀態(tài),如果員工離職,賬號(hào)刪除、禁用、或者凍結(jié)等情況下,賬號(hào)切換到“已停用”狀態(tài)。

對(duì)于員工賬號(hào)支持角色的二次編輯,支持各類條件查詢等。

5. 日志中心

日志中心是對(duì)所有產(chǎn)品敏感性操作的記錄,支持匯總查看、按產(chǎn)品查看、按操作員查看、按操作時(shí)間查看等模式。

集中的日志管理,有助于系統(tǒng)管理者快速了解各個(gè)產(chǎn)品的使用情況,明確操作員的動(dòng)態(tài)。在遇到問題,發(fā)生風(fēng)險(xiǎn)的時(shí)候,可以回溯日志,定位操作節(jié)點(diǎn),鎖定相關(guān)人員。

考慮到服務(wù)器儲(chǔ)存壓力的問題,可設(shè)置日志最多儲(chǔ)存10000條,或者最多儲(chǔ)存3個(gè)月內(nèi)的數(shù)據(jù)。后續(xù)每多出一條數(shù)據(jù),循環(huán)刪除最早的一條數(shù)據(jù)。

如果條件允許,建議保留所有的歷史操作日志。

6. 打造統(tǒng)一的視覺交互UI,強(qiáng)化產(chǎn)品矩陣

大后臺(tái)的整合不僅僅需要體現(xiàn)在流程和功能上,還需要體現(xiàn)在視覺和交互上。所以,作者提出了打造統(tǒng)一的視覺交互UI,強(qiáng)化產(chǎn)品矩陣的設(shè)想。并通過需求方案的輸出,幫助設(shè)想落地實(shí)現(xiàn)。

設(shè)計(jì)Logo:

為每個(gè)產(chǎn)品設(shè)計(jì)一個(gè)獨(dú)特的、貼合產(chǎn)品調(diào)性的Logo,同時(shí)還要做到所有產(chǎn)品Logo有機(jī)整體的融合,視覺統(tǒng)一。

創(chuàng)造Slogan:

為每個(gè)產(chǎn)品創(chuàng)造一條簡(jiǎn)單易記、體現(xiàn)產(chǎn)品屬性和價(jià)值的Slogan,助力產(chǎn)品傳播和推廣。

設(shè)計(jì)“歡迎頁”:

為每個(gè)產(chǎn)品設(shè)計(jì)一款歡“迎頁面”,通過具有感染力的畫面,提升用戶體驗(yàn),傳播產(chǎn)品功能價(jià)值。

統(tǒng)一產(chǎn)品各級(jí)頁面呈現(xiàn)的框架結(jié)構(gòu)、UI視覺、交互體驗(yàn)、操作邏輯等。

  1. 頂部logo+產(chǎn)品名稱+slogan+登錄/退出入口
  2. 左側(cè)導(dǎo)航欄
  3. 右側(cè)大面積操作區(qū)域
  4. 新建按鈕在操作區(qū)域的左上角
  5. 查詢功能在列表上方
  6. 列表采用統(tǒng)一的組建
  7. 翻頁組建統(tǒng)一
  8. 彈窗交互和樣式統(tǒng)一
  9. 刪除等操作二次確認(rèn)
  10. 統(tǒng)一toast提示樣式和消失時(shí)間
  11. 同一類型按鈕采用相同的默認(rèn)色值、交互色值
  12. 同一類型的文本采用統(tǒng)一的字體/字號(hào)/字色
  13. 導(dǎo)航欄交互統(tǒng)一
  14. 說明性文案布局一致、采用統(tǒng)一的字體/字號(hào)/字色
  15. 增刪改查的操作保持統(tǒng)一的交互體驗(yàn)

局部UI需求表:

7. 傳播團(tuán)隊(duì)影響力

產(chǎn)品介紹展示:

  • 這個(gè)模塊是關(guān)于產(chǎn)品的介紹,圖文結(jié)合,主要內(nèi)容包括:產(chǎn)品的性質(zhì)、產(chǎn)品的功能、產(chǎn)品的合作伙伴、相關(guān)負(fù)責(zé)人、產(chǎn)品的一些關(guān)鍵數(shù)據(jù)指標(biāo)等。
  • 該模塊主要是靜態(tài)圖文的展示,需要設(shè)計(jì)師出方案稿。

操作手冊(cè)下載:

  • 提供相關(guān)產(chǎn)品的操作手冊(cè)的查看和下載。
  • 文檔格式建議PDF。

團(tuán)隊(duì)風(fēng)采展示:

圖片、文字、視屏等形式展示團(tuán)隊(duì)風(fēng)采,包括:團(tuán)隊(duì)成員、崗位介紹、能力展示、團(tuán)建活動(dòng)、團(tuán)隊(duì)合影等。

技術(shù)支持通道:

在使用產(chǎn)品的過程中,如遇到技術(shù)問題,請(qǐng)通過【XX】聯(lián)系我們的開發(fā)工程師。

  • 開發(fā)工程師1:姓名+工號(hào)+聯(lián)系方式
  • 開發(fā)工程師2:姓名+工號(hào)+聯(lián)系方式

如發(fā)現(xiàn)bug,請(qǐng)通過【XX】聯(lián)系我們的測(cè)試工程師。

  • 測(cè)試工程師1:姓名+工號(hào)+聯(lián)系方式
  • 測(cè)試工程師2:姓名+工號(hào)+聯(lián)系方式

需求提報(bào)通道:

  • 填寫《需求提報(bào)表》,提供表單鏈接,支持PC和手機(jī)端填寫,手機(jī)端填寫支持掃描二維碼打開。
  • 將需求描述作為郵件內(nèi)容,發(fā)送給 abcdefg(abcdefg@XX.com)并抄送給 hijklmn(hijklmn@XX.com),以及您需要周知的相關(guān)業(yè)務(wù)老師。

意見反饋:

在使用產(chǎn)品的過程中,如有什么好的建議和想法,歡迎反饋給我們,共同交流探討。

請(qǐng)通過【XX】聯(lián)系我們的產(chǎn)品經(jīng)理。

  • 產(chǎn)品經(jīng)理1:姓名+工號(hào)+聯(lián)系方式
  • 產(chǎn)品經(jīng)理2:姓名+工號(hào)+聯(lián)系方式

五、總結(jié)

以上內(nèi)容是作者搭建大后臺(tái)的初始版本的產(chǎn)品設(shè)計(jì)方案,主要聚焦在當(dāng)前產(chǎn)品需要整合的問題,最主要解決的是產(chǎn)品權(quán)限管理的問題。

相信,等整個(gè)大后臺(tái)概念落地,產(chǎn)品上線之后,后續(xù)的迭代會(huì)讓產(chǎn)品的體驗(yàn)更加美好、產(chǎn)品層次更加豐富、也會(huì)呈現(xiàn)更加多維度的內(nèi)容。

 

Echo小姐,公眾號(hào):產(chǎn)品經(jīng)理的邏輯與審美;擅長電商前后臺(tái)、知識(shí)付費(fèi)、營銷平臺(tái),懂用戶和運(yùn)營,產(chǎn)品sense良好、有同理心,擁有B端、C端豐富的產(chǎn)品經(jīng)歷,原創(chuàng)有8萬字的《一個(gè)產(chǎn)品人的邏輯與審美》作品文字圖集。

本文由 @Echo小姐的產(chǎn)品論 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

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

Echo小姐,公眾號(hào):產(chǎn)品經(jīng)理的邏輯與審美;擅長電商前后臺(tái)、知識(shí)付費(fèi)、營銷平臺(tái),懂用戶和運(yùn)營,擁有B端、C端豐富的產(chǎn)品經(jīng)歷。

本文由 @Echo小姐的產(chǎn)品論 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

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

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

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 學(xué)習(xí)了,感謝~

    來自上海 回復(fù)
  2. 請(qǐng)教小姐姐,這種單點(diǎn)登錄的大后天的數(shù)據(jù)權(quán)限的管理是由權(quán)限管理系統(tǒng)統(tǒng)一處理還是放在業(yè)務(wù)系統(tǒng)里進(jìn)行單獨(dú)處理

    來自北京 回復(fù)
  3. 干貨滿滿,想請(qǐng)問 一個(gè)運(yùn)維管理后臺(tái)如何把 公司內(nèi)部人員 和終端用戶 融在一個(gè)平臺(tái)里呢?還要滿足 終端用戶登錄運(yùn)維平臺(tái)后 還可以管理終端用戶的SaaS平臺(tái)?

    來自江蘇 回復(fù)
  4. 這里的添加系統(tǒng)功能,是如何同時(shí)做到數(shù)據(jù)層面的對(duì)接呢

    來自北京 回復(fù)
    1. 前后端約定1個(gè)規(guī)則就可以。這篇文章像是通過系統(tǒng)名稱

      來自廣東 回復(fù)
  5. 想咨詢一下,這個(gè)大后臺(tái)的操作日志是記錄了其他所有接入大后臺(tái)的業(yè)務(wù)系統(tǒng)的日志信息嗎
    為什么不分開,各自業(yè)務(wù)記各自呢

    來自北京 回復(fù)
    1. 日志數(shù)據(jù)統(tǒng)一進(jìn)行數(shù)據(jù)分析,各個(gè)業(yè)務(wù)系統(tǒng)的日志需要按大后臺(tái)的用戶賬號(hào)ID上報(bào),方便進(jìn)行登錄數(shù)據(jù)分析;各自業(yè)務(wù)記各自的,登錄數(shù)據(jù)賬號(hào)、身份對(duì)應(yīng),數(shù)據(jù)是割裂的

      來自江蘇 回復(fù)
    2. 1張表, 可以通過左上角的下拉表 選擇 各個(gè)系統(tǒng)的

      來自廣東 回復(fù)
  6. 點(diǎn)贊收藏加關(guān)注

    來自北京 回復(fù)
  7. 這才是真正實(shí)戰(zhàn)過產(chǎn)品能寫出來的實(shí)戰(zhàn)篇,贊了

    回復(fù)
  8. 想請(qǐng)問下非標(biāo)準(zhǔn)角色有什么好的授權(quán)辦法嗎,很多運(yùn)營同學(xué)做的事情比較雜,所需權(quán)限各不相同,很難通過一個(gè)或幾個(gè)角色把所需權(quán)限涵蓋住。

    曾經(jīng)做過針對(duì)單個(gè)用戶單獨(dú)授權(quán)的方式,但是回收梳理權(quán)限就比較困難。

    來自四川 回復(fù)
    1. 建議將運(yùn)營的要做的工作進(jìn)行分類,整合幾個(gè)通用的角色,然后進(jìn)行配置。

      來自北京 回復(fù)
  9. 我也在做類似的權(quán)限系統(tǒng),目前遇到的問題是,如何判斷一個(gè)角色可以管理多個(gè)系統(tǒng)比較合適,還是把角色歸屬到系統(tǒng)比較合適?

    來自廣東 回復(fù)
    1. 這個(gè)需要看系統(tǒng)之間的業(yè)務(wù)耦合度,如果很高,那是需要有一種凌駕在系統(tǒng)之上的角色,可以跨系統(tǒng)進(jìn)行操作,如果耦合度低,那就沒有必要。

      目前,我們的系統(tǒng)業(yè)務(wù)都是分開的,所以,角色的設(shè)定都是基于系統(tǒng)的。

      來自北京 回復(fù)
    2. 那為何不急于崗位上下級(jí)來規(guī)劃呢。跨區(qū)域,跨公司,跨部門,跨系統(tǒng)。

      來自陜西 回復(fù)
  10. 這樣權(quán)限只是到菜單欄級(jí),如果想設(shè)置功能級(jí)權(quán)限管理呢?

    來自陜西 回復(fù)
    1. 菜單不等于菜單欄。你做的時(shí)候可以顆粒度做到按鈕呀,這種框架很靈活,大部分系統(tǒng)都能用

      來自四川 回復(fù)
    2. 對(duì)的,因?yàn)槲覀兡壳皺?quán)限比較初級(jí),還不需要顆粒度太小,最主要的后臺(tái)的整合??梢愿鶕?jù)業(yè)務(wù)需要,做到頁面按鈕的增刪改查,還有數(shù)據(jù)權(quán)限、操作權(quán)限、閱讀權(quán)限等。

      來自北京 回復(fù)
  11. 這樣權(quán)限只是到菜單欄級(jí),如果想設(shè)置功能級(jí)權(quán)限管理呢。嘿嘿

    來自陜西 回復(fù)