B端產(chǎn)品經(jīng)理要掌握的3項硬核基本功

66 評論 18633 瀏覽 273 收藏 12 分鐘

本文將介紹B端產(chǎn)品經(jīng)理應(yīng)關(guān)注的最硬核三項基本功——賬號體系設(shè)計、權(quán)限管理設(shè)計、導(dǎo)航體系設(shè)計。

做B端產(chǎn)品經(jīng)理也很久了,也見識過很多產(chǎn)品和產(chǎn)品經(jīng)理,似乎沒有人談及一些產(chǎn)品經(jīng)理應(yīng)當(dāng)扎實掌握的基本功,而這些對于每一個產(chǎn)品經(jīng)理都是至關(guān)重要的。舉個不恰當(dāng)?shù)睦樱@些基本功就像一個人的內(nèi)褲,你可能不太好意思拿出來說你有,但總歸是要用到的。

本文將介紹B端產(chǎn)品經(jīng)理應(yīng)關(guān)注的最硬核三項基本功——賬號體系設(shè)計、權(quán)限管理設(shè)計、導(dǎo)航體系設(shè)計。每一個模塊其實都可以單獨拿出來大做文章,但礙于篇幅,只能在此拋個引子,如感興趣,可在評論區(qū)深入探討。

一、賬號體系設(shè)計

對于普通用戶,賬號體系的可能被簡單理解為登錄,但做過B端產(chǎn)品的都清楚,賬號體系建設(shè)是一項復(fù)雜的系統(tǒng)工程。

賬號體系一般分為賬號、角色、權(quán)限三部分,所謂賬號體系設(shè)計,本質(zhì)上是要設(shè)計賬號、角色與權(quán)限三者之間的聯(lián)系,但因為權(quán)限管理非常的復(fù)雜,所以單獨拿到下一部分來說。

B端產(chǎn)品經(jīng)理要掌握的硬核基本功

賬號設(shè)計中的用戶體驗五要素

首先,我們先談賬號設(shè)計,參照上圖,我們根據(jù)用戶體驗五要素來分別說下賬號設(shè)計中要做哪些事情。

戰(zhàn)略層首先要明確我們的定位、目標(biāo)、用戶,搞清楚戰(zhàn)略才能夠知道產(chǎn)品是封閉的還是開放的。比如我之前做的一個企業(yè)內(nèi)部的saas框架,讓集團各個公司的辦公saas都接入進去,這種產(chǎn)品的定位必然是開放的,在接下來的產(chǎn)品設(shè)計中肯定要考慮開放更多接口,做足數(shù)據(jù)保密工作等。

范圍層考慮的是我們需要哪些功能,實現(xiàn)什么效果。賬號設(shè)計中,范圍層一般有三部分需要重點關(guān)注,分別是登錄、退出、密碼找回。這里面會涉及到賬號的第三方關(guān)聯(lián),賬號密碼的加密方式,找回密碼的方式等。值得一提的是,如果你們是做一個開放平臺,未來可能會嵌入其他的產(chǎn)品,建議提前做好單點登錄的接口,免得后續(xù)改造起來很麻煩。

結(jié)構(gòu)層更多的是考慮信息架構(gòu)。在賬號設(shè)計中,需要呈現(xiàn)給用戶的信息主要分為用戶協(xié)議、保密協(xié)議、公告、賬號信息等。這個看上去簡單,但是落地還是比較困難,在系統(tǒng)開發(fā)階段,需要做一個非常合理的數(shù)據(jù)庫設(shè)計,否則用戶增多后,將會有無盡的麻煩。

框架層就是對界面的信息及布局設(shè)計。這里應(yīng)當(dāng)有操作指引、操作提示、登錄流程等方面的考慮。

最后就是表現(xiàn)層??筛鶕?jù)市場需求、產(chǎn)品定位來決定登錄頁的靜態(tài)或動態(tài),是否需要廣告位,如果有廣告位,登錄框應(yīng)該靠右,沒有的話就要居中……

