B端產品經理要掌握的3項硬核基本功
本文將介紹B端產品經理應關注的最硬核三項基本功——賬號體系設計、權限管理設計、導航體系設計。
做B端產品經理也很久了,也見識過很多產品和產品經理,似乎沒有人談及一些產品經理應當扎實掌握的基本功,而這些對于每一個產品經理都是至關重要的。舉個不恰當的例子,這些基本功就像一個人的內褲,你可能不太好意思拿出來說你有,但總歸是要用到的。
本文將介紹B端產品經理應關注的最硬核三項基本功——賬號體系設計、權限管理設計、導航體系設計。每一個模塊其實都可以單獨拿出來大做文章,但礙于篇幅,只能在此拋個引子,如感興趣,可在評論區深入探討。
一、賬號體系設計
對于普通用戶,賬號體系的可能被簡單理解為登錄,但做過B端產品的都清楚,賬號體系建設是一項復雜的系統工程。
賬號體系一般分為賬號、角色、權限三部分,所謂賬號體系設計,本質上是要設計賬號、角色與權限三者之間的聯系,但因為權限管理非常的復雜,所以單獨拿到下一部分來說。
賬號設計中的用戶體驗五要素
首先,我們先談賬號設計,參照上圖,我們根據用戶體驗五要素來分別說下賬號設計中要做哪些事情。
戰略層首先要明確我們的定位、目標、用戶,搞清楚戰略才能夠知道產品是封閉的還是開放的。比如我之前做的一個企業內部的saas框架,讓集團各個公司的辦公saas都接入進去,這種產品的定位必然是開放的,在接下來的產品設計中肯定要考慮開放更多接口,做足數據保密工作等。
范圍層考慮的是我們需要哪些功能,實現什么效果。賬號設計中,范圍層一般有三部分需要重點關注,分別是登錄、退出、密碼找回。這里面會涉及到賬號的第三方關聯,賬號密碼的加密方式,找回密碼的方式等。值得一提的是,如果你們是做一個開放平臺,未來可能會嵌入其他的產品,建議提前做好單點登錄的接口,免得后續改造起來很麻煩。
結構層更多的是考慮信息架構。在賬號設計中,需要呈現給用戶的信息主要分為用戶協議、保密協議、公告、賬號信息等。這個看上去簡單,但是落地還是比較困難,在系統開發階段,需要做一個非常合理的數據庫設計,否則用戶增多后,將會有無盡的麻煩。
框架層就是對界面的信息及布局設計。這里應當有操作指引、操作提示、登錄流程等方面的考慮。
最后就是表現層??筛鶕袌鲂枨?、產品定位來決定登錄頁的靜態或動態,是否需要廣告位,如果有廣告位,登錄框應該靠右,沒有的話就要居中……
角色分類
接下來簡單談談角色。角色可看做是一個個權限組,角色設計是B端賬號設計中非常重要的一環,由于業務特殊性,B端用戶勢必有很多層級,每個層級所需要看的內容不盡相同,就需要一個符合業務的角色體系。
一般的角色有三種設計方式——根據崗位、根據職責、個性化。
- 根據崗位是指用戶本身的崗位就是自己的角色,上級要擁有下級全部權限,這種設計多用于銷售相關產品。
- 根據職責是指以用戶使用這個系統的目的來確定角色,比如超級管理員、分級管理員等,這種設計比較常見,一個普通員工的權限可能比公司CEO的權限范圍都大。
- 最后一種是個性化角色設計,一個賬戶開通后,僅具有一般權限,需要什么權限可在后續找相關負責人申請,此種設計常見于需求頻繁變動的企業內部,且維護成本比較高,對于一般的B端產品,不建議直接采用此種設計。
由于B端用戶的需求通常比較復雜,所以在實際的產品設計中,這三種方式往往混搭出現,以充分滿足用戶需求。
二、權限管理設計
在探討這個模塊之前,我要發出一個靈魂拷問:為什么需要權限管理?
理由很簡單——為了更好的協作。從本質上來講,所有權限管理產品,都屬于B端產品,涉及到很多不同的人的參與,不同的人需要看的東西不一樣,不同的人需要進行操作不一樣,不同的人對風險把控的能力不一樣,為了降低風險,增加效率,才需要權限控制。
權限管理一直以來都是讓產品經理頭疼的事情,作為一個B端產品經理,我們應該知道一個共識——B端的需求復雜,目前還沒有一個針對權限管理的完美的解決方案,權限管理的設計過程其實是一個不斷取舍的過程。
權限管理的RABC模型
現階段比較通用且比較成熟的權限管控模型是RBAC(Role-Based Access Control)——基于角色的訪問控制。簡單來說,就是權限授予角色,角色賦給賬號,角色可視為權限的集合,賬號就是角色的集合,彼此為多對多關系。賬號和權限在上面已經提到,且網上很多關于RBAC的資料可以查閱,所以這里不重點闡述,我想重點說明的是在權限管理設計時應當注意的一些問題。
(1)數據權限與功能權限分開
見過一些B端產品,將數據權限與功能權限綁定在一起,可見即可得。在產品起步階段,這樣的設計會減少維護成本和學習成本,但是當產品用戶量提升或遭遇大客戶時,便會顯得力不從心。這個時候可能需要重新設計產品,將數據權限和功能權限剝離,這樣很耗費資源,還不如一開始就做到位。
(2)角色不要與組織強掛鉤
部分B端產品會采用將角色掛靠到組織下的方式,這種方式的好處是角色和賬號可一并管控,且可以無限細分管理下級,擴展性很強。但是對于一個商業產品來說,非常不推薦這種形式,因為目前很多公司的組織架構并不穩定,甚至有的公司每個月都要大調整,角色與組織強掛鉤無異于飲鴆止渴。
(3)留有余地,為某些特殊需求做準備
每一個B端產品經理都知道,B端的需求是非常復雜的,所以在設計權限管理時,要為一些特殊需求做準備,留有可自由配置任何權限組合的通道,以免需求到來,措手不及。
三、導航體系設計
相比于直接搜索,用戶更喜歡用導航,因為導航是讓用戶做選擇題,而搜索是填空題。
這句話我忘記了是從哪聽說的,但每次談到B端產品,我都會想到這句話。對于B端產品來說,用戶學習成本高,完全做不到像百度一樣直接放個搜索框,導航是一個B端產品經理傳遞給用戶最溫暖的話語。
導航的作用有兩個——“我們有什么”以及“你在哪”。
“我們有什么”意思是要有一個清晰的導航架構及標簽體系。這就要求在設計產品時對各頁面及子頁面做好清晰的規劃,保持結構的連貫性和一致性。同時導航務必采用容易理解的交互方式,不要做太多“炫技”式交互。
導航的形式也要根據實際情況做充分的考慮,主流的導航形式有三種——頂部導航、側邊導航、混合導航,其中混合導航是頂部導航和側邊導航共存的混合形式,多用于頁面結構復雜的產品。目前導航設計比較好的產品有阿里云官網,有機會可以單獨寫一篇文章來分析阿里云官網。
阿里云官網導航
“你在哪”其實就是告訴用戶現在的處于哪一個頁面的哪一個位置。常見的處理方式是在導航中做標注,用戶所處的位置做區別處理。另一種常用的處理方式是面包屑導航,每一級都做標注,且每一級都可以點擊,電商網站常使用面包屑導航。
有贊微商城中對用戶位置的展示
京東商城中的面包屑導航設計
以上就是我對B端產品經理最硬核的三項基本功——賬號、權限、導航的闡述,還是那句話,基本功就像內褲,你可能不太好意思拿出來說你有,但總歸是要用到的。如果有問題,歡迎在評論區與我溝通。
私以為,每一個產品經理都必須穿一條好內褲。
本文由 @王撼宇 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
你好,功能權限和數據權限,我的理解就是,比如有一個實驗記錄這個功能,記錄各種實驗方案數據,功能權限:就是實驗人員可以使用實驗記錄這個功能,但IT人員不能使用,數據權限就是:創建實驗和參與實驗的人可以看到這個實驗記錄,沒參與的這個實驗的實驗也可以使用實驗記錄這個功能,但沒參與這個實驗的人員不能查看這個這個數據,是這么理解嗎,我感覺有點別扭
是的,一橫一縱。兄弟最近在做實驗記錄功能吧
是啊,樓主也在做嗎
沒有
有點淺,不過真是基本功
您好,對于您的文章,我有兩處疑問,希望您指點;
1.數據權限和功能權限分開:我是不是可以理解為比如財務角色查看訂單管理場景,僅讓財務角色在訂單管理下看到“已支付”狀態的訂單,這樣系統每次訪問服務器時就會只調取已支付的訂單,我這個理解算不算是數據權限與功能權限分開的?
2.角色不要與組織強掛鉤:是不是可以理解為一個角色可以所屬一個或多個組織,但調整組織架構時,該組織下的角色不受影響,并且該角色不管調整到那個組織,他的權限都不變呢?
之前沒接觸過B端,希望您指正。
第一個問題:功能權限是讓用戶有權限使用這個功能,而數據權限就是決定用戶在使用這個功能時能看到哪些數據。比如你說的這個場景,財務和運營都有看到訂單列表的權限,這是功能,而財務只能看到已支付類的訂單,而運營能看到所有的訂單,這是數據權限。再比如總裁和大區總都能看到銷售數據,用著同一個功能,而總裁能看到全國的,大區總只能看到他管轄的區域的,這也是數據和功能權限分開的案例。
第二個問題,如果角色屬于組織,很難做到調整組織時角色不受影響,建議是角色和組織只做關聯,組織調整只會影響到該組織下的人,而不會影響其他人。有的角色甚至不和組織掛鉤,只和人員掛鉤,不管組織怎么變,人員的權限都不受影響。
感謝您的幫助。
可以持續關注我的公眾號,感謝支持
轉B端產品 有哪些方法?
最近遇到數據權限和功能權限設計問題,一直沒想透徹,不知您是否有經驗可介紹?
可以關注我的公眾號,有時間會寫這個
憾宇最流弊
桃哥啥時候也來謝謝UI啊
寫寫
感覺例子舉的很恰當
謝謝
贊一個,不知道筆者是那個行業的,可以多交流 ??
前不知名信息化產品經理,現智能CRM產品小白
相比于直接搜索,用戶更喜歡用導航,因為導航是讓用戶做選擇題,而搜索是填空題。雖然不知道這個結論是從什么數據總結出來,總的來說這個觀點其實不一定,我以前就是常常會用到阿里云,對我來說阿里云的導航太復雜,因為系統過于龐大,導致找一些功能模塊,翻來翻去,到最后,還不如一個搜索,把功能搜索出來
是的,這句話并不是說完全摒棄搜索,而是說,對于B端產品來說,一個清晰的導航,比搜索重要的多。讓我們這樣想,你是一個第一次接觸阿里云的,并不是對功能了如指掌的老司機,你是更需要導航還是搜索。office發展到2016才設置了一個搜索,其實也是一個道理,搜索在B端只能是輔助,而不像C端是主搜。
請問下什么情況下需要將數據權限和功能權限分開呢,可以舉例說明下嗎?謝謝作者哈哈哈 我已經關注了你的公眾號
一般情況下,做權限系統都建議把數據權限和功能權限分開。比如一個CRM系統的團隊數據統計,功能權限應該只開給管理者,普通銷售是沒有這個功能權限的。但是不同的管理者,可以看到的數據是不一致的,ceo需要看到全國的,分公司總經理只能看到特定地區的。
對于B端產品這個具體還是要看客戶需求,數據權限顧名思義,誰可以看到那部分數據,誰不可以看到哪部分數據,配好用戶角色,根據用戶角色進行數據權限劃分;而功能權限就是菜單權限了,一般情況下,我們配置好所有菜單開關,由admin去設置用戶的菜單使用權限了。一般系統設計,數據權限和菜單權限是兩個獨立的,就如同作者的例子,或者,一個OA系統中,領導可能會看到一些統計數據,但是不必進行一些功能操作,而員工沒有權限看統計數據,但是可以進行流程申請等操作。
詳細清楚!謝謝! ??
期待作者大大的權限篇
謝謝,會有的
個性化配置對于一個組織架構變動頻繁的組織來說,可能是基于角色、組織配置權限的基礎上,最佳解決方案了吧
頻繁變動的組織架構,我稱之為動態組織架構,哈哈哈哈哈
擁抱變化。
我們要擁抱有意義的變化
坐等作者的權限篇!
哈哈,可以關注我的公眾號,才開始搭建,準備最近寫點干貨
小白感激不盡
感謝,有些以前沒明白的東西豁然開朗
寫得很棒,受益匪淺
這個說的都比較淺,往深了說的話,可以說得太多了
是的,但是淺層的我們理解了,你下次寫深入的文章,那么我們也就明白了
賬號權限頭大……感謝分享!
權限管理目前還沒有一個完美的方案,只能多踩坑,多總結
嗯,大佬可不可以寫一寫B端系統跟系統之間對接需要學習的一些知識,感謝!??!
之前做過B端框架產品,可以理解為承載各個系統接入的容器,有機會可以寫一寫,有興趣可以關注我公眾號喲
期待您的作品!
我也想了解
審批流做的我們頭大
所以前期的賬號權限設計很重要
權限,日志,報表,監控,告警,都是2B 常用模塊。
是的,不過個人認為日志監控這些產品解決方案都比較完善了
學習了,期待宇少對阿里云導航頁的分析
以后有時間會寫一篇,阿里云的導航真的強
寫的很好呀,講解很具體,學習~
比如業務系統,僅僅是公司自身使用,就是單個系統,為什么它也做單點登錄呢?
如果只是單個系統的話,確實沒必要。只是在考慮到現在或未來有其他系統接入的可能,才會做單點登錄。
寫得很好耶,小白get!
感謝,之前也有涉及到多身份多權限的問題。
權限是一個很復雜的工程,得多花點時間研究
優秀 學習到了!
我的朋友7總又出現了
你好 我也是做B端的 以后有時間可以交流一下
可以的,你是做什么產品的?
目前在做ERP系統 頭疼 ??
ERP確實比較頭疼,對業務的理解需要非常深刻
想辭職不干了 賬號和權限做的想死 ??
你這種可以嘗試做非常細致的權限管理,但是要投入人員來運營
為什么這么多收藏,但是沒評論呢???
哈哈哈哈都在偷著學,默默點開回復回一句