TO B產品交互體系一次性推翻重構，代價很沉重

也許大家已經覺察到最近幾年產業互聯網需求激增，即所謂B2B或SaaS、PaaS、VaaS等，對企業級用户在互聯網+技術上賦能的To b類產品或服務，這也是互聯網科技行業的行情輪動。

與此同時，很多大廠也開始擲資切換賽道。

當然業務決策的切換是瞬時的，但業務能力的切換卻是需要一定的調整和適應週期的。硬切換的過程中多少都會犯To c模式下的習慣性錯誤，話題太大，這裏還是想通過聚焦到個別細分實例，聊聊在產品體驗設計過程中容易犯的錯誤點。

既然是講To b，就免不了結合其對照組To c一起來聊， 這裏先講一下二者的三個概念差異：

1. To c產品是現實生活的映射（簡單的、有結果預期的），而To b產品卻是一個複雜的工作台（多線程的，不確定性的）；
2. To c產品滿足的是人們現實生活中已知需求或其升級版（是一種消費、社交娛樂行為或其形式的升級版），而To b產品滿足的是社會化大生產的複雜協同和創造性需求（他本質是一種生產行為）；
3. To c產品設計需要具備社會行為心理模型（是一種標準化行為模式），而To b產品設計需要具備的是紛繁複雜的行業知識和業務場景（是一種行業差異化行為模式）。

這是二者在交互體驗設計乃至業務模式設計上的本質的差別，消費行為面對的是社會個體，而社會個體行為具有規律性和趨同性。用户行為和決策模型相對比較容易捕捉，所以To c產品體驗設計在經歷過相當長一段時間沉澱以後會形成一致的羣體性認知。

這樣對To c業務的體驗設計成本也會大大降低，比如我要給對方發一段語音，我就知道要長按實心圓圈按鈕，我要刪除list頁中的某條記錄，我要麼長按（android）要麼左劃（ios）list項呼起刪除按鈕。

所以大家會發現最近To c的設計重複執行類需求會越來越少，這也是To c的界面和交互設計師現階段會出現供需瓶頸和需求錯位的主要原因。

聊完二者之間的差別後，就進入正題了，產品改版在To c行業應該是家常便飯了。

以前在騰訊做產品設計的時候，迫於數據kpi壓力，業務團隊有個不成文的規定，產品必須做到一週小迭代、一月大迭代、半年小改版、一年大改版，目的是為了變着花樣提升用户體驗和滿足不斷升級的c端用户需求。

因為To c業務往往解決的是生活中點對點的確定性需求，所以產品需求和交互流程相對比較簡單。

比如我要用共享單車，核心需求就是騎車到目的地，所以我們在app上的正常交互流程就是：打開app——找附近的自行車——開鎖——騎行——關鎖結束服務——支付費用——退出app。

這個流程叫服務主流程，就是説該交互流程能完全滿足你的核心剛需。

所以To c類的產品保持週期性高頻改版對用户的體驗並不會有太大影響，加上有升級引導的加持，一般都能做到傻瓜式的學習成本並瞬間適應，但To b業務就完全不是這樣了。

最近公司服務於開發者的一款SaaS產品面臨一次改版，計劃對重點產品的核心功能（更準確的説應該是高協同性的核心功能矩陣）進行用户體驗上的升級，理由有三：

1. SDK集成方式上，以往是使用什麼就集成什麼，任君選擇的佛系設定，預期調整為批量一次性集成sdk方式，為未來服務升級和推廣降低下載安裝和配置成本（因為所有服務必須事先集成sdk才能實現），該需求出發點是沒有問題的；
2. 優化推送服務流程，豐富化各種人羣定向、提高送達率的配置項，使其更符合運營增長需求場景；
3. 增加數據統計和分析能力，用數據能力持續優化運營增長。

這看上去沒毛病也很合理。但經過一個星期的金品分析和潛心打磨之後，拿到產品需求後才發現，原有的產品交互邏輯全部被推翻了，就是説出了底層數據和功能邏輯保持不變，展示層形態和交互流程完全推翻了，基本從零重新搭建了一套，看上去有零有整有細節，方案還特別結構化，從細節上堪稱是一份教科書式的產品需求文檔；

但在用户體驗體驗委員會評估環節，設計環節提出了諸多異議，