B端產(chǎn)品經(jīng)理要掌握的硬核基本功

角色分類

接下來簡單談?wù)劷巧?。角色可看做是一個個權(quán)限組,角色設(shè)計是B端賬號設(shè)計中非常重要的一環(huán),由于業(yè)務(wù)特殊性,B端用戶勢必有很多層級,每個層級所需要看的內(nèi)容不盡相同,就需要一個符合業(yè)務(wù)的角色體系。

一般的角色有三種設(shè)計方式——根據(jù)崗位、根據(jù)職責(zé)、個性化。

  • 根據(jù)崗位是指用戶本身的崗位就是自己的角色,上級要擁有下級全部權(quán)限,這種設(shè)計多用于銷售相關(guān)產(chǎn)品。
  • 根據(jù)職責(zé)是指以用戶使用這個系統(tǒng)的目的來確定角色,比如超級管理員、分級管理員等,這種設(shè)計比較常見,一個普通員工的權(quán)限可能比公司CEO的權(quán)限范圍都大。
  • 最后一種是個性化角色設(shè)計,一個賬戶開通后,僅具有一般權(quán)限,需要什么權(quán)限可在后續(xù)找相關(guān)負(fù)責(zé)人申請,此種設(shè)計常見于需求頻繁變動的企業(yè)內(nèi)部,且維護成本比較高,對于一般的B端產(chǎn)品,不建議直接采用此種設(shè)計。

由于B端用戶的需求通常比較復(fù)雜,所以在實際的產(chǎn)品設(shè)計中,這三種方式往往混搭出現(xiàn),以充分滿足用戶需求。

二、權(quán)限管理設(shè)計

在探討這個模塊之前,我要發(fā)出一個靈魂拷問:為什么需要權(quán)限管理?

理由很簡單——為了更好的協(xié)作。從本質(zhì)上來講,所有權(quán)限管理產(chǎn)品,都屬于B端產(chǎn)品,涉及到很多不同的人的參與,不同的人需要看的東西不一樣,不同的人需要進行操作不一樣,不同的人對風(fēng)險把控的能力不一樣,為了降低風(fēng)險,增加效率,才需要權(quán)限控制。

權(quán)限管理一直以來都是讓產(chǎn)品經(jīng)理頭疼的事情,作為一個B端產(chǎn)品經(jīng)理,我們應(yīng)該知道一個共識——B端的需求復(fù)雜,目前還沒有一個針對權(quán)限管理的完美的解決方案,權(quán)限管理的設(shè)計過程其實是一個不斷取舍的過程。

B端產(chǎn)品經(jīng)理要掌握的硬核基本功

權(quán)限管理的RABC模型

現(xiàn)階段比較通用且比較成熟的權(quán)限管控模型是RBAC(Role-Based Access Control)——基于角色的訪問控制。簡單來說,就是權(quán)限授予角色,角色賦給賬號,角色可視為權(quán)限的集合,賬號就是角色的集合,彼此為多對多關(guān)系。賬號和權(quán)限在上面已經(jīng)提到,且網(wǎng)上很多關(guān)于RBAC的資料可以查閱,所以這里不重點闡述,我想重點說明的是在權(quán)限管理設(shè)計時應(yīng)當(dāng)注意的一些問題。

(1)數(shù)據(jù)權(quán)限與功能權(quán)限分開

見過一些B端產(chǎn)品,將數(shù)據(jù)權(quán)限與功能權(quán)限綁定在一起,可見即可得。在產(chǎn)品起步階段,這樣的設(shè)計會減少維護成本和學(xué)習(xí)成本,但是當(dāng)產(chǎn)品用戶量提升或遭遇大客戶時,便會顯得力不從心。這個時候可能需要重新設(shè)計產(chǎn)品,將數(shù)據(jù)權(quán)限和功能權(quán)限剝離,這樣很耗費資源,還不如一開始就做到位。

