在產品的迭代升級過程中，改版設計是常常會遇到的問題。文章對結合自己的工作經驗，梳理分析了產品改版設計的步驟，并對過程中需要注意的問題進行了分析總結，供大家參考學習。

當產品要進行大改版時，也就意味著產品經理要沒日沒夜的趕進度，完成新產品的設計工作，在高壓的同時也是一個不可多得的機會，把握住此機會往往能成為自己談資的資本，那么如何進行大版本迭代？又該如何高效完成產品的設計工作？

我參考前墨跡天氣產品總監的分享，整理了以下7個步驟：

1. 前期準備
2. 建立工作坊
3. kickoff會議
4. 驗證
5. 快速實現和發布
6. 快速驗證的敏捷
7. A/B測試

01 前期準備

1. 概論：
2. 團隊內部明確大改版的目的
3. 產品現狀：
4. 用戶畫像
5. 用戶細分
6. 用戶的行為偏好

大改版的過程中，內部一定要確定好一個很明確的目標。是只改交互和頁面，還是整個App架構都變化了，還有一種情況是只改單個模塊，如果這個模塊是舊模塊，我們去改這個舊模塊的時候，一定會說這個舊模塊有一定的問題，這個時候我們需要把它的問題點列出來。

如果說我要去做一個新的嘗試，可能是基于我現在APP的架構上多了一塊業務而做的這個模塊，總之不同的業務，不同產品的時期，或者是說公司不同的情況導致你的目的有不同的偏重，我們在改版的過程中一定要清晰明了的知道我們的目的是什么，做好產品的目標管理。

另外就是要了解自己產品的現狀，現在大家都在說大數據、用戶畫像，這個基于產品前期來講的話，做需求場景的時候已經定義的有幾類用戶，A類和 B類，A類肯定有一個需求，但A類用戶是什么樣子的，這個就是當你之前做的時候和你現在在改版這一時刻用戶畫像有沒有改變，你要去判定一下；

或者說我的用戶畫像已經改變了，我是不是要把我之前設計的場景重新梳理一下，就是怎么去使用，現在說可能有的團隊已經有了一個用戶畫像和用戶標簽，有團隊可能沒有，當然也包括用戶群的細分，用戶偏好的細分。

在這里為大家提供一些辦法，想網上禪大師，酷傳科技，七麥數據等互聯網產品分析網站都會積累大量的數據和做相關調研，如果公司沒有這些用戶數據的話可以考慮借助這種第三方平臺提供的服務，相互合作，完成前期的準備。

在整個設計過程中，我們要提前把用戶的行為梳理起來，就是用戶吸引過來的時候他的核心路徑是哪些，在改版之前會梳理一下核心路徑有幾條，用戶進來的時候打開首頁去哪里，去哪里之后跳出頁是哪里，然后我變動這個功能模塊，變動這個架構的時候影不影響核心路徑，假如影響核心路徑怎么去改變。

最后一點是你需要找出你的核心流程、主流程。把一兩個核心功能梳理出來，判定上線之后的數據情況是什么樣子的，或者是把這個做為一個快速迭代時候的判斷指標，有一個統計是用戶80%集中在核心流程，另外的功能弱，也就是說你發現用那些功能的就五六個人，所以改版在資源調度上面很重要，或者是方向很重要，包括我們在日常進行迭代的時候，怎么樣把注意力放在重點功能上，這就是一個思路和參考。

02 建立工作坊

將團隊分成2個team，每個team完成各自的4個任務（角色討論20min，使命必達15min，設計原則20min，品牌特性25min），然后做匯報審核，共同討論。

為什么要建立工作坊呢？是因為我們要跟所有團隊的人去討論一下大改版或者實施方向，我們怎么去做這個工作坊？我們把我們整個團隊分成2部分，這時候你選人的時候非常重要，我們做改變的時候，有可能產品經理不是離用戶最近的人，這個時候就要把要把運營市場的專員叫過來，還是就是我們在改版的時候有哪些坑。

你找的team1和team2一定要是來自不同部門，有不同訴求的，這樣綜合改版的時候不是我的產品要創造哪些東西，而是說擊中了大家的思維。我們之前說產品經理要學會借力，這也是借力的方法。有了工作坊接下來就是任務了

第一個任務是角色的討論，我們做了那么多前期的準備定義了大概的方向之后，接下來就是我們要把我們的用戶再去細分，也就是用戶是什么樣的，廣義上70后，80后或者90后，按照年齡、性別，他們的經濟狀況，手機使用情況，行為狀況不一樣的，所以我們要對用戶決策進行建模，明確現階段我們做什么。

另外一個就是項目的使命是什么，我們要不停地提煉項目的使命，最終確定一個清晰簡練的項目使命。比如第一個使命是16個字，后面就慢慢減少，每次減少一半，直到不能減少為止，此時就有了一個清晰的目標。

第三個設計的原則，這個設計包括 UI和交互，可能還有更多的人參與，我們這個設計原則是什么？希望實現什么？為什么這樣設置呢？因為平常設計在產品上遇到了一些問題，可能在迭代的過程中由于時間的原因他不敢去說，但在這個過程中他敢表達自己的想法。

