業務還是功能?ToB產品的用戶角色問題

2020-12-24 酷扯兒

本文轉載自【微信公眾號:ToB行業頭條,ID:shkxquan】經微信公眾號授權轉載,如需轉載與原文作者聯繫

專注於角色的業務,而不是每一個具體的功能。

來源/產品微言(ID: wuyuweiyan) 杜松

編輯/ jenny

我們之前談到了如何 基於用戶洞察設計產品的業務架構 ,其目的是為了實現業務的解耦,以便構建一個「輕型」的2B業務系統,實現可擴容的架構,使得整個系統能夠跟上業務快速發展的步伐,而不必為了新業務的增長而重構系統。

我們也花了幾個篇幅來介紹 「產品架構」的概念、思路和設計的方法,並復盤了一個 2B產品的多租戶架構設計 案例。

如果你稍微細心,就能發現其中還缺少了一個關鍵的環節。

是的,這個環節就是 「用戶對象」的問題,就是整套業務系統裡面,到底應該如何構建一個能夠「容納」不同角色的用戶體系並行處理業務,如何實現跨流程的協作。

事實上,這個問題對系統的影響還包括如何構建角色和權限模型,這一點在後續將繼續展開。本文仍然以「O2O平臺」作為案例展開。

01

基於工作流梳理用戶對象

2B的產品,簡單的來說,就是解決很多的用戶(發布在很多業務部門,涉及各種交叉並行的業務流程)如何高效率的協同工作的問題,不管是我們常見的OA系統,還是各種複雜的ERP、CRM系統,還是前些年火熱的O2O平臺。

對任何面向企業的產品來說,都是一頭挑起各種不同的用戶角色,另一頭挑起協作效率的重任。對普通的使用者來說,這套系統的價值在於節省時間和工作量,通過使用這套系統來實現自身(個人或部門)「業績」和能力提升。對企業的管理、決策者來說,這套系統的最多價值在於如何有效的提升整個企業的業務能力。

換一種說法就是,2B的產品,本身指是一個實現企業業務運作協作的工具,它的難點在於,如何更有效率的容納N中角色和N多並行業務的處理能力,並通過這一產品,實現企業業務流程的優化創新。

2B產品的設計實踐,也就是思考如何基於企業客戶的業務場景,實現個人 vs 組織的「矛盾性」需求的過程。

不管各種新奇的理論如何,我們首先做的第一件事情始終都是在圍繞用戶展開,通過實地的業務模擬,考察和分析推演,結合具體的業務流程和工作流程,拆分各個「群體」——系統的服務實體對象。

1、業務還原

在構建整個 O2O平臺的過程,我們大致梳理的業務過程,包括用戶發起服務請求、後臺處理服務請求、前端完成服務請求三個過程。

簡單描述如如下圖所示:

業務閉環示意圖

服務請求

用戶(不管是2B的客戶,還是2C的終端用戶)可以通過多種方式發起客服服務請求,在這個過程中,坐席端的首要任務就是如何及時響應用戶端的請求,完整的記錄用戶的問題,並快速解決用戶的問題。

從這個過程中,可以拆分的產品價值包括用戶端的體驗問題以及坐席端的效率問題。

也就是,在這個過程中,需要拆分和解決的問題包括:

. 如何建立完整的用戶請求的通道(全覆蓋的通道能夠提升用戶的整體體驗);

. 如何解決坐席的快速解決用戶的問題(任何一個服務平臺都希望儘可能的提高一次服務過程解決用戶問題的比例,這需要一個足夠高效的知識庫);

. 如何幫助坐席快速,完整的記錄用戶請求的內容,也涉及到當服務請求過大時如何分配合理的坐席資源。

這些問題不但涉及到產品的架構設計,也是產品的交互和視覺設計的重要參考依據,必須充分結合實際工作場景,方式和流程,來考慮在交互上的便捷性,甚至視覺上減輕使用者的疲勞感。

實際上,這也是技術選型的重要指標性因素,所以通常來說,產品的需求文檔必須要有明確的技術性指標,包括響應時間,並發數等。

ps:在前文 淺析產品的信息架構、產品架構與業務架構 談到的" 產品的抽象能力 ",指的是這種從上往下的業務分析能力,而不是指能從下往上看各個細節。