(2)角色不要與組織強掛鉤

部分B端產(chǎn)品會采用將角色掛靠到組織下的方式,這種方式的好處是角色和賬號可一并管控,且可以無限細(xì)分管理下級,擴展性很強。但是對于一個商業(yè)產(chǎn)品來說,非常不推薦這種形式,因為目前很多公司的組織架構(gòu)并不穩(wěn)定,甚至有的公司每個月都要大調(diào)整,角色與組織強掛鉤無異于飲鴆止渴。

(3)留有余地,為某些特殊需求做準(zhǔn)備

每一個B端產(chǎn)品經(jīng)理都知道,B端的需求是非常復(fù)雜的,所以在設(shè)計權(quán)限管理時,要為一些特殊需求做準(zhǔn)備,留有可自由配置任何權(quán)限組合的通道,以免需求到來,措手不及。

三、導(dǎo)航體系設(shè)計

相比于直接搜索,用戶更喜歡用導(dǎo)航,因為導(dǎo)航是讓用戶做選擇題,而搜索是填空題。

這句話我忘記了是從哪聽說的,但每次談到B端產(chǎn)品,我都會想到這句話。對于B端產(chǎn)品來說,用戶學(xué)習(xí)成本高,完全做不到像百度一樣直接放個搜索框,導(dǎo)航是一個B端產(chǎn)品經(jīng)理傳遞給用戶最溫暖的話語。

導(dǎo)航的作用有兩個——“我們有什么”以及“你在哪”。

“我們有什么”意思是要有一個清晰的導(dǎo)航架構(gòu)及標(biāo)簽體系。這就要求在設(shè)計產(chǎn)品時對各頁面及子頁面做好清晰的規(guī)劃,保持結(jié)構(gòu)的連貫性和一致性。同時導(dǎo)航務(wù)必采用容易理解的交互方式,不要做太多“炫技”式交互。

導(dǎo)航的形式也要根據(jù)實際情況做充分的考慮,主流的導(dǎo)航形式有三種——頂部導(dǎo)航、側(cè)邊導(dǎo)航、混合導(dǎo)航,其中混合導(dǎo)航是頂部導(dǎo)航和側(cè)邊導(dǎo)航共存的混合形式,多用于頁面結(jié)構(gòu)復(fù)雜的產(chǎn)品。目前導(dǎo)航設(shè)計比較好的產(chǎn)品有阿里云官網(wǎng),有機會可以單獨寫一篇文章來分析阿里云官網(wǎng)。

B端產(chǎn)品經(jīng)理要掌握的硬核基本功

阿里云官網(wǎng)導(dǎo)航

“你在哪”其實就是告訴用戶現(xiàn)在的處于哪一個頁面的哪一個位置。常見的處理方式是在導(dǎo)航中做標(biāo)注,用戶所處的位置做區(qū)別處理。另一種常用的處理方式是面包屑導(dǎo)航,每一級都做標(biāo)注,且每一級都可以點擊,電商網(wǎng)站常使用面包屑導(dǎo)航。

B端產(chǎn)品經(jīng)理要掌握的硬核基本功

有贊微商城中對用戶位置的展示

B端產(chǎn)品經(jīng)理要掌握的硬核基本功

京東商城中的面包屑導(dǎo)航設(shè)計

以上就是我對B端產(chǎn)品經(jīng)理最硬核的三項基本功——賬號、權(quán)限、導(dǎo)航的闡述,還是那句話,基本功就像內(nèi)褲,你可能不太好意思拿出來說你有,但總歸是要用到的。如果有問題,歡迎在評論區(qū)與我溝通。

