B端產品經理要掌握的3項硬核基本功

AI時代,如何更快入行搶占紅利得高薪?前阿里巴巴產品專家帶你15天入門AI產品經理。了解一下>

本文將介紹B端產品經理應關注的最硬核三項基本功——賬號體系設計、權限管理設計、導航體系設計。

做B端產品經理也很久了,也見識過很多產品和產品經理,似乎沒有人談及一些產品經理應當扎實掌握的基本功,而這些對于每一個產品經理都是至關重要的。舉個不恰當的例子,這些基本功就像一個人的內褲,你可能不太好意思拿出來說你有,但總歸是要用到的。

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

一、賬號體系設計

對于普通用戶,賬號體系的可能被簡單理解為登錄,但做過B端產品的都清楚,賬號體系建設是一項復雜的系統工程。

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

B端產品經理要掌握的硬核基本功

賬號設計中的用戶體驗五要素

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

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

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

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

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

最后就是表現層。可根據市場需求、產品定位來決定登錄頁的靜態或動態,是否需要廣告位,如果有廣告位,登錄框應該靠右,沒有的話就要居中……

B端產品經理要掌握的硬核基本功

角色分類

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

一般的角色有三種設計方式——根據崗位、根據職責、個性化。

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

由于B端用戶的需求通常比較復雜,所以在實際的產品設計中,這三種方式往往混搭出現,以充分滿足用戶需求。

二、權限管理設計

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

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

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

B端產品經理要掌握的硬核基本功

權限管理的RABC模型

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

(1)數據權限與功能權限分開

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

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

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

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

每一個B端產品經理都知道,B端的需求是非常復雜的,所以在設計權限管理時,要為一些特殊需求做準備,留有可自由配置任何權限組合的通道,以免需求到來,措手不及。

三、導航體系設計

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

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

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

“我們有什么”意思是要有一個清晰的導航架構及標簽體系。這就要求在設計產品時對各頁面及子頁面做好清晰的規劃,保持結構的連貫性和一致性。同時導航務必采用容易理解的交互方式,不要做太多“炫技”式交互。

導航的形式也要根據實際情況做充分的考慮,主流的導航形式有三種——頂部導航、側邊導航、混合導航,其中混合導航是頂部導航和側邊導航共存的混合形式,多用于頁面結構復雜的產品。目前導航設計比較好的產品有阿里云官網,有機會可以單獨寫一篇文章來分析阿里云官網。

B端產品經理要掌握的硬核基本功

阿里云官網導航

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

B端產品經理要掌握的硬核基本功

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

B端產品經理要掌握的硬核基本功

京東商城中的面包屑導航設計

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

私以為,每一個產品經理都必須穿一條好內褲。

 

本文由 @王撼宇 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
  1. 最近遇到數據權限和功能權限設計問題,一直沒想透徹,不知您是否有經驗可介紹?

    回復
    1. 可以關注我的公眾號,有時間會寫這個

      回復
  2. 憾宇最流弊

    回復
    1. 桃哥啥時候也來謝謝UI啊

      回復
    2. 寫寫

      回復
  3. 感覺例子舉的很恰當

    回復
    1. 謝謝

      回復
  4. 贊一個,不知道筆者是那個行業的,可以多交流 :oops:

    回復
    1. 前不知名信息化產品經理,現智能CRM產品小白

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

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

      回復
  6. 請問下什么情況下需要將數據權限和功能權限分開呢,可以舉例說明下嗎?謝謝作者哈哈哈 我已經關注了你的公眾號

    回復
    1. 一般情況下,做權限系統都建議把數據權限和功能權限分開。比如一個CRM系統的團隊數據統計,功能權限應該只開給管理者,普通銷售是沒有這個功能權限的。但是不同的管理者,可以看到的數據是不一致的,ceo需要看到全國的,分公司總經理只能看到特定地區的。

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

      回復
    3. 詳細清楚!謝謝! ;-)

      回復
  7. 期待作者大大的權限篇 :mrgreen:

    回復
    1. 謝謝,會有的

      回復
  8. 個性化配置對于一個組織架構變動頻繁的組織來說,可能是基于角色、組織配置權限的基礎上,最佳解決方案了吧

    回復
    1. 頻繁變動的組織架構,我稱之為動態組織架構,哈哈哈哈哈

      回復
    2. 擁抱變化。

      回復
    3. 我們要擁抱有意義的變化

      回復
  9. 坐等作者的權限篇!

    回復
    1. 哈哈,可以關注我的公眾號,才開始搭建,準備最近寫點干貨

      回復
  10. 小白感激不盡

    回復
  11. 感謝,有些以前沒明白的東西豁然開朗

    回復
  12. 寫得很棒,受益匪淺

    回復
    1. 這個說的都比較淺,往深了說的話,可以說得太多了

      回復
    2. 是的,但是淺層的我們理解了,你下次寫深入的文章,那么我們也就明白了

      回復
  13. 賬號權限頭大……感謝分享!

    回復
    1. 權限管理目前還沒有一個完美的方案,只能多踩坑,多總結

      回復
  14. 嗯,大佬可不可以寫一寫B端系統跟系統之間對接需要學習的一些知識,感謝!!!

    回復
    1. 之前做過B端框架產品,可以理解為承載各個系統接入的容器,有機會可以寫一寫,有興趣可以關注我公眾號喲

      回復
  15. 審批流做的我們頭大

    回復
    1. 所以前期的賬號權限設計很重要

      回復
  16. 權限,日志,報表,監控,告警,都是2B 常用模塊。

    回復
    1. 是的,不過個人認為日志監控這些產品解決方案都比較完善了

      回復
  17. 學習了,期待宇少對阿里云導航頁的分析

    回復
    1. 以后有時間會寫一篇,阿里云的導航真的強

      回復
  18. 寫的很好呀,講解很具體,學習~

    回復
  19. 比如業務系統,僅僅是公司自身使用,就是單個系統,為什么它也做單點登錄呢?

    回復
    1. 如果只是單個系統的話,確實沒必要。只是在考慮到現在或未來有其他系統接入的可能,才會做單點登錄。

      回復
  20. 寫得很好耶,小白get!

    回復
  21. 感謝,之前也有涉及到多身份多權限的問題。

    回復
    1. 權限是一個很復雜的工程,得多花點時間研究

      回復
  22. 優秀 學習到了!

    回復
    1. 我的朋友7總又出現了

      回復
  23. 你好 我也是做B端的 以后有時間可以交流一下

    回復
    1. 可以的,你是做什么產品的?

      回復
    2. 目前在做ERP系統 頭疼 :cry:

      回復
    3. ERP確實比較頭疼,對業務的理解需要非常深刻

      回復
    4. 想辭職不干了 賬號和權限做的想死 :cry:

      回復
    5. 你這種可以嘗試做非常細致的權限管理,但是要投入人員來運營

      回復
  24. 為什么這么多收藏,但是沒評論呢???

    回復
    1. 哈哈哈哈都在偷著學,默默點開回復回一句

      回復
马总会三肖中特