B端產品心法(1):如何設計B端產品,且讓用戶愿意用?
本文將從B端產品的用戶角色定位以及用戶體驗入手,分享了如何讓用戶樂意用我們的產品。
前言:
家好,我是老諸,好多年沒在寫東西了,我還是我,一向喜歡用大白話寫產品思考分享的我又回來了,因為嘛,做B端產品這么多年了,很多產品一出來就得到了用戶很好很適用的肯定。其間有建筑行業,醫藥企業。雖然有兩次差點能在這個領域里切出一個不亞于阿里的生態產業體系,也搞出過建筑行業的像支付寶這樣的關鍵樞紐APP產品及能支撐其的后臺,ERP。所以,我的B端學生朋友們總是催我寫一篇關于如何做好B端產品設計的文章,希望能分享我在這行的思考。
先,我認為優秀的B端產品人的視角應始于宏觀,行于微觀,而在產品設計中沒有什么終結,只有業務的階段需求下的“適可而止”。
這個原則下,才會找到B端產品設計的正確合理的思路。而讓B端產品設計變得更簡單,也更容易快速切中價值入口,針對這個要求,及對學生及部員的要求,我整理了幾個B端產品的一些關鍵問題:
- B端產品怎么設計?用戶憑什么會用你的產品?
- B端產品的形態:ERP,CRM,后臺,中臺,及C端業務產品APP?小程序?
- B端產品的真正價值是什么?大數據?價值鏈條?利益關系?人脈關系?
- B端產品有什么發展?及怎么發展?市場有多大?
- B端產品更大的價值:生態鏈關系,產業格局。以格局觀看B端產品設計。
- B端產品引入區塊鏈有啥發展?合適什么行業?引入區塊鏈的幾點可行的實際業務設計。
- 怎么建設生態圈及形成自己的生態壁壘?
在多年C端,B端的工作中,我一直覺得做B端比通行的沒有目標盲目的C端容易得多,因為B端每個用戶都有其明確的預設立場。不像肓目不清的C端,你都不知道用戶想要什么。有了預設立場,那么用戶想要什么就自然好分析出來了。
但是B端最麻煩的是業務復雜性,業務一多了反而把自己搞亂了。
B端產品怎么設計?用戶憑什么會用你的產品?
這個問題,我們先看前半段B端產品怎么設計?
這個問題一開始看好像無從下手,但只要搞清楚產品給誰用,什么人用,怎么開始用,那這個問題就簡單了很多。所以我們要先明確產品人的三個基本設計原則:
- 先要搞清楚你的用戶在哪,是啥,長啥樣,要達成什么目的。
- 你的產品怎么幫助用戶達成目的。
- 做這事對產品對公司有啥價值,能不能找個平衡點把這事做成了,還能為自己帶來價值。
具體參看:《好產品只幫用戶做好一件事》
B端的用戶角色如何定位?從哪開始?
答:你幫用戶解決什么業務流程的問題就從哪開始。
這時我們一般會先畫清楚業務流程,或是設計出來吧。我先隨便找些B端業務,可能相關的角色與部門都會非常多。業務內容可能也不少。截取兩個簡單的例子來給大伙看看:
例一:
例二:
相信很多人其實都是從業務流程著手,雖然這是如此的正確,但業務流程其實是可以換個簡單的分析角度,以組織結構來考慮的。
所以我們可以將上邊的業務關系分成幾個維度來看:業務中的組織關系、組中的權利關系、相關角色權限及權限的領域。
思考法:
B端的用戶無非是達成一個他在商業或工作中的目的,所以其職能及在企業里組織里的角色定位要搞清楚。而任何一個組織都有相似的目的導向,那就是他要完成自己所在環節的任務。高效并明確有質量的把經手的東西或事情推到下個環節。
我們先看看一般的組織結構:
組織基本上,都是樹狀的。一個節點下幾個分枝,某個分枝下還有分枝,組織越大,分枝越多。
如果一個業務需要經歷非常多不同的組織節點時,是不是業務就會變得非常復雜?每個環節都需要搞清楚?
其實這個擔心是不需要的。因為任何一個組織無非只有兩個:上級發布命令并審核推進情況。下級執行并反饋執行情況。
所以我們可以簡單的拆分,最上層領導,看的是事情被推進的情況及對事情進行評估。自然會產生相應的手段。而下層,自然是推進這個事。被上層監督與審核。
這就是B端最原始的設計思考的開始。然后將最上與最下以不同業務維度展開,加入中間層,中間層要滿足上下關系,在這之間做好自己的環節。那么你會發現,其實角色的定位思考就變得非常清晰明確了:
怎樣的角色,設計圍繞業務的什么功能,角色間發生什么樣的關系,功能如何體現,而功能的合適標準則是這個功能的業務產出上中下游內容是什么,哪些人負責哪個業務段(領域),哪些人做為這個業務段(領域)中的執行與監督,或是接口人、審核人。定義好相應可以看見并操作的功能。即可。
(小結:任何組織必要有絕對上與絕對下兩層,組織的業務多了,依業務情況自然會產生中間層。中間層。哪怕組織有非常多層,也可以先簡單的以上下層關系來推導出業務中的不同角色關系。及其在業務中的定位。)
而這種思路可以適用于非常多的領域,包括醫療、基建、教育、軍事、政府、黨組、公司企業,各種組織中的業務整理。這是個將組織關系化簡單的一種方式。
(其間復雜的其實是中間層的層層關系復雜性。但是同樣可以看成是組織中的角色權利在一個業務中的簡單的上中下關系)。
所以,我們可以清楚的整理出在產品功能設計上的兩個必須有的性質:供需關系。發任務與收任務、監督與執行。以這個為骨架原則設計功能,就能很好的把握住用戶的定位。
比方上邊業務流程圖 例一 中:
簽合同的業務吧,普通客戶與業務這兩角色產生詢單業務。發起是客戶,但業務要提供相應的資料。之后客戶下單,下單消息傳給“物流/倉儲/采購”,財務要確認這個單子,要審核要擔保。
所以相應的功能與業務。出現在哪個階段,給什么人看,一目了然。這里需要向后臺,或是平臺數據中心發送什么樣的數據做關鍵記錄也非常清晰。
這樣前端功能如何設計,缶后端傳什么,后端應該有個什么界面或功能要處理什么,及當前相關的角色方便在什么樣的終端上處理這些業務,當前用戶合適在什么場景下去操作?可以兼容哪些場景及操作的平臺?如何保證執行的效率與信息傳遞的效率加質量?產品形態是什么APP還是小程序,PC上的工具還是WEB工具?,你看,確定這個B端產品是什么樣的是不是自然就很容易整理出來了。
用戶是誰搞清楚了,怎么設計產品解決他們問題這也有了,接下來討論下一個問題:
用戶憑什么用你的產品呢?
這就要回到產品的根本——“用戶體驗”這個問題上。(了解用戶體驗本質,具體參看:《最濃縮的概念:什么是用戶體驗,用戶體驗設計怎么做?》
用戶的體驗是多層次的。很多時候他說不清楚。但是能在使用的過程中去感受到。很多產品功能設計沒問題,但體驗這環就不知道怎么做了。如果光是停留在好看、用色、美觀、易懂易學這個層次上。那基本上可以算是碰運氣了。
所以在體驗上,怎么說服還是要回到設計的相關業務的本質上:讓用戶用第一次,第一次的感覺決定用戶憑什么會用你的產品。當前業務的重點。用戶在做這業務的時候,內心時刻想知道想看到想觸及到的是什么?
(當用戶不知道你怎么讓他知道呢?
答:廣告呀,通過關系介紹下,用戶自己找呀,群內推廣呀等等營銷手段我就不說了,總之,用戶不知道你產品的時候自然沒辦法用,重點是是當用戶第一次知道你并用了你的過程才是憑什么繼續選擇用你產品的開始)
所以,我們還是回到業務本身。如果是以客戶開始,那么要想清楚,客戶憑什么會開始進入,并愿意點下一步。我們需要把最開始的環節做為關鍵去思考。
客戶第一步是詢單,這里需要非常明確的是——詢單發生時,到傳遞這個信息,如何高效的傳遞到業務上。那么,他想要的自然是業務給的回饋信息。如果在這個階段,由人完成,則要提供非??斓臋C制,讓用戶一發消息,業務人員就能快速跟上。
那客戶是詢什么單?怎么詢單?這個就成了產品第一位要考慮的事。買東西?問價格?是問什么產品的?在什么情景及場景下問?
在這里,我舉一個采購型電商的例子:
當一個客戶發生詢單時,一般會快速的將這個用戶當前是在什么店下什么場景下的什么商品,及問的什么相關信息,一并快速發給業務人員。(更好的是將當前客戶的其它業務行為參數,是否瀏覽相關商品的可購買性評估也傳遞給業務人員)。
并快速從數我據資料庫里將相應的常用詢單信息,幾個版本的不同信息,發給業務,由業務與客戶間的對話,快速的做出回應。
不要讓客戶等待,不要讓客戶不耐煩,讓用戶快速的得到自己咨詢的答案,則是體驗的最基本要求。
這里我們可以再拆分:客戶需要的的是業務能快速回答詢問的答案是否滿意。業務需要的回答客戶的資料快速及可掌控的隨機應變,并能引導到下個環節。
而讓客戶達成目的,則業務需要先具備相應的可控條件。這是體驗在這環節中最關鍵的地方。
那如果機器化完成這個環節呢?沒有業務人員。只是客戶發出詢問,機器能不能快速取得相關信息并快速反饋出相應的資料答案呈現給客戶?那這個就成了產品設計中另外一個需要考慮的分枝??傊?,做為第一位的客戶而言,快速明確直接的拿到滿意的資詢問題的答案是客戶會不會再來第二次,并愿意繼續使用你的工具的前提。憑什么,就是來源于這個基本體驗后的感受。
所以,在視覺層,讓用戶優先看到什么,怎么看,哪個區域看,多大面積看,怎么設計才合適,應該傳遞多少份量感?這時體驗設計才有譜。在這個根本下,體驗設計的達標要求才能明確量化。這也是說服用戶憑什么用你的最好也是唯一解釋。
分享一個體驗層設計的技巧,適用于所有給人用的終端,供大伙參考
首先體驗設計的原則是:一切要圍繞用戶的當前事物價值的份量感知來設計。
很多初手人都會認為用戶在使用中,體驗好就是“瞬達瞬達瞬達”。因為這里要技術,要網絡,要各種東西體現軟件或工具的響應與反應快,這樣做好的才是好。對吧?
其實這是個沒錯但是會有誤的理解。
有時,在關鍵的一些環節,適當的讓用戶小等一下,哪怕技術能做到瞬達,也讓用戶小等(看情況來定義是0.5m/0.75m/1m/…)這樣子,反而會讓用戶感覺你平臺是可靠的。
因為真正的體驗設計是傳遞的是一份“份量感”、一份“態度”。所以,并不是所有業務流程中都是做到瞬達這才是把握用戶使用你的B端工具的關鍵體驗設計點。
總結一下
總結前邊說的,B端產品人要始于宏觀。全面的看問題。雖然是以業務做為切入口,但看的不光是業務表面的問題,而是多個維度的價值層的綜合問題。
行于微觀則是把一個業務切片,一個大業務無非可以按供需關系切成一段一段的看問題,設計好合適的片段。讓用戶每一段過程中體驗都要良好。每一段用戶達到了價值,他就爽到了。
而沒有終結則是,任何業務都會隨著業務的進展及變化產生更多的內容,要不斷的更新迭代,陪著用戶在使用中成長。讓用戶繼續不斷的爽。
這樣才能一步又一步的從第一次體驗到說服用戶用你的產品,再到離不開你的產品發展進步。
好下一篇,我們開始針對第二個問題開始新篇章~~謝謝
#專欄作家#
TomZhu,人人都是產品經理專欄作家。主攻社交和社會心理學。擅長原型設計、需求挖掘,做過ERP、社交和教育產品。不喜歡中國式爭論,不喜歡參與勝負之爭的所有行為及活動。微信公眾號:xz_studio1977。
本文獨家發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于CC0協議
沒有留下聯系方式,差評 ,咋聯系做著呢!!!!
您好,請問可以用這個例子詳細的闡述一下 從需求到功能到最后原型設計的過程嗎?
目前正在做B端產品的人表示,這是一篇絕對的干貨,非常感謝作者。
目前正在做B端產品的人表示,這是一篇絕對的干貨,非常感謝作者。
目前正在做B端產品的人表示,這是一篇絕對的干貨,非常感謝作者。
請問您的泳道圖是用什么工具畫的?
請通過點我頭像,訪問主頁查看:
第二篇
第三篇
后續文章被限流,請通過查詢查看。
感謝分享
去年跟老諸認識的,其實他寫的文章講的話我當時都有點看不懂,現在做了一年多的B端產品經理,能真正體會到他講的一些問題了
一年多聽不懂正常,可學呢孩子
tob產品經理如果僅能做到照本宣科的照搬業務流程(線下copyto線上)
你會發現無比累,業務流程天天變,缺乏靈活度的設計和規則視角的你會天天疲于奔命,感覺身子被掏空
大白話挺好的
服務根本是在人!其實一旦明確業務c,b沒有什么區別!
歸根到底都是服務c端,所以抽空替他們想怎么能服務好c端
仿佛是一篇C端的文章