私以為,每一個產(chǎn)品經(jīng)理都必須穿一條好內(nèi)褲。

 

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

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 你好,功能權(quán)限和數(shù)據(jù)權(quán)限,我的理解就是,比如有一個實驗記錄這個功能,記錄各種實驗方案數(shù)據(jù),功能權(quán)限:就是實驗人員可以使用實驗記錄這個功能,但I(xiàn)T人員不能使用,數(shù)據(jù)權(quán)限就是:創(chuàng)建實驗和參與實驗的人可以看到這個實驗記錄,沒參與的這個實驗的實驗也可以使用實驗記錄這個功能,但沒參與這個實驗的人員不能查看這個這個數(shù)據(jù),是這么理解嗎,我感覺有點別扭

    來自江蘇 回復(fù)
    1. 是的,一橫一縱。兄弟最近在做實驗記錄功能吧

      來自重慶 回復(fù)
    2. 是啊,樓主也在做嗎

      來自江蘇 回復(fù)
    3. 沒有

      來自重慶 回復(fù)
  2. 有點淺,不過真是基本功

    來自廣東 回復(fù)
  3. 您好,對于您的文章,我有兩處疑問,希望您指點;
    1.數(shù)據(jù)權(quán)限和功能權(quán)限分開:我是不是可以理解為比如財務(wù)角色查看訂單管理場景,僅讓財務(wù)角色在訂單管理下看到“已支付”狀態(tài)的訂單,這樣系統(tǒng)每次訪問服務(wù)器時就會只調(diào)取已支付的訂單,我這個理解算不算是數(shù)據(jù)權(quán)限與功能權(quán)限分開的?

    2.角色不要與組織強掛鉤:是不是可以理解為一個角色可以所屬一個或多個組織,但調(diào)整組織架構(gòu)時,該組織下的角色不受影響,并且該角色不管調(diào)整到那個組織,他的權(quán)限都不變呢?
    之前沒接觸過B端,希望您指正。

    來自北京 回復(fù)
    1. 第一個問題:功能權(quán)限是讓用戶有權(quán)限使用這個功能,而數(shù)據(jù)權(quán)限就是決定用戶在使用這個功能時能看到哪些數(shù)據(jù)。比如你說的這個場景,財務(wù)和運營都有看到訂單列表的權(quán)限,這是功能,而財務(wù)只能看到已支付類的訂單,而運營能看到所有的訂單,這是數(shù)據(jù)權(quán)限。再比如總裁和大區(qū)總都能看到銷售數(shù)據(jù),用著同一個功能,而總裁能看到全國的,大區(qū)總只能看到他管轄的區(qū)域的,這也是數(shù)據(jù)和功能權(quán)限分開的案例。
      第二個問題,如果角色屬于組織,很難做到調(diào)整組織時角色不受影響,建議是角色和組織只做關(guān)聯(lián),組織調(diào)整只會影響到該組織下的人,而不會影響其他人。有的角色甚至不和組織掛鉤,只和人員掛鉤,不管組織怎么變,人員的權(quán)限都不受影響。

      來自重慶 回復(fù)
    2. 感謝您的幫助。

      來自北京 回復(fù)
    3. 可以持續(xù)關(guān)注我的公眾號,感謝支持

      來自重慶 回復(fù)
  4. 轉(zhuǎn)B端產(chǎn)品 有哪些方法?

    來自四川 回復(fù)
  5. 最近遇到數(shù)據(jù)權(quán)限和功能權(quán)限設(shè)計問題,一直沒想透徹,不知您是否有經(jīng)驗可介紹?

    來自安徽 回復(fù)
    1. 可以關(guān)注我的公眾號,有時間會寫這個

      來自重慶 回復(fù)
  6. 憾宇最流弊

    回復(fù)
    1. 桃哥啥時候也來謝謝UI啊

      回復(fù)
    2. 寫寫

      回復(fù)
  7. 感覺例子舉的很恰當(dāng)

    來自上海 回復(fù)
    1. 謝謝

      回復(fù)
  8. 贊一個,不知道筆者是那個行業(yè)的,可以多交流 ??

    來自陜西 回復(fù)
    1. 前不知名信息化產(chǎn)品經(jīng)理,現(xiàn)智能CRM產(chǎn)品小白

      回復(fù)
  9. 相比于直接搜索,用戶更喜歡用導(dǎo)航,因為導(dǎo)航是讓用戶做選擇題,而搜索是填空題。雖然不知道這個結(jié)論是從什么數(shù)據(jù)總結(jié)出來,總的來說這個觀點其實不一定,我以前就是常常會用到阿里云,對我來說阿里云的導(dǎo)航太復(fù)雜,因為系統(tǒng)過于龐大,導(dǎo)致找一些功能模塊,翻來翻去,到最后,還不如一個搜索,把功能搜索出來

    來自廣東 回復(fù)
    1. 是的,這句話并不是說完全摒棄搜索,而是說,對于B端產(chǎn)品來說,一個清晰的導(dǎo)航,比搜索重要的多。讓我們這樣想,你是一個第一次接觸阿里云的,并不是對功能了如指掌的老司機,你是更需要導(dǎo)航還是搜索。office發(fā)展到2016才設(shè)置了一個搜索,其實也是一個道理,搜索在B端只能是輔助,而不像C端是主搜。

      來自重慶 回復(fù)
  10. 請問下什么情況下需要將數(shù)據(jù)權(quán)限和功能權(quán)限分開呢,可以舉例說明下嗎?謝謝作者哈哈哈 我已經(jīng)關(guān)注了你的公眾號

    來自四川 回復(fù)
    1. 一般情況下,做權(quán)限系統(tǒng)都建議把數(shù)據(jù)權(quán)限和功能權(quán)限分開。比如一個CRM系統(tǒng)的團隊數(shù)據(jù)統(tǒng)計,功能權(quán)限應(yīng)該只開給管理者,普通銷售是沒有這個功能權(quán)限的。但是不同的管理者,可以看到的數(shù)據(jù)是不一致的,ceo需要看到全國的,分公司總經(jīng)理只能看到特定地區(qū)的。

      來自重慶 回復(fù)
    2. 對于B端產(chǎn)品這個具體還是要看客戶需求,數(shù)據(jù)權(quán)限顧名思義,誰可以看到那部分?jǐn)?shù)據(jù),誰不可以看到哪部分?jǐn)?shù)據(jù),配好用戶角色,根據(jù)用戶角色進行數(shù)據(jù)權(quán)限劃分;而功能權(quán)限就是菜單權(quán)限了,一般情況下,我們配置好所有菜單開關(guān),由admin去設(shè)置用戶的菜單使用權(quán)限了。一般系統(tǒng)設(shè)計,數(shù)據(jù)權(quán)限和菜單權(quán)限是兩個獨立的,就如同作者的例子,或者,一個OA系統(tǒng)中,領(lǐng)導(dǎo)可能會看到一些統(tǒng)計數(shù)據(jù),但是不必進行一些功能操作,而員工沒有權(quán)限看統(tǒng)計數(shù)據(jù),但是可以進行流程申請等操作。

      來自陜西 回復(fù)
    3. 詳細(xì)清楚!謝謝! ??

      來自廣東 回復(fù)
  11. 期待作者大大的權(quán)限篇 :mrgreen:

    來自浙江 回復(fù)
    1. 謝謝,會有的

      來自重慶 回復(fù)
  12. 個性化配置對于一個組織架構(gòu)變動頻繁的組織來說,可能是基于角色、組織配置權(quán)限的基礎(chǔ)上,最佳解決方案了吧

    來自重慶 回復(fù)
    1. 頻繁變動的組織架構(gòu),我稱之為動態(tài)組織架構(gòu),哈哈哈哈哈

      來自重慶 回復(fù)
    2. 擁抱變化。

      來自重慶 回復(fù)
    3. 我們要擁抱有意義的變化

      來自重慶 回復(fù)
  13. 坐等作者的權(quán)限篇!

    來自北京 回復(fù)
    1. 哈哈,可以關(guān)注我的公眾號,才開始搭建,準(zhǔn)備最近寫點干貨

      來自重慶 回復(fù)
  14. 小白感激不盡

    回復(fù)
  15. 感謝,有些以前沒明白的東西豁然開朗

    回復(fù)
  16. 寫得很棒,受益匪淺

    來自四川 回復(fù)
    1. 這個說的都比較淺,往深了說的話,可以說得太多了

      來自重慶 回復(fù)
    2. 是的,但是淺層的我們理解了,你下次寫深入的文章,那么我們也就明白了

      來自四川 回復(fù)
  17. 賬號權(quán)限頭大……感謝分享!

    來自湖北 回復(fù)
    1. 權(quán)限管理目前還沒有一個完美的方案,只能多踩坑,多總結(jié)

      來自重慶 回復(fù)
  18. 嗯,大佬可不可以寫一寫B(tài)端系統(tǒng)跟系統(tǒng)之間對接需要學(xué)習(xí)的一些知識,感謝!??!

    來自北京 回復(fù)
    1. 之前做過B端框架產(chǎn)品,可以理解為承載各個系統(tǒng)接入的容器,有機會可以寫一寫,有興趣可以關(guān)注我公眾號喲

      來自重慶 回復(fù)
    2. 期待您的作品!

      來自北京 回復(fù)
    3. 我也想了解

      來自北京 回復(fù)
  19. 審批流做的我們頭大

    來自浙江 回復(fù)
    1. 所以前期的賬號權(quán)限設(shè)計很重要

      來自重慶 回復(fù)
  20. 權(quán)限,日志,報表,監(jiān)控,告警,都是2B 常用模塊。

    來自上海 回復(fù)
    1. 是的,不過個人認(rèn)為日志監(jiān)控這些產(chǎn)品解決方案都比較完善了

      來自重慶 回復(fù)
  21. 學(xué)習(xí)了,期待宇少對阿里云導(dǎo)航頁的分析

    來自重慶 回復(fù)
    1. 以后有時間會寫一篇,阿里云的導(dǎo)航真的強

      來自重慶 回復(fù)
  22. 寫的很好呀,講解很具體,學(xué)習(xí)~

    來自重慶 回復(fù)
  23. 比如業(yè)務(wù)系統(tǒng),僅僅是公司自身使用,就是單個系統(tǒng),為什么它也做單點登錄呢?

    來自廣東 回復(fù)
    1. 如果只是單個系統(tǒng)的話,確實沒必要。只是在考慮到現(xiàn)在或未來有其他系統(tǒng)接入的可能,才會做單點登錄。

      來自重慶 回復(fù)
  24. 寫得很好耶,小白get!

    來自廣東 回復(fù)
  25. 感謝,之前也有涉及到多身份多權(quán)限的問題。

    來自北京 回復(fù)
    1. 權(quán)限是一個很復(fù)雜的工程,得多花點時間研究

      來自重慶 回復(fù)
  26. 優(yōu)秀 學(xué)習(xí)到了!

    來自重慶 回復(fù)
    1. 我的朋友7總又出現(xiàn)了

      來自重慶 回復(fù)
  27. 你好 我也是做B端的 以后有時間可以交流一下

    來自湖北 回復(fù)
    1. 可以的,你是做什么產(chǎn)品的?

      來自重慶 回復(fù)
    2. 目前在做ERP系統(tǒng) 頭疼 ??

      來自湖北 回復(fù)
    3. ERP確實比較頭疼,對業(yè)務(wù)的理解需要非常深刻

      來自重慶 回復(fù)
    4. 想辭職不干了 賬號和權(quán)限做的想死 ??

      來自湖北 回復(fù)
    5. 你這種可以嘗試做非常細(xì)致的權(quán)限管理,但是要投入人員來運營

      回復(fù)
  28. 為什么這么多收藏,但是沒評論呢???

    來自重慶 回復(fù)
    1. 哈哈哈哈都在偷著學(xué),默默點開回復(fù)回一句

      來自廣東 回復(fù)