對產品經理來說,面向任何一個業務需求,都首先要從大方面思考,再深入到細節性流程,一旦反過來,則整個產品只有功能,而沒有業務。

服務調度

調度,指的是針對某類型用戶/客戶,發起服務請求的響應和處理。

也就是基於「效率至上」的原則,如何調配最合適的工程師解決用戶的問題是最經濟,最高效,在這個過程,涉及到很多種場景的優先考慮,比如有些問題只是一般性的諮詢,有的問題則嚴重的質量問題,還有的問題可能已經引發了群體性和輿論性問題。

這不但需要建立一種完備的處理機制和流程,首先則是需要賦予一線「接線員」相應的權限和能力,能夠第一時間識別到風險,也能快速調動相關的資源,及時處理用戶問題。

在產品和技術上的處理細節,還需要考慮到資源的瓶頸性,系統必須要能人工幹預的調度資源,還要能建立一個「眾包」的通道,打通更多的社會性資源加入「平臺」,同時也在一定程度上激發工程師的積極性,來提高服務的處理效率。

服務履約

這個環節,也是最終如何處理用戶服務請求的過程,也是一個對服務質量考核的關鍵節點,包括服務響應時間、服務質量、用戶評價等過程。

業務上,這個環節在某些場景還可能存在服務和產品的二次銷售行為。

綜上所述,我們就能夠把整個複雜的業務過程,抽象成三大「業務動作」,也就是支撐整個系統能夠正常運轉的基本節點,想像一下房子的支柱,即可理解這種思路設計的系統有那些優勢。

換言之,我們在第一階段設計產品的架構時,根本無需過多的考慮分支流程和細節性邏輯,只需要構建一個支撐平臺即可完整的還原整個業務流程。

也就是,我們可以想像自己在打造一個桌面,只需要考慮桌子的四個角之間的構造合理性、穩定性和承重能力,就可以保障未來的業務擴展。

在架構設計的階段,我們可以把上述的業務流程進一步抽象,整個的業務模型可以表達如下:

O2O平臺業務模型

從整個模型上,我們既能看到要服務的用戶對象,也能看到各個服務的實體,以及在整個過程中關鍵業務動作,圍繞這些動作,即可完成各種不同場景下的業務訂單。

這個平臺是一個高度解耦的系統,能夠兼容不同的業務和不同的單據格式和內容,對整個系統而言,表現層的內容對業務本身不構成影響因子,整個平臺僅依賴「業務動作」的高效運轉。

2、實體拆分

從整個業務模型中,我們梳理出了一個業務全貌,可以清晰的識別到各個服務層所承載的服務能力,即可根據各自的能力進一步的拆分出實體的「業務範圍」。

我們也就能基於對整個業務場景的透徹理解,從實際業務的角度逐級分解整個用戶角色的邊界和在流程中的承接和交互關係。

這種從邏輯層的分解,在系統的設計中,就直接演變對應到實際中的「業務實體」,也就是不同的業務應用對象,他們直接承載著整個平臺的業務運作。

(ps,在實際的產品設計中,只需要依據業務場景的展開,即可完整的勾繪出整個平臺的業務關係,本文為方便描述,本文示例進行了大量的簡化工作。)

角色示例

從上圖可以清晰的看到不同的實體,他們的業務邊界非常的清晰,在這個邏輯下,我們可以清晰的設計各自的工作流,也就能清晰的界定不同的用戶角色權限。

以「門店」為例,TA在這個角色關係中,實際上處於一種「上下承接」的關係。

向上對接訂單的調度,負責總部的調度機制和工單協調機制;向下,對接其旗下的服務工程師,負責工程師的調度和工單的協調。

按照這種思路,我們在設計「門店」這個角色和工單的流轉業務中,就能很明確的限定它在這個平臺中的地位,換句話說,也就能界定它的權限範圍和需求範圍。

也就不會再出現隨意性的變更,因為它受制於整個平臺的管理規範。

基於這種思路,我們就能夠有效的拆分複雜的應用,解耦整個系統的框架設計,也就能清晰的描述各個用戶角色在平臺上的職責、權限和價值體現。

整個平臺是基於角色的工作流作為出發點,而不是帳戶,兩者可實現柔性的關聯關係,而不是強制性的管理關係。

