真實案例: To B產品體驗設計師,如何承接并驅動項目?

1 評論 5927 瀏覽 30 收藏 22 分鐘

筆者作為用戶體驗設計中心的成員,在接到了“帶動業務持續運轉和商業價值的穩步提升”的任務后,與團隊一起承接了絕大部分以往大家所認為的產品或運營職能,對核心產品的平臺側和業務側做一次運營和體驗優化升級。

入正題,設計有兩種價值輸出方式:一種是售賣設計本身(外包公司、設計全案公司、咨詢公司)、另一種是用設計思維售賣萬物(稿定設計、愛彼迎、蘋果),這是兩種截然不同的思維方式和價值形態,一個極度垂直,一個高度整合,同時也會將設計從業者帶向不同的職業發展之路,這篇實例文章將會圍繞它們之間的差異來展開。

一、案例

還是延續之前的敘事穿插方式:

最近公司核心業務事業線的產品和開發團隊變動非常大,資源變得異常短缺,我的老板(leader)突然找我,說:

用戶體驗中心在特殊時期必須進能帶動業務持續運轉和商業價值的穩步提升,退能找準自己的專業定位,持續輸出專業價值和協助業務目標達成……

如此云云,口吻沒毛病吧,很官方很老板對不對??

但我隱約覺察到用戶體驗中心充當“填坑辦”的任務要來了,那種感受就像捉奸一樣又興奮又忐忑。

慶幸的是我的團隊大部分設計師并不太排斥這種協作方式,畢竟互聯網行業屬于價值驅動型而非職能驅動型。忐忑的是切實能感受到前面的暗坑和不確定性很多。

這個世界有一部分人總能光鮮上場,長槍短炮、馬肥糧足的條件出征,另外有一部分人注定就是在缺兵少糧、困阻重重中負重前行(哈哈,我希望我的老板永遠看不到這片文章)。

果不其然,接下來在很長一段時間內,設計需要承接絕大部分以往大家所認為的產品或運營職能,對核心產品的平臺側和業務側做一次運營和體驗優化升級,該事業線沒有業務產品經理(目前國內大部分to b公司產品經理都是以技術產品經理為主,業務產品經理更多是銷售擔當了)、也沒有用戶運營崗,用戶體驗中心這個冠以建立與用戶溝通通道為天職的團隊,似乎理應承擔點什么。

事實也是如此,接下來團隊必須從需求承接方轉變為需求方,從專業支撐崗位轉變為項目驅動崗位。

也就是說,用戶體驗中心需要深入業務,在產品和技術的支持和協助下,結合市場和競品研究分析,自己梳理業務流程并確定預期目標,進而發現問題和優化提升點,形成系統產品需求執行方案,然后拉項目組立項并驅動交互、UI、開發、測試上線,最后驗證目標和效果達成。

當然,以往類似這種項目流程在頭部平臺的to c項目中比較常見,但在業務的行業壁壘森嚴和業務邏輯異常復雜的to b項目中的確非常罕見,因為一個設計類的專業崗位確實很難對to b業務認知和理解上做到全穿透,不是能力不行,而是信息的不對稱和權限的不對稱。

即便可以做到,但因為職業偏見,業務部門也不敢委以重任,畢竟平庸勝于風險。

以往我們團隊確實有過獨立發起并驅動項目的經歷,但都只限于現有產品業務邏輯基本不變,也不會有新的功能邏輯產生的情形下單純對交互、視覺和品牌體驗的提升,其結果的衡量標準也是以定性評判為主,行為數據變化衡量為輔,畢竟互聯網產品體驗設計很難擺脫業務,形成自己獨立的商業價值評價體系。

因為這篇文章不是定位為設計方法論,加上項目太細很容易被猜到東家是誰,會有打廣告之嫌,所以整個項目背景這里就不做細節贅述和配圖,簡單描述就是:

一個以往以銷售驅動產品研發來滿足客戶需求,且銷售為主動,產品研發為被動的傳統SASS業務模式將要面臨一次重大的商業模式升級,變成銷售和產品相互協同的雙驅動模式,但在現有業務體系下要達到以上目標,具體需要完成以下事項:

