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

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

一、案例

還是延續(xù)之前的敘事穿插方式：

最近公司核心業(yè)務事業(yè)線的產品和開發(fā)團隊變動非常大，資源變得異常短缺，我的老板（leader）突然找我，說：

用戶體驗中心在特殊時期必須進能帶動業(yè)務持續(xù)運轉和商業(yè)價值的穩(wěn)步提升，退能找準自己的專業(yè)定位，持續(xù)輸出專業(yè)價值和協(xié)助業(yè)務目標達成……

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

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

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

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

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

事實也是如此，接下來團隊必須從需求承接方轉變?yōu)樾枨蠓?，從專業(yè)支撐崗位轉變?yōu)轫椖框寗訊徫弧?/p>

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

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

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

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

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

一個以往以銷售驅動產品研發(fā)來滿足客戶需求，且銷售為主動，產品研發(fā)為被動的傳統(tǒng)SASS業(yè)務模式將要面臨一次重大的商業(yè)模式升級，變成銷售和產品相互協(xié)同的雙驅動模式，但在現(xiàn)有業(yè)務體系下要達到以上目標，具體需要完成以下事項：

01 在官網(wǎng)平臺側

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

02 在業(yè)務平臺側

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

看到這里，你肯定覺察到了兩個點：

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

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

我們把劇情拉回到實際案例中，這里再補充一個現(xiàn)實困境的小插曲：

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

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

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

二、我們是如何做的？

01

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

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

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

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

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

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

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

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

02

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

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

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

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

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

03

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

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

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

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

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

04

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

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

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

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

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

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

05

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

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

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

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

06

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

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

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

07

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

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

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

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

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

請不要低估自己，跟我一起，用實際的項目案例持續(xù)觸碰傳統(tǒng)體驗設計的價值邊界…….

本文由 @咕咕咕 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議