任何用戶,只需要符合某種角色身份就可以在平臺中自由完整的執行業務動作。這也是整個平臺帳戶體系設計的基本思路。

越是大型的系統,越是要能界定邊界,瀝青責權。

02

專注於動機設計用戶標籤

「標籤」的目的,除了簡化系統設計以後,還有一個重要屬性就是構建柔性的網絡管理規則,可以根據不同的業務需求,直接配置不同對象。

標籤系統可以根據角色的類別、屬性、業務動作等進行分解。如下圖所示:

這個圖,有出現「類別」、「屬性」、「可視範圍」、「業務動作」這些名詞。實際上這四個名詞並非通用性術語,而是在構建這個平臺以及制定整個平臺的SOP採用的一種項目化語言。

根據我的經驗,採用這一約束性的項目化語言,有助於團隊快速的理解需求,並在規範的範圍內加速產品的應用落地。

這裡還引入了一個重要的屬性:可視範圍。簡單的說,就是一個坐席、或者門店,工程師可以根據他們的實際情況,配置他們所能履約完成的業務範圍,比如A門店具備上門服務的能力等。

對於一個產品 / 系統來說,決定業務的是每一個獨特的實體對象,也就是在整個工作流過程中的角色,只需要緊扣角色對象,就能夠清晰的界定整個平臺的邊界範圍——直接給業務實體打標籤。

但我們卻容易停留在表面,而沒有能夠深入業務,更談不上對用戶動機的深刻洞察。

換句話說,我們在用戶調研過程中,過於傾向於關注用戶的行為動作,而不是動機——用戶畫像過多的停留在個人信息和人口學屬性的集合,而沒有能夠深入到實際業務中。(我們最容易犯的錯誤就是過於停留在產品的功能上,而不是業務場景中)

比如,調研發現用戶需要頻繁的列印那些有規劃地點、線路的訂單,如果只是去設計一個高效的列印、排版的訂單處理和調研界面,顯然不是更好的解決方案。

對產品而言,不能提供關於「用戶態度和行為特性」的人物角色只是一個「雞肋」般的存在,因為無法真正理解用戶的痛點,無法真正解決用戶的「績效問題」,也就根本不能設計一款真正符合用戶預期的產品。

「當用戶使用某個產品的時候,他們是為了完成某個特定的工作(到達某種結果)」,這是一句產品名言。

在設計產品時,真正值得高度關注的是用戶的目標、產品的使用場景以及用戶與產品的關鍵交互階段,而不是把焦點集中在用戶的任務是什麼以及如何完成任務。

所以,

在設計用戶角色模型時,應該分成兩個步驟來完成:

1、建立對人物角色的同理心

包括用戶的履歷和年齡、收入等人口學屬性。

2、關注人物角色的動機

包括用戶的態度和行為,使用產品的目的和動機,以及在使用產品時的行為細節、偏向和心理感受。