01 在官網平臺側

  1. 重新升級產品品牌調性,由原來的“數據改變世界”升級為以“滿足客戶價值為發展重心”,并開始官網和產品業務側的用戶的精細化運營,做好用戶分層和引導分流,最后促進意向客戶的主動咨詢和留資,這一點會偏to c產品用戶策略。
  2. 將以往售賣的散點產品功能包裝成行業客戶的解決方案,提升客戶的場景代入感,促進官網平臺的客戶轉化,提升銷售ARPU值。
  3. 進一步精細化真實客戶案例營銷,用大客戶真實案例,以更真實和數據化的案例分享形式來講述使用產品和服務前后效果差異,借客戶的口吻更可信。

02 在業務平臺側

  1. 還原客戶的行業背景+業務需求場景,通過客戶體驗地圖和使用行為路徑結構樹的行為數據,洞察客戶可能的潛在增值服務需求點,通過一定規則內嵌增值服務運營引導,將公司的亮點付費功能適時營銷出去。達到真正意義上的SASS產品的場景化運營,這里也比較類似to c產品的用戶場景化運營。
  2. 當然最后才是用具體的設計手法,將免費用戶和付費vip用戶的身份和服務的差異化營造出來,并用更加簡潔輕松的設計風格和和友好的運營話術來完成業務平臺側展示層的體驗設計升級。


看到這里,你肯定覺察到了兩個點:

  • 這并不高級呀,這不就是教科書式產品運營進化迭代方向嗎?
  • 這不是產品或運營應該做的嗎?跟用戶體驗中心有啥關系?

但這才是今天我要說的重點,用戶體驗設計從命名那天起就應該擺脫先天設計職能邊界限制了,純UI、UX設計是一種專業能力的表現方式,他們是一種專業價值方式的介入,而用戶體驗是一種客戶價值預期管理,是承載了客戶價值和商業價值閉環的,我們的職責是把設計思維和方法帶到產品體驗全流程甚至商業全鏈路的決策中去,如果只做設計表達,就是開篇時說的第一種單一價值輸出模式。

我們把劇情拉回到實際案例中,這里再補充一個現實困境的小插曲:

因為該業務發展歷史非常久遠了,且目前產品承載的業務邏輯和技術邏輯異常復雜,也存在一定的架構邏輯問題。再加上來來去去的產品和研發人員的流動,最終導致的結果就是,目前分管的各產品支線沒有一個人能徹底弄明白內在邏輯全貌,那就更談不上對于上面升級改造點的具體方案設計了。

對這樣一口飛來之鍋,用戶體驗中心該如何承接?沒有做過成熟to b業務規劃的設計師可能永遠無法想象面對一個系統黑盒的無助,說實話,設計師開始確實是拒絕和慌亂的。

接下來我會圍繞以下七個要點來分享我們具體是怎么做的,里面肯定有很多模糊的職責邊界,歡迎網友批評指正:

二、我們是如何做的?

01

體驗設計這個職業的能力要求是沒有邊界限制的,所以作為設計師,不用懼怕打破原有協作方式和職責范疇,這樣你的能力以后才有遷移價值。

什么叫遷移價值這里就不贅述了,可以百度。

舉個栗子,裝飾設計師或空間設計師這個職業,他們的工作方式并不是按照客戶的需求被動接單,然后用牛逼的專業設計能力做好人居環境規劃方案直接交付。

而是在前期充分溝通的前提下,整合客戶預算、風格喜好、材料成本、公司利潤等綜合條件限制,他的日常工作會深深的嵌入到前期銷售、中期工程施工,后期交付甚至售后服務全流程,而且在整流程中會恰如其分的嵌入增值服務的場景營銷,達到客戶價值最大化和公司利潤最大化的平衡,這不是設計,這是在經營。

回到這個項目一開始,負責該項目的設計leader很無奈的和我說:

我覺得以往的協作方式很好也很順暢和清晰,產品告訴我們需要做什么,我們就用心把他實現,職責很清晰,現在讓我們跨界協調所有環節,主導這個項目,真的會有很多不確定性的坑,這些坑不是我們能解決的……

