權限作為一個底層的功能，不僅要考慮用戶的實際應用場景，合理劃分以適用于不同的角色，還要將其轉(zhuǎn)變?yōu)橄到y(tǒng)的語言。我們表面上看簡單的勾選就能達到分權限的目的，但實際上開發(fā)在實現(xiàn)的時候沒那么簡單。

我們都知道，B端用戶不是一個個體，是由一群個體構(gòu)成的組織，那這個組織里面就有不同的崗位，不同的角色，比如說財務、運營、倉庫管理員等等。老板作為最高管理者，擁有所有的操作權，但下面的員工，不可能把所有操作權都開放給他。所以權限就應運而生，這也是B端產(chǎn)品中不得不做的一個功能。

權限作為一個底層的功能，不僅要考慮用戶的實際應用場景，合理劃分以適用于不同的角色，還要將其轉(zhuǎn)變?yōu)橄到y(tǒng)的語言。我們表面上看簡單的勾選就能達到分權限的目的，但實際上開發(fā)在實現(xiàn)的時候沒那么簡單。

作為產(chǎn)品經(jīng)理，前期的規(guī)劃很重要。

權限的應用

我們先來看看權限在哪些地方應用到，這幾個大家應該都不陌生。

1. 版本拆分

從銷售層面，我們經(jīng)?？吹?，B端產(chǎn)品會分成基礎版，專業(yè)版等2-3個版本，每個版本包含的功能不同，價格也不同。但我們不可能去開發(fā)3個產(chǎn)品，肯定是開發(fā)一套最全的版本，然后通過權限去控制功能模塊，拆分出不同的版本來。這樣既節(jié)省了開發(fā)成本，也能實現(xiàn)分級銷售的目的。

2. 子賬號管理

這是針對B端用戶內(nèi)部的賬號管理。B端用戶在購買系統(tǒng)后，會默認開通一個超級管理員的賬號，即擁有所有功能的操作權限，管理員會給下面的員工創(chuàng)建不同的子賬號。

比如這是淘寶賣家子賬號的設置流程，一些系統(tǒng)可能沒有部門結(jié)構(gòu)和分流設置，但是添加員工和修改崗位權限是一定會有的，而且這2個功能是相輔相成的，會同時出現(xiàn)。

為什么不合并成一個功能呢，在創(chuàng)建子賬號的時候就直接勾選操作權限？試想，如果創(chuàng)建的子賬號數(shù)量很多的時候，是不是選擇角色會更簡單一點？而且從系統(tǒng)上來說，這就是2個獨立的模塊，要解耦合。

3. 角色管理

這里我們可以看到具體詳細的權限點，系統(tǒng)一般會把角色分成2部分，內(nèi)置角色和自定義角色。

3.1 內(nèi)置角色

比如上圖淘寶賣家的內(nèi)置角色，系統(tǒng)已經(jīng)根據(jù)商家的特征，分好了客服、運營、美工、財務等常用角色。這些權限都是不可以修改的。對于一般的商家來說，直接使用內(nèi)置角色就可以很好地給員工進行權限劃分了。不僅操作方便，也能給那些不會設置的用戶做了個示例。

3.2 自定義角色

如果內(nèi)置角色不能滿足使用，可以自定義角色，可以導入內(nèi)置角色，在這基礎上進行修改，一般都是采用勾選的方式來控制。

權限的設計

我們看上面的圖，也能發(fā)現(xiàn)權限點的控制不是單一的維度，有交易管理、物流管理這種大模塊，也有導出訂單、查看詳情這種小按鈕。

總的來說，權限點的控制會體現(xiàn)在這些方面：模塊權限，頁面權限，操作權限，字段權限，賬號權限。

下面一一來看：

1. 模塊權限

我們看到的權限樹中的一級菜單，就是屬于模塊級的，版本拆分就是通過模塊權限來控制的，不會再往下細分。

一般來說，模塊權限和系統(tǒng)里面的一、二級功能菜單會對應起來。比如下圖權限的一級菜單就是導航欄的一級菜單。

我們也可能看到，模塊權限點并不在菜單里面，而是藏在系統(tǒng)里的一個比較重要的功能點。

為什么會把他拎出來呢？顯得格格不入。

可能是用來拆分版本的重要功能，可能是多個地方共同控制的提煉，也可能是用戶很關心的點，方便尋找。所以這塊權限提煉會相對復雜一點。

2.?頁面權限

模塊下一級的權限，就是頁面權限了，頁面權限是用的最多的。一般來說，重要頁面都是有一個權限點的，直接控制這個頁面顯示或者不顯示。

頁面權限的設置只需到進入功能的首頁即可，通?？赡苁橇斜眄摚热缯f訂單列表，商品列表。詳情頁不屬于頁面權限，因為他是在首頁上操作后才進入的，屬于按鈕/操作權限了。

3. 操作權限

操作權限最多的體現(xiàn)是按鈕權限，通過點擊等操作來執(zhí)行業(yè)務，最常見的就是增、刪、改、查、審核。