相關焦點

  • ToB產品與ToC產品的區別
    決策者一般為公司的高管或者老闆,能夠決定「付款」的人,所以他們會更加關注引入的產品,是否能夠幫助公司提高運轉效率;管理者一般為中層人員,會更加關注自己職責範圍內相關功能是否可以幫助自己提高工作成績;而普通員工,一般關注的是產品的簡單程度、是否能夠減輕自己的工作負擔。C端產品用戶角色比較單一,大多數用戶都是衝著核心的某一兩個功能而使用這款產品,用戶角色高度集中。
  • 2B產品的用戶權限管理問題與RBAC模型
    來源/產品微言(ID: wuyuweiyan) 杜松編輯/ jenny在上一篇文章《業務還是功能?ToB產品的用戶角色問題》中,我們討論了 2B產品的用戶角色設計 問題,著重探討了在整個系統中,用戶和角色的關係,並基於業務過程對角色進行了場景的細分,並詳細的解釋了為什麼要在做產品原型設計之前分析業務角色,設計各個角色的關係。本文則討論如何基於用戶角色進行權限管理。
  • B端產品設計:用戶角色權限系統設置
    本文首先對B端產品的用戶與需求進行了解析,進而利用RBAC模型做了權限劃分,並做了詳細的案例分析。在做過了一些B端產品後,就會發現所以B端端產品有很多共同的部分,比如系統設置裡的用戶角色權限以及基礎信息的維護,雖然B端產品可能業務不一樣,產品服務的人群、產品價值不一樣,但是用戶體系卻是每個系統必不可少的。1.
  • B端產品設計3大流程業務流程圖、功能流程圖、頁面流程圖
    本文介紹了B端產品設計的三個流程圖:業務流程圖、功能流程圖、頁面流程圖,與大家分享!B端產品往往涉及複雜的業務關係和場景,線下業務一般會涉及到採購、銷售、物流、財務、人力、倉管等多個不同的部門和角色。如何用產品支撐B端業務落地是一項非常有挑戰性的工作,要求產品經理既要有對宏觀的把控能力,又要有對細節的專注力。B端產品設計分為業務問題診斷、產品整體方案設計、產品細節方案設計幾個階段,在不同階段,我們需要藉助不同類型的流程圖來幫助我們釐清思路。一、業務問題診斷:業務流程圖1.
  • To B業務怎麼做「用戶運營」?
    使用者:就是一線員工,每天都在操作、體驗我們的產品服務,對用戶體驗、工作量、績效等因素顧慮很多,說白了就是想少幹活、多掙錢。 問題問的是「用戶運營」,那我們關注的重點就要放在一線員工上。
  • 如何深入業務場景,做出好的產品規劃?
    在為用戶提供服務的過程中,產品和運營承擔了非常重要的工作。產品為「系統」而生,運營為「人」而活。從前期調研、業務分析、目標用戶畫像定位到功能模塊拆解,用戶價值提升,產品經理與運營是密不可分,相輔相成的。產品教會運營如何用系統,如何告知用戶哪裡有問題。運營要弄懂產品設計的基本邏輯,並且整理用戶能明白的話術。
  • 好未來發布AI開放平臺,基於AI產品發力ToB業務
    好未來發布AI開放平臺,基於AI產品發力ToB業務 作者:杜威 發布時間: 2019-07-19 12:23
  • 產品經理之用戶角色權限的管理設計模式
    通常在做系統的時候除開基礎業務外我們要搭建一套與行政功能相關聯的基礎三要素:用戶、角色、權限。(本文就不畫圖了,雖然圖片利於理解但是我手頭上的工具有限就算了)二、三個模塊搭建用戶系統通常我們在做產品設計的時候做用戶系統的時候都會分為:用戶、角色管理(一般角色和權限都做在一個模塊,角色包含權限)部門管理。
  • 工作1年後,我對B端產品用戶行為有了新的理解
    編輯導語:B端產品也叫「2B(Bussiness)」產品,使用對象是組織或企業。B端產品往往是基於某個業務領域,解決客戶在辦公或經營過程中遇到的問題,為客戶提高效率、增加收入、減少成本,一句話概括就是「為客戶賺的更多,省的更多」。本文作者結合自己的工作經歷,總結了對B端產品用戶行為的看法。
  • 管中窺豹——從限購業務模型設計論產品業務模型構建之道
    一、組成——產品業務模型構成產品的業務模型是業務的抽象模型,包括從底層的業務對象,業務範圍、業務限制、業務規則等、執行層的數據流動方式及展現層的前臺展現交互的設計。一個較為通用的業務模型模板,可以由架構層,數據層,展現層三層構成。
  • 萬惡之源KPI|B端產品業務專家之路
    身為產品經理,在梳理業務場景及設計功能時,也必須要結合使用者的KPI,具體問題具體分析。本文以客服業務為例,分析KPI是如何影響業務的,產品經理又該怎麼使用它?講到KPI,大家可能就會聞風喪膽。每天的撕逼,每周的996,每個月的熬夜寫報告,不就是為了達成所謂的KPI,進而拿到更好的回報,也可能殘忍地只是因為怕被優化。
  • 產品功能如何定義?
    而當產品經理切入產品設計時,一般有我們常用的兩種產品類型,一種是基於基礎核心業務延伸的從0到1的項目設計,一種是處於生命周期-成長期中從1到N的產品迭代。而這2種規劃產品的功能的方式也是不一樣的。01 從需求出發不管是哪類產品,立足點都是基於需求,而需求池也分2種,一種是源源不斷的需求池,一種是寥寥無幾的需求收集;前者更為切合從1到N的產品,上線後的需求或反饋都是來自真實用戶的聲音,包括主動的從現有的產品進行回訪、用戶調研以及通過用戶的反饋和建議收集有效需求。有了需求,那是最直觀的,對應的產品功能可以根據此展開進行規劃。
  • 產品分析 | 嗶哩嗶哩,用戶是希望,虧損不是問題
    本文筆者將從產品、市場、用戶、功能四個方面對B站進行分析,並提出一些優化改進建議。其主要收入遊戲業務的增長已經觸碰到了天花板,但遊戲運營成本在不斷的增長,導致虧損擴大。但是,從長期來看,提高用戶粘性與忠誠度依然是B站最珍貴的財產,B站需要不斷調整優化營收業務份額佔比,形成新的內容電商體系。本文將從產品、市場、用戶、功能四個方面對B站進行分析,並提出一些優化改進建議。
  • 螞蟻森林功能的主要價值,是用戶激活還是用戶留存?
    AARRR模型圖解(圖源網絡)螞蟻森林功能對於支付寶的整體增長來說,在AARRR這5個環節中,主要價值體現在用戶激活環節還是用戶留存環節?起初我認為螞蟻森林對於支付寶主要是起到了激活的作用,這是因為螞蟻森林上線後,並沒有大規模的運營動作,因此並未為支付寶的整體留存起到十分重要的作用。
  • 產品系列(四):聊聊產品策劃和產品設計
    編輯導語:講了產品經理的核心工作流程、用戶需求分析、可行性分析後,我們對產品經理的業務更加了解;本篇文章作者從產品出發,詳細的介紹了產品策劃和產品設計,我們一起來看一下。一、產品策劃產品策劃是根據市場和用戶的需求,結合公司的戰略規劃,制定產品業務模式的過程。
  • 產品面試問題:二次元用戶需求挖掘與抖音評論邏輯
    面試問題:第一個問題:我們公司的產品是一個完全基於虛擬形象的社交App(不允許出現任何真人照片和視頻),請你分析該產品的用戶需求以及如何解決用戶需求的手段。第二個問題:請描述抖音App的評論功能的具體邏輯,並列舉在評論功能使用過程中可能出現的所有消息情況。
  • 產品筆記——怎麼找到用戶痛點
    2)不要追逐市場中某一產品的空缺,如果在已有的市場中僅對其頭部產品缺失的能力進行補充,對業務是沒有什麼意義的,除非兩者的用戶量級差不多;因為頭部產品架構和體系都相對成熟,明顯放著一個空缺等著你去發展的機會不大,所以要謹慎分析後再行動;競爭對手不會那麼好心留個蛋糕給後來者享用,有可能本來那就是個坑,比如說有監管方面的風險,或者技術上的壁壘等,即便被彎道超車,體量大的產品也會迅速抄襲這個功能
  • 探究B端產品的體驗設計方法——角色全景圖
    對於CRM、ERP、工單平臺這類複雜工具類系統,人們不再只是追求功能基本跑通、界面是否好看,也開始關注產品是否清晰好用、能否快速上手、能否降低人工勞動、能否提升工作效率…對於前者,不少團隊通過「設計系統(Design System)」來解決一致性、美觀度、可用性、開發效率等問題。而對於後者,如何讓B端產品更貼合使用者的工作場景和體驗訴求,也成了設計師日益關注的重心。
  • 打開還是關閉?PUSH功能對用戶而言意味著什麼?
    但技術後續的發展遠遠超乎想像,如今黑莓手機已經停產,PUSH功能卻成功在移動智能時代生存下來。而且,PUSH的角色發生了天翻地覆的變化。哥倫比亞大學Tow數字新聞中心(Tow Center For Digital Journalism)曾連續兩年針對 30 多個新聞APP的推送通知做了統計研究,發現近年來新聞機構正在不斷加碼應用程式的PUSH。
  • 產品市場策略:高屋建瓴還是基層壘起?
    01 產品的使用角色我們都知道B端產品是由很多角色構成的,不同的角色層代表著不同的利益層,訴求也不一樣。1. 老闆老闆作為最高決策者,當然希望軟體能給他增效減負,提高營收。但這是對內的,他們還有對外的訴求,比如如何讓客戶感知到他們的優秀,如何讓投資者聽懂他們的故事。