如果你是一個 B 端老鳥，那你一定清楚上線一個新版本、新功能究竟會有多痛苦。

比如很多 C 端產(chǎn)品在做大版本迭代的時候，不會太在意用戶的使用習慣；導航架構(gòu)的調(diào)整，也不會去管用戶是否能夠接受；而對于 B 端產(chǎn)品而言則完全不相同，一點點的習慣改變都會遭到部分用戶的強烈抵制！

因為一個新的功能意味著他們需要適應(yīng)和學習新的事物，沒有人愿意多花時間在工作學習上，因此這對他們來說可能會很痛苦。

但作為一個設(shè)計師，很多時候你是不得不做。不改變，新用戶理解不了；改變，老用戶又不能接受。 因此我們今天來聊聊 B 端新版本，上線新功能的具體 SOP～

一、評估你的方案是否合理

在去做一個新需求時，如果用戶不能接受，我們首先要去思考的便是你的方案是否合理。

因為對于設(shè)計師而言，在去做方案的過程中，容易形成自己的思維慣性，導致你會覺得一個需求只會有一種解法。這時候就不能埋著頭做設(shè)計，一定要抬頭聽聽周圍人的意見。

在工作中，我們可以在方案不太確定時，邀請相關(guān)的同事進行風險的評估，通常這些同事是其他項目的設(shè)計師、相關(guān)的產(chǎn)品經(jīng)理、 對應(yīng)的測試同事、或者是提出需求的銷售，這些他們都是會與用戶打交道，對于用戶的理解更加深刻。

通過邀請他們參與評審，我們可以判斷我們的方案是否切實可行。如果其他同事時間緊迫，你也可以將設(shè)計方案私下發(fā)送給他們，并明確標注核心的修改部分，這樣可以盡可能減少他們的閱讀時間。這一步盡可能的聽取大家的意見，將自己的方案盡可能的考慮全面。

在方案確定之后，我們需要對日常的更新內(nèi)容進行一個基本的劃分，好方便我們后續(xù)的分析。在日常的需求方案當中，我們主要分為三種情況：1.大版本迭代 2.新功能上線 3.小需求優(yōu)化

針對這三種情況，我們會介紹不同的更新策略，方便大家在實際工作當中進行實操.

二、大版本的迭代

在整個大版本的迭代上，由于涉及到的人員實在過多，因此在設(shè)計上需要格外小心

1. 灰度新用戶測試

首先如果是一次非常大版本的升級，我們會去考慮引入"灰度新用戶"來進行測試。因為如果我們將新版本的內(nèi)容直接全量發(fā)布，那必定會受到很多老用戶的吐槽和壓力。

這時候 SaaS 產(chǎn)品就會有源源不斷的新用戶進來，同時他們沒有養(yǎng)成各種使用"壞習慣"，這時候?qū)⑦@部分用戶圈出來，進行單獨的測試。這樣就能得到一個較為干凈的用戶群，也能夠讓他們站在一個全新的用戶視角判斷我們產(chǎn)品是否有問題。

比如 飛書文檔 最近正在準備進行一次大的迭代，迭代里面會包含很多概念的調(diào)整，其中最重要的是區(qū)分 我的空間、共享空間、知識庫 ，取而代之的是 主頁、云盤、知識庫，增加了云盤的概念，這對于很多用戶來的都是一次全新的挑戰(zhàn)。

因此在他們新版本當中，目前只能讓新注冊的企業(yè)進行使用，能夠保證這些人的干凈與純粹，這樣在用戶使用不滿意的地方才能夠排除是用戶之前的一些習慣所造成的影響。

2. 上線新版本

當新用戶滿意后，我們便可著手思考如何讓新版本滿足老用戶的使用需求。

普通設(shè)計師的做法就是上！強上！讓老用戶直接去學習適應(yīng)新版本，這時候肯定會遭到大量的吐槽，然后這時候銷售再教會 KA 客戶新版本應(yīng)該如何使用。

聰明設(shè)計師則會采取 "溫水煮青蛙" 的方式，將一部分不適應(yīng)的用戶 篩選再篩選，進而讓他進行適應(yīng)，這里簡單分享一下上線版本的策略：

首先，新版本上線將全部用戶都切換到新版本中，并給出相對應(yīng)的新手引導，告訴用戶目前系統(tǒng)更新內(nèi)容，這時就會出現(xiàn)兩種情況。

1. 用戶對新版本內(nèi)容滿意，愿意繼續(xù)探索使用，這部分用戶我們通常會通過數(shù)據(jù)監(jiān)控了解他們的去向～
2. 用戶對新版本內(nèi)容不滿意，想要繼續(xù)使用老版本，這時候我們會讓他快速找到老版本回退的入口（會非常顯眼），并進行快速的點擊。并且用戶每一次登錄，系統(tǒng)先暫時讓他默認保留為舊版本，不去做新版本的切換。

當不滿意用戶點擊"返回舊版本"后，會給出對應(yīng)的問卷提示，詢問其不滿意的地方及原因，這樣既能讓一部分頑固派保持他們現(xiàn)有的界面狀態(tài)，同時也能詢問他們不滿意的原因。

3. 調(diào)整優(yōu)化