但在我看來,這也許并沒有那么難,因為該項目核心價值部分并不是我們專業上的盲區,它不像純技術和數據解決方案,需要有專業背景,我們不需要對技術實現方式全盤了解,只需要了解大概原理就行,我們可能需要把大量的時間放在和產品、技術的頻繁討論并確認現有邏輯上,還有用戶訪談還原使用場景上。

但這個過程中我們獲得了完整業務形態上的規劃能力,我們獲得與用戶以及協作團隊的溝通能力,我們獲得如何連接并驅動其它團隊小伙伴一起合作的能力,我們獲得了挫敗后的堅持、獲得溝通中的相互尊重、獲得了用戶體驗邊際價值的自信,這些能力是可以平行遷移復用的。

02

要做好to b產品的精細化體驗設計,對產品了解的顆粒度必須達到業務邏輯乃至技術邏輯的全覆蓋。

因為這是設計中心第一次完整的規劃一個帶有預期業務目標的系統性項目,所以如何向產品和研發下需求(尋求幫助),這顯然是一個逆天的操作,過程確實是抓狂的。

第一,我的老板把鍋給了我們,注定主要壓力在我們,其他人沒有義務主動上心,不是說大家沒有責任心,這是職場本能反應,因為大家都很忙。

第二,面對復雜的產品黑盒,設計師以前是實現需求,不需要技術和資源支持,現在憑一己之力起初確實無從下手。

我們只有一個辦法,開通所有不同付費權限,以客戶的業務視角花大量的時間系統性走查全業務流程,統計并標記所有的潛在的可能的付費轉化觸點,把問題及時記錄,集中溝通和請教,就是通過自己花時間系統性梳理了業務邏輯之后,帶著具體的問題去請教,而不是給大家提開放式的需求,這樣才不會讓人反感,也會讓支持解答的人沒有那么大的負擔,這是一個溝通協作技巧,也是一個向別人學習請教的技巧。

03

要做好to b產品的用戶體驗設計,難度不在于設計細節處理和大家經常所說的to b產品to c化的方法論平移。

國內to b產品用戶體驗設計因為傳統銷售模式差異,之前確實沒被重視起來,前兩年也有過to b產品to c化的說法,但這個項目下來給到我的感受是,其實主要難度不在于to c的方法論平移,而是在于溝通和驅動整個業務鏈條的體驗價值認同和資源支持配合,從客戶側到市場商務,從前端銷售側到產品運營,從設計落地到開發交付。

還是拉回項目案例吧,我們有一塊內容的規劃設計其實是想結合客戶使用產品服務前后數據效果對比的真實案例描述,來提升產品品牌口碑和線上營銷的可信度,從原來的“我們能給你提供什么?”轉換成“他們用了以后,給他們帶來了什么樣明顯提升?”。

毫無疑問,這項工作用戶體驗中心是怎么都盤不動的,客戶詳情案例是需要客戶配合提供和授權的,沒有過硬的客戶關系和信任度很難獲取內容并授權,大家應該已經意識到,看似是一個案例升級,但事實上已經上升到了業務的品牌戰略高度了,可以理解為把客戶價值放在了企業戰略的重要位置。

怎么辦呢?不然就開展不下去了,沒辦法了,說服leader并寫份ppt吧,讓leader去說服CEO,從上層引起重視并安排下來,這件事情才能順利完成,我們的確是這么做的。

04

設計不是在資源充足的完美條件下做完美的設計,而是在限制條件下尋求盡量完美的設計解決方案

其實我們大多數設計師每天都在各種限制條件下做設計,同意的請舉手。因為條件真的完美了,設計就沒有那么大價值了。

回到案例,項目前期階段,設計師一邊走查一發現有諸多先天的歷史遺留邏輯問題,于是問道:“這么多坑,感覺根本執行不下去,能做嗎??”,我說“先不要過分擔憂,先動起來,動起來就能發現問題和尋求到解決方案”。