1. 這一次改版缺乏目標價值指標（或者説是目標太泛太宏觀，很難關聯到具體工作上），上線後無從評估好壞，沒有衡量標準就不知道下一步的迭代方向；
2. 沒有前期工作，憑一己之力輸出的產品方案，是否有信心完全顛覆經歷4年多沉澱下來的用户使用習慣；
3. 在沒有形成用户價值依賴，也無從保證客户需要高昂的切換遷移成本的前提下，如何防止產品體驗的繁雜低效導致用户流失，切換到更簡單易用的友商競品去；

到這裏，你肯定會好奇後來是否叫停了該版本的推進呢？

這個版本最終還是推進下去了，畢竟產品是需求的決策環節，用户體驗中心可以提出合理化建議，但是否採納還是取決於產品經理自己，因為是產品團隊為結果負責，此處省去500字。

結果上線後離預期相差甚遠，用户一次性集成sdk任務完成率很低，新增用户集成、配置並完整完成第一個業務類任務成功率大大減少、客服接聽率倒是明顯增多、新用户轉化漏斗衰減嚴重；老用户線上負面反饋增多（無用功能和信息太多，產品不友好），最糟糕的是一個全新的版本上線後發現不符合預期，接下來完全不知道該怎麼做了，只能版本回滾。

這裏沒有幸災樂禍的意思，因為行業以往絕大部分To b產品經理是沒有To c的經驗的，對用户體驗影響沒有那麼強的感知。

設計和產品本就同在一條船，一損俱損，此處引出該實例純粹是為了準確給大家診斷和分析問題所在，並告誡同行小夥伴如何規避。

篇幅有限，我儘量濃縮，對此次經驗總結如下：

1. 產品錯了，體驗再好也是沒有價值的，所以體驗設計價值必須依附於產品價值。如果你認為你是對的，就堅持下去或者一杆子捅到更高的決策環節，在一個錯誤的前提下做正確的事情本身沒有意義；
2. 介於To b產品的業務複雜性，對用户習慣的敬畏就是對客户場景和行業壁壘的敬畏。我們個體的同理心和經驗複用無法代替To b用户真實需求，這是無論產品還是設計都很容易犯的下意識錯誤，總認為自己最懂客户；
3. 一個複雜產品的全新版本硬切換是一件高風險行為，你首先需要做大量的前期調研、評估、甚至和銷售一起拜訪客户，以驗證你的版本需求階段合理性；然後你還要去接觸真實使用者來評估其易用性影響，因為上面説了To b產品是生產場景，生產就一定要追求效率，工作效率雖不是核心價值。但一定是客户的永恆不變的價值，最後你還需要拆分你的大版本成為局部功能分開來迭代，適時驗證、逐步替換；
4. To b產品的改版也要有明確的價值目標，他可以是明確的業務指標，沒有業務指標也要有用户數據細節指標，沒有細節指標也要有價值衡量標準，SUS價值量表也好、NPS衡量也罷，沒有目標就是沒有方向，改完以後無法保證其後續迭代的延續性；
5. To b產品的To c化，但凡是帶有任何To c屬性的產品（有自然流量和海量免費用户，且有免費向付費轉化的產品），就必須做用户精細化運營設計和灰度樣本測試對比，因為免費用户就是潛在的未來付費客户池，你不能只關心正在買衣服的，而不關心試穿的；
6. To b的體驗設計滿足的不僅僅是友好性和舒適度，其實最大的價值在於設計一套生產和工作協同流程，他是帶有專業的業務視角的，並引領客户達成不同的業務目標；
7. To b類產品體驗設計一定要服務於提升業務的切換和遷移成本，設計是可以被被模仿和替代的，產品功能也很容易被抄襲，但與平台核心能力的依賴度，以及產品矩陣的之間的價值協同性，才不容易被輕易替代，從而提升留存、降低流失風險、也降低銷售續單壓力；
8. 數據報表設計是一個很難界定價值大小的功能模塊，你可以直接把用户和業務數據都採集並矩陣式的展示出來供用户去分析查看，他也有價值，但這太1.0時代了，優秀的數據報表篩選是要能直接關聯明確的業務目標的，且能輔助決策並儘量縮短決策鏈，提升決策效率和決策準準確性的。

所以大家會發現，一款To b產品或系統的改版升級，一定是一個非常複雜的協同和嚴謹的論證過程。

為了不影響客户的正常生產，還要保持分佈式迭代驗證，直到最後的版本整體替換，到最後其實你會神奇的發現，最終的形態已經不是當初的模樣了，這樣才是To b產品的精益設計的過程。

本文由 @咕咕咕 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議