top of page
Writer's pictureMolly

How B2B and B2C Product Design Differ

Updated: Dec 9, 2020

因近來朋友提到B2B的產品人似乎比較難找,加上我在加入AI領域的學習後,許多產品皆是以To B為面向,觸發我想藉此梳理一下這個題目。我認為「B2B和B2C的產品設計之間有何區別」與「To B產品的困難點在哪」、「To B產品為何時常更複雜、更充滿挑戰性」可以看作是相同的命題來一起聊聊。此外,我認為在討論差別性之餘,異中求同也很重要,無論過往有沒有To B背景,同理心的實踐才是產品人最核心的能力。


What is "To B" and "To C"?

企業對企業(B2B)(Business to Business),也稱「公對公」,指的是企業間透過電子商務的方式進行交易,企業利用網際網路來支援企業與企業之間各種買賣的資訊流、商流、金流、物流的經營流程與架構,相對於B2C(Business to Consumer)的銷售方式是企業對顧客。——出自維基百科

To B的時代來臨


一提到To C的產品,往往能夠輕易地舉出大量實例,並感受它在時間推移中美感體驗的進程;反之,To B的產品卻予人一種只著重於實用性的形象,甚至「通常不太好用」已成為某種刻板印象。整體來說,無論是哪個角度,似乎對它的著墨都遠遠少於To C的產品。種種因素令To B產品的討論聲量一直相對不足,對於Product Manager、Product Designer、UX Designer等職位的人來說,在推行專案時,也不似To C的產品有著豐富的參考對象。


然而,近來對於「To B時代是否已經來臨」也逐漸有人敲起響鐘,例如2020年10月12-15日在第二十屆中國股權投資年度論壇上,創新工場董事長及首席執行官李開復便以《中國迎來To B創業的黃金時代》為主題進行了演講,對於這樣的看法有興趣的人也許可以以此為起始,再順藤摸瓜地開展自己的想法。


To B產品的設計難點

  • 使用者不是一般大眾,而是要解決某領域問題的專業工作者

在設計產品時,情境假設往往可以從自身經驗出發,這也是為何養成觀察日常生活和整體趨勢的能力非常重要,但對於To B產品而言,其功能是為某一專業領域提供服務,此時domain know-how便顯得格外關鍵,需要對使用者進行更扎實的前期調研。


如果在調研階段,能推敲出那些沒有從使用者口中說出來、但卻無比重要的細節,更是成功的關鍵。沒有從使用者口中說出來的原因有許多種,可能是對於這些專業工作者是十分基礎的事項,所以他們沒有特別提及,也就是描述得不夠全面;也可能是因為其他的資訊落差,譬如這群調研對象不足以代表全體,導致最終產品變得好像只是為這群人量身定做的。

  • 難以接觸到使用者

以上描述的還是我們接觸得到使用者的情況,更多時候,我們很難接觸到特定領域的專業工作者,尤其這個基數還得夠大。在這樣的情況下,時常讓設計To B產品的調研工作不夠完善,而錯失關鍵的domain know-how。此時數據追蹤系統的建立十分重要。對於能連網的To B產品,這個問題可能還比較好處理,畢竟連了網就能討論各種回饋機制的設計,起碼獲得數據不是個問題,之後要做假設驗證就能一步步來完成,進而改善問題;不能連網的產品就相對困難了,雖然利用年度更新這類接觸的時刻,也能順利取得使用者數據,但頻次上仍然不夠,需要依其產品性質尋求更多解法,其中尤其需要工程端的技術協助。


總地來說,面對To B產品的數據,我們更傾向在其中挖掘出如何增進Usability,而非再挖掘出使用者的其他需求,當然這跟我們能取得的數據有關,也跟我們對於To B產品的期待有關——能協助專業工作者更正確、迅速地處理「特定」問題。

  • 設計邏輯的改變:工具型產品特色——快狠準才是使用目標

讓我們先回憶一下熟悉的To C產品,我們希望的是使用者可以常常使用、每回可以用久一點,時常還得想一大堆機制喚醒使用者回來使用;To B產品就完全不同了,我們希望它有效率地協助使用者得到準確性高的結果,每回使用都應該是一種快狠準的體驗,而且使用者通常必須在工作環節中使用它,一般不需要苦惱於如何施法召回他們。


鑑於以上兩段對比,可以知道兩者在設計的邏輯上完全不同,自然擁有不同的評價方式/ 資料指標,產品人需要了解自己的產品,判斷怎樣的指標對於當前產品是「有意義的」。資料指標有很多種,找到對自身業務有意義的來觀察才是重點。例如討論To B產品的跳出率、退出率意義並不大,更應該討論完成任務的成功比,和每回協助完成任務耗費了多久時間,以及任務的準確性是否提升。這也是我後期開始偏好To B產品的原因,它著重於功能本身的不斷提升,像是許多To B的AI產品,目標就是不斷提升模型的準確度,實在是一個非常迷人的過程。

  • 使用者不是購買者,重新思考Usability和Sales Process