當新版本上線 1-2 周后，一定會接到大量的 不滿意投訴，這時候我們就要針對這些投訴優(yōu)化，進行相應(yīng)的微調(diào)。

比如在騰訊云控制臺之前上線的新版本，我們也有去寫相應(yīng)的復盤。隨后你會發(fā)現(xiàn)他們的控制臺內(nèi)容又會不停的變化，樣式上也會進行調(diào)整。

這也證明設(shè)計不應(yīng)該是一成不變的，需要根據(jù)上線后的用戶反饋進行調(diào)整優(yōu)化。

當我們覺得優(yōu)化完成過后，我們就需要再次邀請我們的"客人"，那些切換回舊版本的用戶，讓他們再次體驗優(yōu)化過后的內(nèi)容，這時候肯定會有部分用戶是能逐步接受的，那就繼續(xù)觀察他們的使用數(shù)據(jù)。

對于不能接受的用戶這時候我們就需要給他們一點"手段"，也就是讓他們每次進入系統(tǒng)，都需先進入新版本系統(tǒng)當中，強制他們使用，想要回到舊版本必須手動切換，盡可能增加它的使用成本，使新版本內(nèi)容并逐步的接受。

經(jīng)過這一系列操作，我們的用戶肯定會對新版本更熟悉，也更了解。

4. 弱化入口逐步取消舊版本

到了迭代的尾聲，也別忘了舊版本的入口，這時候可以將舊版本的入口逐漸弱化。

比如最開始是外露在工作臺當中，目的為了讓用戶能夠快速切換，隨后收折到了設(shè)置里面，需要二次操作才可切換，并且還可進一步弱化。

直到入口消失，將舊版本的用戶完全遷移～

三、新功能上線

對于新功能的上線，我們就需要考慮功能當中的兼容性問題。如果上線一個新的功能，但會影響舊版本功能的體驗，這時候我們的設(shè)計就會異常小心，一定要去考慮如何兼容舊版本的內(nèi)容。

比如在飛書文檔當中之前會出現(xiàn)，思維導圖的迭代優(yōu)化。在最初的版本當中，思維導圖是以舊版本的方式來去做的呈現(xiàn)，如下圖：

但由于這種思維導圖它的局限性較大，節(jié)點與節(jié)點之間很難形成關(guān)聯(lián)，因此在設(shè)計人員的優(yōu)化下，最終將其變?yōu)橐援嫲逍问綖橹鞯乃季S導圖。（就是這個思維導圖的本質(zhì)是一個畫板，里面會包含有思維導圖這種模式，和之前的固定的形式其實是不同的）

當然由于這是一個新的功能，因此在設(shè)計的時候需要考慮如何與舊版本去做關(guān)聯(lián)。

首先不可能將用戶的所有舊版本內(nèi)容直接進行替換，這顯然是不太符合用戶直觀的習慣的，因此飛書這里給出的解決方案是在舊版的思維導圖當中，新增一個升級的入口，能夠讓用戶直接點擊升級，進而快速讓用戶能夠繼續(xù)使用。

同時在入口處也會進行優(yōu)化，將舊版本的思維導圖隱藏到二級菜單，這樣也更符合產(chǎn)品想要去推廣新的思維導圖。

這就是在去迭代新思路的時候，我們需要去考慮舊版本的內(nèi)容應(yīng)該如何兼容，當然等到某一個時間節(jié)點，使用舊版本的人數(shù)真的很少的情況下，我們就可以進行直接的切換～

關(guān)于兼容，無論是之前 WP7 到 WP8 因為沒有做到設(shè)備的兼容而丟失市場份額，成功案例比如蘋果雖然去掉了 3Dtouch，但依舊使用長按來兼容這個功能的運行，我覺得都是非常重要的一種方式。

四、小需求優(yōu)化

最后在日常工作當中，我們也會經(jīng)歷非常多的小需求優(yōu)化。

對于小需求優(yōu)化，我們更關(guān)注的是需求能不能夠讓用戶理解，這方面的需求我們需要快速得到驗證。最好的辦法就是建立自己內(nèi)部的社群，通過社群當中的用戶快速的互動，進而得到一個較為準確的答復。

這樣就能實現(xiàn)一個問題的快速反饋，保證體驗與設(shè)計質(zhì)量。

當然無論是什么情況下的更新，都需要在幫助文檔、需求文檔等地方有著更為清晰的標注，這樣才能夠保證最后的改變內(nèi)容能夠傳達給用戶。

比如 Figma 這次的迭代優(yōu)化，其實你會發(fā)現(xiàn)在其幫助文檔里標注極為詳細，我們便可以通過標注的內(nèi)容快速理解其變化。

因此我們在后續(xù)功能優(yōu)化時，也應(yīng)該在對應(yīng)的頁面給出對應(yīng)的前后對照表，方便我們快速理解

總結(jié)

最后，我們無論在什么產(chǎn)品當中，剛開始上線一個新功能都不會是完美的，需要我們?nèi)プ龈嗟木S護工作。

比如 Figma 的上線、飛書新功能上線、騰訊云新功能... 會有很多，我們在做設(shè)計時，也不是一錘子買賣，需要做的是不斷的迭代～

那你在產(chǎn)品上線時還發(fā)生過那些有趣的故事？可以和我們一起聊聊～

作者：CE青年Youthce