產品頁面改版一件常見的事，不過為什麼一般情況下，移動端的產品不支持返回舊版，而網頁端的產品支持？什麼時候需要有「返回舊版入口」？作者在文章中結合案例進行了具體的闡述，感興趣的朋友一起來看看吧~
最近兩年，B端產品發展迅猛，同時很多產品的門戶網站也開始進行改版，前段時間我們講過花瓣的設計改版，聊了聊它改了什麼內容。今天又看到B站的網頁端也在做一個改版，今天我們就不聊大的改版，我們聚焦於一個小的功能模塊，也就是 「返回舊版入口」。
首先先問小夥伴們這樣一個問題：
- B端產品是否需要有返回舊版的入口？
- 那為什麼移動端的很多設計當中不會出現這個入口呢？
那故事，我們就得從為什麼需要返回舊版說起。
一、需要返回舊版的原因
有沒有發現一個現象？提到返回舊版，我們很少在移動端產品當中看到，比如移動端產品當中，網易雲音樂、微信、支付寶、淘寶等，在一些大版本的更新當中都是直接將版本更新推送給所有用戶，並且無論你是否適應，你都必須給我用！
而在網頁端產品當中，我們頁面的設計變動，在剛開始都是非常的小心，我們會像一個保姆一樣問用戶，你用得習慣不習慣，不習慣可以直接退回的。
其實這也是做網頁端的產品與移動端的產品上的差異。
代碼層面上，網頁端由於代碼都在網上，回退舊版的這個功能對於程式設計師來說實現起來較為簡單；而在移動端甚至客戶端，因為我們的每一次疊代都是通過安裝包的方式進行疊代，也就意味著你想要回退到之前的版本，唯一的辦法就重新安裝舊版本的安裝包，再加上蘋果手機的限制，無法回退（懷念安卓系統一秒鐘）。
那為什麼要返回舊版，我們會站在用戶角度去思考這一問題。
1. 改版變化太大，難以適應
因為很多網頁端的產品改版非常巨大，也就造成了用戶難以適應前後的差異。為了保證用戶不流失，所以給大家預留返回舊版的入口。
比如在B站的這次改版當中，通過對比我們就能發現前後的版本差異巨大，整體首頁的邏輯由以前的按照視頻分區進行展示，所有內容都可以在右側進行跳轉。
到現在的首頁以內容推送為基礎，想要了解分區，需點擊頂部分區欄進行展示：
而這樣的改變，對於我已經非常熟悉B站的首頁機制的用戶來說，確實會有一些不適應，因此預留的返回舊版本便是滿足那些不太適應的用戶。
有正向的例子就一定有反向的例子，也就是並不是所有的產品都需要返回舊版，比如在產品當中，只是簡單調整了頁面當中幾個按鈕變化時，這時候就沒有必要展示返回舊版，顯得有點畫蛇添足。
2. 緩解用戶情緒
既然上面都提到改版變化必須得大，那就一定會涉及到另一個問題，用戶的接受成本一定非常高。
作為用戶，並不是每一個人都喜歡嘗鮮的，那大版本的修改調整，一定會遭到用戶的強力吐槽，而返回舊版本，則是能夠緩解用戶的使用壓力。
比如在語雀的【工作檯】改版當中，就會涉及到這個問題：
版本一（2018-10-24）：
早在2018年的時候，語雀就對當時的工作檯進行改版，但是由於當時用戶量本身不多（雖然是猜測，但是通過語雀的搜索量可以大致得出這一結果），另外就是改版的幅度較小，因此第一個的工作檯疊代非常順利，用戶反饋也非常良好。
版本二（2021-01-18）：
這個版本便是語雀工作檯進行的大刀闊斧的改動，其中就包含整體視覺風格、右側快捷入口、左側知識庫快速訪問等多個改動，隨之而來的便是用戶的大量吐槽。
好像當時語雀就缺少了返回舊版入口（不太確定，有清楚的同學可以評論區補充，我當時使用的時候是沒有發現入口的），導致用戶的情緒無法得到緩解，一時間在語雀公告的評論區炸開了鍋，有大量的用戶吐槽各種新版本的問題。
3. 驗證結果
關於返回舊版本，其實是可以從側面去驗證你的這次改版做得是否合理。
因為返回的人一定是對這次改版產生了不適，而它在去切換舊版本時，他一定有想吐槽的地方，這時適當的展示一份問卷，了解用戶真正關心的點，我們便能夠從這些用戶的吐槽當中，去分析問題，再做設計的後續規劃。
如果能夠從數據上發現返回舊版的人數變少，也能夠從側面反映我們設計的改版的目的，得到了驗證（當然這個指標的制定，不是那麼簡單的，需要看後台數據去做調整）。
二、返回舊版的設計風格
當然，返回舊版的設計風格會有所不同，在我們系統當中並不是隨意去做設計，而是會根據設計要求去做相應調整。
1. 入口位置
在返回舊版當中，入口通常會放置在 右下、側邊、頂部三個區域，由於三者位置不同，對於設計師來說也會有不同的寓意。
（1）頂部入口
在頂部的返回舊版入口是針對全系統的「所有」頁面都會有所改動的時候，比如頁面設計當中：工作檯、表格頁、詳情頁，都會受到影響的時候，這時候更願意把它放在頂部，提高他的信息層級。
（2）側邊入口
這類的改版，則更多針對某一個或某幾個頁面當中，這類的改版不會特別大，因為放在側邊，能夠讓人們知道，目前的改版只針對這幾個頁面，不會涉及到全局。
2. 提示方式
（1）靜默升級
目前很多B端產品，在剛開始疊代時，總是靜悄悄的，然後在系統的右側貼上一個內測版本，這種方式比較適合對系統還不太有把握，剛上線的情況，等情況理想，便可不再低調，安靜的查看數據的結果。
（2）公告提示
隨著數據的不斷變好，版本疊代總的來點儀式感，因此這時候我們都會在版本疊代當中，都會發布公告來讓用戶關注，更新的儀式感由此而來，同樣這也意味著這個版本已經全量發布。
三、如何設計一個「完整」返回舊版
返回舊版在目前看來，似乎只是一個假象，我們要去了解的是產品改版背後的邏輯。通常一次改版疊代，並不是直接改版展示即可，而是需要一個完整的疊代思路。
1. 灰度測試
在網頁端的灰度測試當中，其實測試的方法有很多，通常我們會使用隨機內測與邀請內測制，前者數據更加真實，後者用戶更可控，目的都非常簡單，能夠收集到用戶的意見與反饋。
比如上面例子當中提到的語雀工作檯的改版當中，就採取邀請內測制，先讓用戶申請試用新版本，然後確定內測人群，使用過後進行打分+討論+文章總結的形式，來去驗證設計的初步構想
2. 優化過後疊代通知
解決掉灰度測試遇到的問題過後，可以進行更大範圍的推行，這時候可以嘗試通知所有用戶，已經有新版本，讓一些勇敢願意嘗試的用戶，率先體驗到我們的產品。並且我們會提供完整的新手引導以及退回舊版本的入口，讓他先感受下新版本究竟如何，用起來是否順手
3. 弱化入口直到完美過渡
弱化入口是展示自己「套路」的過程。
首先在剛開始，我們可以採取的策略是，保存用戶之前的版本習慣，比如他之前退出時使用的是舊版本，那後續進入系統當中我們就提供給他舊版本。
隨後，隨著時間的推移，我們就對登錄的策略進行調整，讓他每次進入系統都是先進入新版本，想要進入舊版本就必須手動點擊切換才行，這樣讓他被迫熟悉新系統。
最後由於大家都對新版本比較熟悉，我們可以逐步弱化舊版本入口，直到將其隱藏消失。
這樣的完美過渡就會比新版本強行落地效果來的好得多，當然在公司當中，我們還是得配合銷售、售後人員，對於新版本多去做一些視頻分享會，公開的教會大家如何使用產品，讓用戶能夠快速適應。
四、最後聊聊
其實B端產品的設計改版，想要完美落地時非常難的，畢竟打破之前用戶的使用習慣，需要重新學習。但是使用適當方法，配合著團隊的付出，還是能夠將其順利落地，當然由於文章的篇幅關係，我們就不展開討論了，希望文章能夠對最近正在處理設計改版的你有所幫助，可別忘了點讚轉發~
專欄作家
CE青年，微信公眾號：CE青年，人人都是產品經理專欄作家。專注B端設計領域，一個2B行業的2B設計師。
本文原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平台僅提供信息存儲空間服務。