產品設計 | 配置化的版本更新引導怎麼做？
什麼是配置化的版本更新引導？
為什麼要做配置化？
配置化的版本更新提示怎麼做？
一些使用者體驗上的優化點
涉及人工配置，協作流程是怎麼樣的？
關於強制更新
最後，踩過的一個坑及避坑指南
一、什麼是配置化的版本更新引導？
這裡的“配置化的版本更新引導”是指，使用中臺配置的方式，來為迭代過程中，不同的內容不同重要性的版本，量身定製引導更新的方式，降低對使用者的騷擾，並避免使用者陷入“更新麻木”狀態中，同時保證一定的更新率。配置化的版本更新引導與一刀切式的更新引導相對。
需要配置的內容主要有以下3種：
1. 引導更新的方式配置
2. 強制更新配置
3. 新版本更新內容和版本資訊
本文主要講引導更新方式配置化。
二、為什麼要做配置化？
不同的版本更新內容不同，有些是新功能釋出，有些是重大bug修復，有些則是小細節優化，版本的重要性不同，不同使用者的版本情況也不同，這就意味著不能用一種固定式的更新提醒。
例如，如果每次新版本釋出都用APP內的彈窗去提示使用者，在版本更新頻率較高的情況下，一來會對使用者造成比較強的打擾；二來很容易出現“狼來了”的情況（即當用戶對更新提示習慣性麻木後，遇到真正重要的版本，也會習慣性地忽略掉而不更新）。
三、配置化的版本更新提示怎麼做？
不同重要性版本的提示方式應有不同，常見的版本的提示方式有：APP內彈窗、badge引導，其中，badge引導又分為主tab badge和“檢查更新”選單badge。
例如，版本依據重要性劃分為1、2、3三個等級，數字越低代表重要程度越高。則不同重要性的版本的提示方式如下（重要性高的提示方式包含重要性低的提示方式，如使用彈窗時會同時使用badge引導）：
重要性1：APP內彈窗
APP內彈窗的提示強度較高，適用於非常期望使用者更新的版本，例如新功能上線、已有功能做了比較大的優化等場景下。
重要性2：主tab badge
主tab badge提示的強度弱於APP內彈窗，適用於期望使用者更新的版本，例如功能的優化，bug的修復等。
重要性3：“檢查更新”選單badge
提示強度最弱，對使用者更新版本的期望程度一般。適用於修復bug的小版本。
配置時，根據版本的重要性定義，為該版本配置相應的展示方式。
舉個例子，新版本上線了一個可重要的運營活動，使用者需更新方能參與，則此時以使用APP內彈窗的方式提示使用者。若新版本優化了一些細節的體驗，修復了一些bug，使用者是否更新影響不大，此時在“檢查新版本”選單處標識badge，願意升級的使用者主動點選即可。
版本的重要性如何去定義？
從產品自身來說：每個產品團隊內部都會有自己的一套需求的評估模型，將需求池中的需求通過此模型確定好重要性和優先順序後，則需求本身的重要性就是對應版本的重要性。
從使用者角度來說：大部分使用者常用的或期待的功能，重要性往往也會比較高。
四、一些使用者體驗上的優化點
1. 允許使用者勾選“忽略該版本”
允許忽略的邏輯是，如果使用者在更新彈窗上勾選“忽略該版本”，則該版本的更新彈窗對該裝置不再展示；否則彈窗依舊按既定規則彈出，如每天首次開啟APP時彈出。
這個優化點的使用者場景是：雖然這個版本在產品內部的定義為很重要（因為已經用到首頁彈窗去強提醒使用者），但是使用者閱讀更新提示後，覺得對自己並不重要，所以決定不更新該版本，此時把選擇權交給使用者，比起每天傻瓜式地彈出提醒，雖損失了一定更新率，但是無形中也降低了使用者的不滿和解除安裝率。
類似的方式還有，使用者對某版本選擇不升級的次數達到一定值時，不再對使用者提示該版本等。
2. 不同網路環境下的邏輯
如使用者當前所處的網路環境為WiFi環境，在更新彈窗上提示WiFi環境會降低使用者更新的負擔，繼而增加更新率；若使用者處於行動網路環境，此時彈窗上可以提示預計消耗的流量，如果是應用內更新，則最好是在點選更新後讓使用者二次確認是否更新，或者允許使用者在通知欄操作暫停下載。
3. 包的大小
如無必要，儘量以“瘦”為美。看到一個一百多M的APP，想到下載要一分鐘，安裝要半分鐘，可能流量還要耗掉幾塊錢，願意更新的恐怕就是真愛了。
4. 更新彈窗視覺上及文案上的優化
文案上儘量避免使用技術上的描述詞彙，如“修復了xxx的bug"，有些使用者可能並不知道“bug”是什麼意思；另外，精簡和說人話的文案總是優於長篇大論和任務式的描述。
視覺上嘛，舉個例子，對於大部分使用者來說，即使知道賣相好的果子很可能是在農藥的懷抱里長大的，依舊會選擇它們而不是那些歪瓜裂棗，既然已經呈現到使用者面前，用點心打扮好看點總是沒錯的。
5. WiFi下靜默下載
相對於提示有新版本可下載，直接下載好了提示使用者安裝，使用者的決策成本會被降低，更新率會更高。不過此操作只有Android版本可以做到，另需注意提示安裝的時機以及使用者未安裝下載的版本而又有新版時的邏輯處理。
五、涉及人工配置，協作流程是怎麼樣的？
版本更新配置化的優點是延展性強，缺點是強依賴人工。版本上線涉及多人或多部門協作，如開發部門打包，QA部門驗收，產品和設計部門驗收，市場部門發版，運營部門驗收線上版本及配置更新提示等等，如果協作流程不順暢，其結果一定是一言難盡。
不同公司不同團隊，有不同的協作風格和協作流程，沒有最好的流程，只有最適合的流程。舉個例子，需求在策劃前就已有了重要性的評估，那麼在開發完成後測試通過前，產品及運營就應確定本次提示使用者更新的方式並準備好相關素材，並在市場發版前完成配置並檢查無誤，待版本稽核通過後，再分渠道驗證一遍線上的更新流程。
六、關於強制更新
強制更新的邏輯簡單粗暴：不更新就不讓用，這個時候，往往解決問題的優先順序大於使用者體驗，所以無論怎麼做都會傷害使用者，只是傷得重還是傷得輕而已。所以強制更新一定要慎用，否則很容易殺敵一千自損八百，強制更新的使用場景一般有兩種：某版本有重大bug、低版本不再維護。
七、最後，分享一個踩過的坑
最近在從0到1做一個產品，一開始的計劃是先快速推出MVP去市場試錯，由於資源比較有限（人員、時間等），完善基礎設施的需求（如使用者觸達和版本更新提示等），團隊內部的評估結果是“不重要不緊急”，所以優先順序定得比較低。由於後面主要資源都投放在嘗試業務需求和穩定產品功能上，導致這些基礎性需求一直排不上期。
堆積到後來就成了，但是由於缺乏使用者觸達體系，沒有有效的方式可以提示使用者更新版本（後來緊急做了遠端push），APP內也沒有檢測新版本的功能，一次，一個早期的版本出現了一個比較嚴重bug，使用者直接怒而差評，生生把產品的Google Play評分從4.5拉到了3.2...
經過這件事後，我們的版本迭代策略調整為：基礎性的需求，較小的就直接混搭到各個業務需求中，買一送一一起做，較大的則按照其優先順序，排進業務需求的空隙或單獨拎出來作為一個需求，保證每個月的計劃中，一定可以排上幾個看似“不重要不緊急”基礎需求。既可不耽誤業務需求，也避免後面堆積太多的坑。
有時候，絆倒你的，不是天上的星辰，而是地上你沒填的坑。