交互設(shè)計(jì) | 先分解后聚合,“權(quán)限申請(qǐng)及審批”的產(chǎn)品閉環(huán)
在上一篇文章《復(fù)盤(pán) | B端產(chǎn)品中,如何構(gòu)建權(quán)限體系》中,筆者講解了:如何在RBAC模型基礎(chǔ)上構(gòu)建了一套“B端、數(shù)據(jù)、平臺(tái)”產(chǎn)品的權(quán)限體系——基于數(shù)據(jù)集合及角色的權(quán)限訪問(wèn)控制模型。那么,在該模型基礎(chǔ)上,如何針對(duì)“權(quán)限申請(qǐng)及審批”流程開(kāi)展交互設(shè)計(jì)?下文將詳細(xì)說(shuō)明。
在本項(xiàng)目中,產(chǎn)品團(tuán)隊(duì)從長(zhǎng)遠(yuǎn)考慮,決定將“權(quán)限申請(qǐng)及審批”功能在產(chǎn)品內(nèi)設(shè)計(jì)成一個(gè)完整的閉環(huán),該閉環(huán)主要包括“權(quán)限申請(qǐng)”及“權(quán)限審批”兩個(gè)流程,參與的角色有“申請(qǐng)者”、“審批者”及“系統(tǒng)”,各角色定義如下:
- “申請(qǐng)者”,負(fù)責(zé)發(fā)起權(quán)限申請(qǐng);
- “審批者”,負(fù)責(zé)審批權(quán)限申請(qǐng);
- “系統(tǒng)”,負(fù)責(zé)判斷業(yè)務(wù)邏輯和傳遞消息。
各角色之間的串聯(lián)關(guān)系為:申請(qǐng)者發(fā)起申請(qǐng)——系統(tǒng)尋找審批者——審批者進(jìn)行審批——系統(tǒng)傳遞審批結(jié)果給申請(qǐng)者。
據(jù)此,進(jìn)一步可以將“權(quán)限申請(qǐng)”及“權(quán)限審批”劃分為4個(gè)環(huán)節(jié):發(fā)起、流轉(zhuǎn)、審批、反饋。
一、權(quán)限申請(qǐng)的“發(fā)起”
定義“權(quán)限申請(qǐng)”的發(fā)起用戶(hù)為“申請(qǐng)者”,根據(jù)上一篇文章中構(gòu)建的“基于數(shù)據(jù)集合及角色的權(quán)限訪問(wèn)控制模型”,在本環(huán)節(jié),申請(qǐng)者只需要確認(rèn)兩個(gè)信息:數(shù)據(jù)集合、角色,然后提交權(quán)限申請(qǐng)即可。
- 數(shù)據(jù)集合:選擇需要開(kāi)通權(quán)限的產(chǎn)品,可以多選;
- 角色:選擇需要申請(qǐng)的角色,不同的角色代表不同的權(quán)限。
一般的申請(qǐng)者在發(fā)起一條權(quán)限申請(qǐng)的時(shí)候(只可以申請(qǐng)“普通用戶(hù)、產(chǎn)品管理員”兩種角色,“平臺(tái)管理員、超級(jí)管理員”則直接通過(guò)后臺(tái)配置),由于是使用內(nèi)部統(tǒng)一的登錄(使用工號(hào)),那么TA只需要在界面中確認(rèn)“數(shù)據(jù)集合”和“角色”兩個(gè)內(nèi)容,就可以完成權(quán)限申請(qǐng)的“發(fā)起”。
PS:為了保證能順利通過(guò)審核,增加“申請(qǐng)理由”作為必填項(xiàng)。
針對(duì)用戶(hù)需要申請(qǐng)權(quán)限的需求,這里有兩種場(chǎng)景需要討論:
1. 用戶(hù)沒(méi)有任何數(shù)據(jù)集合的權(quán)限,TA是首次申請(qǐng)
這種場(chǎng)景下,用戶(hù)登錄進(jìn)入產(chǎn)品之后,必然會(huì)面臨無(wú)任何數(shù)據(jù)的狀況,所以這個(gè)時(shí)候需要第一時(shí)間提供給他“申請(qǐng)權(quán)限”的入口。
2. 用戶(hù)已經(jīng)具備部分?jǐn)?shù)據(jù)集合的權(quán)限,TA需要繼續(xù)申請(qǐng)其他數(shù)據(jù)集合的權(quán)限
這種場(chǎng)景中,可以通過(guò)右上角賬號(hào)名稱(chēng)下的菜單,使用“申請(qǐng)權(quán)限”功能,這樣可以保證用戶(hù)使用產(chǎn)品的過(guò)程中,在不中斷當(dāng)前任務(wù)的前提下,可以隨時(shí)申請(qǐng)其他數(shù)據(jù)集合的權(quán)限。
二、權(quán)限申請(qǐng)的“流轉(zhuǎn)”
當(dāng)“申請(qǐng)者”發(fā)起一條權(quán)限申請(qǐng)的時(shí)候,該申請(qǐng)需要流轉(zhuǎn)至對(duì)應(yīng)的“審批者”——即權(quán)限申請(qǐng)的接收用戶(hù),這一過(guò)程由系統(tǒng)自動(dòng)完成。
那么,誰(shuí)是審批者?
這里就需要給系統(tǒng)定義權(quán)限申請(qǐng)的流轉(zhuǎn)規(guī)則:
- 當(dāng)用戶(hù)在一條“權(quán)限申請(qǐng)”中選擇了N個(gè)產(chǎn)品時(shí),系統(tǒng)需要將其拆分為N條申請(qǐng)消息并發(fā)送至對(duì)應(yīng)的審批者;
- 當(dāng)申請(qǐng)的數(shù)據(jù)集合存在產(chǎn)品管理員時(shí),該申請(qǐng)消息會(huì)發(fā)送給產(chǎn)品管理員、平臺(tái)管理員、超級(jí)管理員;
- 當(dāng)申請(qǐng)的數(shù)據(jù)集合沒(méi)有產(chǎn)品管理員時(shí),該申請(qǐng)消息會(huì)發(fā)送給平臺(tái)管理員、超級(jí)管理員;
- 當(dāng)沒(méi)有平臺(tái)管理員時(shí),該申請(qǐng)消息會(huì)發(fā)送給超級(jí)管理員(超級(jí)管理員必須存在)。
三、權(quán)限申請(qǐng)的“審批”
當(dāng)權(quán)限申請(qǐng)的消息順利流轉(zhuǎn)至對(duì)應(yīng)的審批者后,作為“審批者”的用戶(hù)會(huì)收到一條系統(tǒng)消息。
此時(shí),審批者可以對(duì)其進(jìn)行“審批”。
審批者可以在“消息”內(nèi)查看權(quán)限申請(qǐng)的詳細(xì)內(nèi)容,包括:申請(qǐng)者的姓名、工號(hào)、部門(mén)、申請(qǐng)產(chǎn)品、申請(qǐng)角色,以及申請(qǐng)理由。
根據(jù)申請(qǐng)內(nèi)容,審批者可以直接操作“通過(guò)”或者“駁回”。當(dāng)操作“通過(guò)”后——即表示:給申請(qǐng)者開(kāi)通對(duì)應(yīng)權(quán)限;當(dāng)操作“駁回”時(shí),需要給出“駁回理由”。
需要注意的是:根據(jù)流轉(zhuǎn)規(guī)則,同一條申請(qǐng)消息會(huì)存在多個(gè)接收者,也就是會(huì)有多個(gè)“審批者”同時(shí)收到相同的權(quán)限申請(qǐng)消息。
針對(duì)這種情況,規(guī)定:當(dāng)?shù)谝粋€(gè)“審批者”操作后,無(wú)論是“通過(guò)”還是“駁回”,此條申請(qǐng)消息由“待審批”的狀態(tài)變更為“已審批”,其他審批者的操作功能隨即失效。
四、審批結(jié)果的“反饋”
當(dāng)審批者完成一條權(quán)限申請(qǐng)的審批后,系統(tǒng)會(huì)將此條權(quán)限申請(qǐng)的結(jié)果返回給相應(yīng)的“申請(qǐng)者”。這時(shí),作為“申請(qǐng)者”的用戶(hù)會(huì)收到一條系統(tǒng)消息。
申請(qǐng)者可以在“消息”內(nèi)查看權(quán)限申請(qǐng)的結(jié)果:
- 如果權(quán)限申請(qǐng)已通過(guò),會(huì)告知申請(qǐng)者審批者的姓名、工號(hào),以及審批的時(shí)間;
- 如果權(quán)限申請(qǐng)被駁回,會(huì)額外告知駁回理由;
- 如果用戶(hù)存在異議,可以通過(guò)工號(hào)使用其他通訊方式聯(lián)系審批者,并與TA溝通。
至此,在產(chǎn)品內(nèi)形成了“權(quán)限申請(qǐng)及審批”的完整閉環(huán)。
五、總結(jié)
在本項(xiàng)目中,通過(guò)“權(quán)限申請(qǐng)及審批”的產(chǎn)品閉環(huán)設(shè)計(jì),為用戶(hù)提供了一站式的服務(wù)體驗(yàn),作為交互設(shè)計(jì)師,采取的策略可以用6個(gè)字總結(jié):“先分解、后聚合”
- 明確各環(huán)節(jié)的對(duì)象以及TA所面臨的任務(wù);
- 針對(duì)各環(huán)節(jié)的任務(wù)展開(kāi)分析,將任務(wù)拆解為一套流程;
- 根據(jù)各環(huán)節(jié)的對(duì)象和任務(wù),在產(chǎn)品內(nèi)找出用戶(hù)觸點(diǎn),并以此開(kāi)展交互設(shè)計(jì);
- 將所有環(huán)節(jié)進(jìn)行聚合,形成完成的閉環(huán)設(shè)計(jì)方案。
作者:胡欣欣,公眾號(hào):吹拉彈唱大師(ID:cltcds)
本文由@吹拉彈唱大師 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來(lái)自Unsplash, 基于CC0協(xié)議
大佬,審批者那個(gè)地方加一個(gè)先后順序會(huì)不會(huì)權(quán)責(zé)更清晰,另外不用每一個(gè)申請(qǐng)都要給平臺(tái)管理員吧,是不是可以中間角色審批即可
厲害啊 就是要看到這樣的關(guān)于權(quán)限論述的文章 收藏了
案例+拆解式的分享。辛苦作者。產(chǎn)品的前端交互效果,以怎樣的形式對(duì)接設(shè)計(jì)及開(kāi)發(fā)人員效果更好呢
我給開(kāi)發(fā)澄清需求的時(shí)候,首先會(huì)按照流程圖講解一遍,讓開(kāi)發(fā)理解產(chǎn)品設(shè)計(jì)的思路,然后再結(jié)合交互稿講解,什么環(huán)節(jié)需要什么數(shù)據(jù)、哪些接口。