這也是用的很多的，我們在設置權限的時候，會看到他們和頁面權限放在一起，放在模塊權限的下面。

4. 字段權限

字段權限是更細的權限點了，控制這個字段是否可被看到，一般是用來控制頁面上的敏感信息的，比如說成本價、供應商信息等。

這個權限用的相對少一點，有的系統(tǒng)會把這個權限點直接做到系統(tǒng)的配置項里面。

5. 賬號權限

這個權限用戶可能感知不到，他沒有放在權限列表中可被勾選。是根據(jù)業(yè)務的屬性做了強行過濾，只能當前賬號查看自己的信息。一般來說這種用的不是很多。

比如說醫(yī)生門診系統(tǒng)，醫(yī)生登錄系統(tǒng)，只能看自己接診的患者，不能看到其他醫(yī)生的，也不能對其他醫(yī)生的病歷、處方等進行修改。這也是為了避免責任糾紛。

還有業(yè)績提成統(tǒng)計報表中也可能會用到，員工可以查看自己的業(yè)績，預算本月工資，但不能看到別人的。

權限設計中的注意事項

雖然權限主要是上面5個層面的劃分，看似挺簡單的，但實際上在設計的時候，還會有不少的坑，下面這些注意事項一定要注意了哦！

1. 權限點不是越多越好

權限的目的是給不同的人員分工，把這個人用不到的功能模塊隱藏掉，或者根據(jù)職位的高低，分配流程上的權限等。所以要根據(jù)B端業(yè)務來定，不要把每個頁面、每個按鈕都設置上權限。既增加了工作量，也不利于用戶選擇。

2. 提煉同權限點

有時候一個功能會在系統(tǒng)的好幾個功能模塊和頁面中被用到。如果需要統(tǒng)一控制的話，就把這個功能點提煉出來，作為一個一級權限點。這樣用戶在選擇的時候就能知道，這是一個全局的控制。如果放在某個模塊下面，他們可以會誤以為只控制這個模塊下的內(nèi)容。

比如說診療系統(tǒng)中，快速接診和轉(zhuǎn)診的功能，在醫(yī)生門診、病人庫中都會用到，我們就把他們提煉了出來。

這里面還需注意一個點，開發(fā)在做權限控制的時候，往往會把相同的功能點一起做控制。但有時候我們不需要做全局控制，就一定要在文檔上注明，這個頁面上所有功能都可被使用，不受其他權限點影響。

3. 注意權限點間的相互影響

我們看到一般情況下，有操作權限、字段權限和賬號權限的前提是要有頁面權限，而有頁面權限的前提是要有模塊權限。我們必須要告訴用戶，權限之間有哪些關聯(lián)影響。否則用戶只勾選了操作權限，但是找不到按鈕在哪，以為出bug了呢。

其實上面說的，開發(fā)把同功能的權限設置為一個也是權限點間相互影響的一個考慮點，是否有關系，是否需要這種關系，產(chǎn)品經(jīng)理都要告訴開發(fā)和用戶。

4. 前端權限展示便于用戶理解

開發(fā)在做的時候更多考慮的是后臺的設計，所以不能直接把開發(fā)的結(jié)構(gòu)表展示給用戶。我們要按照系統(tǒng)模塊、頁面的順序，來排列好，這樣用戶就能理解，某個權限點具體控制的是哪一項了。

我們看這個權限就比較亂，不知道具體控制的是哪一個頁面上的哪一個點。

這個頁面的展示就很直觀，很容易理解。

5. 不要輕易變更權限

最后再強調(diào)一個很重要很重要的點，不要輕易變更權限，因為牽一發(fā)而動全身。我們看似只是把一級權限點挪了個位置，變成了二級，或者把二級提成了一級。但這些改動都會涉及到底層，一不小心就出bug了。

如果給一個新系統(tǒng)從0開始設計權限體系，一定要把系統(tǒng)的結(jié)構(gòu)框架定下來，最后再去做權限。如果想到哪做到哪，最后重做的概率很大。

總結(jié)

權限不像業(yè)務功能那么顯眼，就是背后默默支撐的功能，但B端產(chǎn)品卻必不可少。

本文分享了權限設計的邏輯和需注意的坑，希望大家在設計權限時，多留個心眼，多思考一點，一定成型，不要來回改動。

如果怕以后做這個功能時找不到這文章了，先收藏下哦！

#專欄作家#

司馬特小隊，公眾號：司馬特小分隊，人人都是產(chǎn)品經(jīng)理專欄作家。8年+互聯(lián)網(wǎng)資深產(chǎn)品經(jīng)驗，多年B端產(chǎn)品管理經(jīng)驗。具有多個從0到1的大型B端產(chǎn)品的孵化、重構(gòu)、迭代經(jīng)驗；主要教授產(chǎn)業(yè)互聯(lián)網(wǎng)產(chǎn)品相關的硬核知識點。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

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