另外就是品牌特性，這塊是說明我們做完東西怎么去做宣傳，然后我這個功能點上能不能差異化，一個是宣傳的差異化，另外是產品上已有的差異化，把這個提煉出來，就是品牌特性，其實品牌特性有很多很多方面需要考慮，品牌不光和我們產品關聯，還是和我們應用推廣有關聯。

這塊能挖出來的東西特別多，在改版的時候不要局限在改這個模塊，或者改這個設計，而是站在綜合的角度上考慮我改版的目的。

03 Kickoff會議

Kickoff會議上可以把項目的周期確定，用什么啟動，然后第一次的UI，包括產品原型，然后設計開發是什么時候，另外是我們需要多久，或者項目跟進的時候大家怎么調動這個資源，一定要有一個明確的項目周期。

另外改完之后肯定是要做外部評審，因為改完之后可能是設計風格要去審，也有可能這次改的主要功能要做一個評審，還有可能這次關心的用戶不一樣，有的公司可能是團隊內測的，部門內測還要給老板匯報，要把這個時間周期安排好，因為每一次決策，不同人在不同角度決策的時候，會對項目周期和產品結果的促成很大影響，我們需要把這些因素都考慮進去。

KickOff會議結束之后，重點的是深度的探索和輸出，產品上建議大家不要讓思路過于太散，就在關鍵一兩個點上去做。有可能我們改一個全新的，數據猛跌，新用戶留不住，所以建議內容一定要拆解，要找一兩個主線，因為現在的產品經受不住很大的折騰。還有就是業務重點建議把高保真原型輸出，用研這塊可以通過高保真的原型去嘗試。

04 驗證

我們有了大概高保真的時候就和用戶做驗證，相當于我們做可行性測試。溝通需求，測試計劃，用戶招募，撰寫腳本，用研準備，預測試，測試執行，撰寫小結，撰寫報告，宣講報告這是內部大概的流程和環節，用戶篩選的時候條件一定要足，就是第一次做的時候老衲倒不建議做新用戶，可以做老用戶，核心用戶，另外在主路徑上流程比較高的用戶是哪些可以去除。

一般大改版會進行三輪的，第一輪有一些核心業務員，中期會在模擬機上跑，后期產品上線，每次都要去做一些，可能第一次比較難，大家要找到合適的方法。

05 快速實現和發布

快速實現的階段我們會對模塊功能進行拆解，如果發現新版本有問題的時候，這時候可以把功能放在老版本做迭代，我們有可能正在做5.0，做6.0新東西的時候，6.0是個大模塊，這時候又要維護5.0，又要維護6.0，我把這個拆解往 5.0上迭代，看部分的用戶對這個功能反饋是什么樣的，如果這個是好就放在6.0上通過。

我們會引入相關的機制，這塊會降低你改版的風險度。另外就是深度篩選你的目標渠道，其實360的用戶畫像和豌豆莢的用戶畫像，包括百度、商場、商店完全是不一樣的，特別是oppo、vivo和小米，用戶畫像、用戶群完全不一樣，包括消費水平都是不一樣的，我們在發布時需要做具體考慮。

還有一塊就是在全量發布的時候一定要有一個標準，起碼說產品質量，包括提供的服務要一定沒什么問題。全量發布的標準內部一定要定義好，就是內部的策略，線上的渠道，然后到底發布的時候推給老用戶還是給新用戶用，這塊一定要做一個相關的驗證。

06 快速驗證的敏捷

另外新版本上線發布的時候要建立一個快捷敏捷的機制，這個敏捷的機制該是做一些假設，做假設的時候可以快速修改，修改可以快速的看一些機制。

因為在上線之前可能經歷了無數次個別功能模塊的調整，這就導致我們商業化變低了要調整，用戶的喜好不一樣了，所以上線以后可能發現一部分用戶反饋特別差，要快速改這些，這也是通過我們的產品去驗證自己的一個方法，這是在大改版中一定是重中之重的思想。

07 A/BTest

A/BTest，隨著我們體量的增加我們就把A/BTest使用上了，國內用A/BTest是頭條一直在用。A/BTest最有效的是在你團隊內爭議的時候對于圖標的測試，你可能感覺這個圖標不好看，用了這個機制之后可以把它的這個圖標打成三份，雖然明顯的知道雖然它非常丑，但是分享率特別高，這是一種設計上A/BTest非常有用的地方。

還有就是產品上做轉化率，就是我們從首頁入口到滴滴訂單的時候，我們在設計上可能有分歧的地方，那就可以用兩三套A/B Test 的機制快速展示就可以快速的得到。

最后，我總結一下大改版背后的一些注意事項：

1. Timing:團隊情況+產品屬性
2. 時間周期，資源度
3. 迭代模式，小步快跑
4. A/B Test
5. 主線不要太多
6. 分配迭代
7. 發布前的預熱準備
8. 危機意識的防范

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

題圖來自Unsplash，基于CC0協議