To C產品的使用者和購買者往往是同一個人。這句話很好理解,直接面向顧客的產品,顧客在購買的同時直接成為使用者,因此我們要滿足的對象非常直觀,To B的產品可就大不同了,當購買者只是中間決策者(花錢決定要買的人),而商品不是這個決策者直接使用時,問題就麻煩了。主要有兩個面向需要考慮:Usability和Sales Process。舉幾個例子可能比較好理解。


其一,假設今天公司需要採購系統,好用固然很重要,但是最後下購買決策的人可能是老闆、行政部門、主管,或是其他任何角色,Usability還是考量的第一位嗎?如果不是,除了產品是否好用之外,要如何說服決策者購買?這就引發了Sales Process的問題,雖然傳統上這看似是Sales和Marketing的工作範疇,但如果產品人能在設計階段發揮更多同理心,加入巧思吸引決策者的眼球,才是推動To B產品真正的動能。


其二,這是來自我生活中的一個小故事。某天我網購了一幅客製化拼圖想要完成後作為禮物送給家人,上面有美美的全家合照,隨拼圖附贈的還有專用膠水、刷澆水的刷子和邊框,但是這些工具都難用到不行,而當時正是英國封城期間,要再去買這些物品並不是這麼便利,於是我在網上的評價只給了三顆星,外加一小段抱怨,最終還是客服人員得安撫我這名不滿的消費者。這裡我看到的是,一個做客製化的拼圖印刷小店,採購了那些難用到不行的工具搭配他們自身的產品,最後一起來到我這個使用者手上。這讓我想到Evonne Tsai在她這篇文章提到下面兩段話,非常觸動我這個Product Manager背景的人。

易用性(Usability)在B2B產品的價值反而是,減少客人犯錯的機會,減少客訴,以及公司支援的負擔。
易用性(Usability)是在公司支援層次有減少成本的商業價值,這些加上技術核心整體才是完整的產品的體驗設計。

可以看到在忽略Usability時,決策者反而需要付出更高的成本。Example 1 是因決策者採購了Usability不足的產品,導致效率低落,產能因此不好,需要更多人力來彌補;Example 2 也是因「不好用」而發生了客服成本,甚至行銷人員也需要花更多心力去了解為何產品只拿到三顆星。以上都是可能避免的成本,它們並非隱形的,但不得不說,在秀出實際多耗的數字前,似乎很難排在待辦清單的前幾項。

  • 如何融入現有情境:「人」的因素很重要

過往的經驗中,To B產品的討論大多始於決策者,目標無非是對現有流程進行數位化、系統替換或升級。其中第一種恐怕是陣痛期最長的,畢竟數位化轉型已是另一個層次的問題,通常情況下,基層人員並不樂見數位化轉型,因為這代表著他們可能要學習新的工具、改變原有流程,甚至成效將更血淋淋地紀錄在這個產品上,此時要開展這樣的產品可不是件易事;此外,在系統替換或升級的情境中,產品的變革可能引發基層人員的不適應,反而令效率低下、生產力降低。在這樣的背景下,產品要如何融入現有流程,最大程度地尊重使用者習慣,讓其能夠流暢的入手,同理心的發揮絕對是關鍵的一環。


在實務中,如果對於產品設計仍有某些「堅持」,別忘了在B2B關係的銷售及維護階段,許多產品都有機會透過窗口、甚至說明會,將未來產品規劃呈現給客戶,此時,就是讓數據說話以獲得決策者(購買產品的人)支持的絕佳時刻。這也是進行客戶教育的過程,以積極面溝通的好處就是,即便最後成果需要一定時間重新適應,使用者大多也願意自我要求、想辦法上手新的產品/ 版本。


因疫情帶來的To B趨勢

因為這次疫情,協助work from home的產品也愈加蓬勃,身邊在家工作的友人們也開始天馬行空地發願(說不定新的business model就在裡面了!LOL),相信生活型態的大幅改變,的確更加催生了To B產品的需求和樣貌。設計都是以人為本的,無論中間經歷了怎樣的變形,產品在處理的最終都是人對接人的活動。無論職稱是Product Manager、Product Designer、UX Designer還是UI Designer,跳脫本位,換位思考,甚至有時能補位,比起強調各個職稱的專業,我更喜歡說我們都只是產品人。



參考資料

https://m.pedaily.cn/news/460906

https://evonneyifangtsai.medium.com/b2b公司做ux有用嗎-5b0a616c5eee



0 comments

Recent Posts

See All

產品改版的完整歷程

這裡的改版,指的是UI/ UX的年度調整,意在提供更符合趨勢的使用者介面,以及更順暢的使用者體驗,當然也可以藉此機會加入新功能,但我認為這不是主要目的。另外一個關鍵是,趁此機會將整年累積的「債」清理一番,無論是技術債,還是當時任何「不得不」的設計方案。...

Comments


bottom of page