其實解決辦法就是先接受和包容這些坑吧,盡量用優秀的設計解決方案降低歷史問題對客戶體驗的影響,但同時也不是放著坑不管,過程中和產品以及業務相關人員商量后續如何徹底解決,就是項目繼續推進,設計過程還有個職能就是暴露問題,問題暴露出來,所有的解決方案才能在項目推進中產生。

還有個例子,對于包裝客戶業務場景的產品解決方案,目前產品團隊要馬上給出來確實很難,這是一個需要業務線和戰略層共同參與并討論才能決定的內容,怎么辦呢??等著他們提供內容了再繼續項目?不用

等,先按預設客戶體驗要求規劃好內容結構示例,并形成設計解決方案,帶著解決方案讓老板們做選擇題或填空永遠比讓老板自主命題完成整篇論文要靠譜。

05

少即是多,學會接受用最簡單的設計處理來解決業務需求中的復雜問題,不是設計改變越大價值就越大。

少即是多這個理論在交互設計原則上有經常用,但在這個項目中體現的尤其突出。

設計師在項目初期問我,這個需求會不會吃力不討好,費老勁做了那么多基礎工作,可能最后老板發現并沒有太大的改變,也沒做啥新的顯性設計。

我本來不想把這個點引進到文中,但這確實是一個經常會犯的原始的認知錯誤,和看程序員寫了多少行代碼來評判他的績效如出一轍,其實to b產品的設計價值評價標準真的不一定是以數量來取勝,比如你要是能用最少的一套設計標準解決所有具有共性的中臺業務線的前端展示層,那就真的是無上功德了,就像ant-design,但這里更想表達的是設計背后支撐和依據是需要大量的前期基礎研究和分析,設計輸出只是最后的呈現狀態,和無印良品的極簡工業設計底層邏輯是一樣的。

06

虎頭龍尾,第一個小迭代設計方案盡量完美,先讓老板看到一個好的開始,你給老板希望,老板可能會幫你提高結果預期。

這不算什么大的設計策略,就是切身體會到的一個細小妙招,你給了領導/老板一個好的開始,即便不是完美的結果,也會堅定他們的項目信心和結果預期、會給予更多的時間和資源的支持,給你掃平阻力,你會推進的更輕松,那么期結果必然會大于預期。

因為領導開始委任給你這個項目的時候可能是一個相對選擇項,只有你給他足夠的信心之后,才會堅定他的絕對選擇項,真正好的團隊,不是一個獨立造車,而是能把領導裹挾進你的項目中,為項目成功在上層力量上加持,因為顛覆性的項目過程中不可能一帆風順。

07

別忘了,每一個大項目的迭代都要做好結果預管理和價值評價標準,以方便最后做成果檢驗和復盤迭代。

結果預期和評價標準是未來項目迭代調整的唯一依據,不然做項目就是拍腦袋,這在一個正經的to c項目中是最基本的標配了,但在to b產品中,因為數據樣本可參考性和歷史發展的差異大家都避而不談,但數據有相對價值和絕對價值之分,to b產品的用戶行為數據雖然對營銷沒有那么大的決策性價值,但對用戶潛在行為傾向性也有相對參照價值的。

很幸運,該項目的設計負責人對項目數據埋點和上線后的數據結果統計意識非常強,也愿意直面自己的工作成果的真實用戶數據反饋,此次升級是希望能將一個潛在的付費用戶從進入官網平臺,到注冊免費用戶,再到咨詢商務,再到銷售跟進到CRM系統,最后到正式使用服務并適時引導升級額外增值服務付費轉化的完整用戶漏斗。

所以,你想讓to b產品體驗設計在價值之路上一路打怪升級,那么,你就要敢于承擔真實的業務數據結果,敢于面對待質疑批判,學會對結果負責,是你做好用戶體驗價值設計所邁出的第一步。

最后還是草草總結截稿,世上本無柏林墻,都是自我設的防??!設計師不是只會擼圖,在特定的情況下,你的潛能可能會遠遠超過你自己的預期。

請不要低估自己,跟我一起,用實際的項目案例持續觸碰傳統體驗設計的價值邊界…….

 

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

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 和作者經歷相似,說到心里了,點個贊~

    來自香港 回復