怎麼知道用戶是否喜歡咱們的新特性？

DevUI是一支兼具設計視角和工程視角的團隊，服務於華爲雲DevCloud平臺和華爲內部數箇中後臺系統，服務於設計師和前端工程師。
官方網站：devui.design
Ng組件庫：ng-devui（歡迎Star）
官方交流：添加DevUI小助手（devui-official）
DevUIHelper插件：DevUIHelper-LSP（歡迎Star）

引言

一個新版本的上線是否真的對產品體驗帶來提高？

用戶是否真的願意切換至新版本？

用戶是否真的喜歡咱們的產品？

現代管理學之父：Peter F. Drucker 有一句名言：

If you can’t measure it, you can’t manage it.

所以咱們要對新版本的上線過程進行體驗度量，用數據以自證。

我去年有幸參與了一款公司內部產品的新版本封閉開發項目，本篇文章主要從如何更好的制定內測、公測計劃，如何用數據證實用戶對新舊版本的喜愛，用戶的轉化率等多個維度，就收集數據指標的設置、數據分析的角度等方面分享一些本身的心得體會。

開始

咱們在封閉階段的新版本總體上線過程以下圖所示：

咱們的初版本上線通過了大量問題分析討論和和設計，而後咱們的新版本又經歷了內測、公測，不斷的收集新的反饋，而後不斷修正的咱們的業務流，最終上到現網環境，收到用戶的一致好評。

下面我主要是基於上線流程中咱們作的數據分析手段，能夠經過收集哪些數據來度量咱們的產品體驗。

此外新版本的上線過程當中，其實仍是有額外的收穫的，咱們的用戶畫像更加清晰，業務場景的一致性規範愈來愈明確，還有前端頁面的一些基礎組件得以沉澱下來。

1、高保真視覺稿輸出

在開發新版本以前，咱們對當前的老版本作了大量的問題分析和總結，而後深刻客戶現場，經過和用戶的真實面對面訪談和調研，整理了大量的用戶訴求和槽點。

而後由產品經理和設計師講問題進行分類整理以後，輸出低保真設計稿。

接着先後端資深開發人員，運營人員，設計師，產品經理等你們一塊兒參與低保真的設計稿討論，不斷修改設計稿的細節：

• 開發人員的參與主要是保證細節的可實現性
• 設計師和產品等人的參與主要是對業務交互層面的把控
• 運營和用戶的參與主要是確實當前的痛點問題是否獲得緩解和解決

反覆討論和修正低保真設計稿，最終你們取得相對一致結論，這個過程其實很是的難，體驗的感覺自己就是主觀的，誰均可以發表並持有本身的觀點。

此時其實須要產品經理力挽狂瀾，捨棄細枝末節的無謂爭執，在覈心訴求獲得知足的前提下，輸出高保真，開發人員開始實施開發，大膽試錯，當心求證。

當時咱們的前端開發人員和設計師、產品等人集中坐在一個小屋子裏面封閉開發，這樣子最直接的好處就是溝通成本的下降。

此外，按照以往，產品說服開發實施一個需求變動，或者開發說服設計師實施一個設計變動，每每會帶來一個負面的效果：就是口服心不服。

當別人進入你的專業領域來左右你的想法時，每每是經過威嚴施壓來變現他的思路，這樣子帶來的多是被迫的修改，你內心仍是不服氣的。

你們坐在一塊兒的時候，咱們是能夠直接經過下游的內測、公測階段的用戶聲音來講話，當用戶跳起來的時候，「設計、產品、開發」會自覺的識別到錯誤，甚至都不須要你下發命令，他悄悄的就修改了，心服口服的默默上線。

封閉把新版本上線運做的系統效率提高到了最高。

2、自測試階段

在新版本開發完成以後，此時的版本確定存在大量的缺陷和高保真還原度的問題。

開發人員充分自測

此時建議充分發動開發人員進行充分自測試，各業務模塊的開發人員，交替測試對方模塊，梳理頁面的核心邏輯，肯定基本流程是否可用，快速響應修復識別到的問題，能夠經過wiki的文檔協做，備註清楚缺陷的提出人、負責人、復現途徑以及嚴重程度等，嚴重缺陷儘可能作到當天閉環。

設計走讀檢視

其次聯合設計師對頁面進行細節走讀檢視，主要是針對高保真的還原度、一致性等問題進行識別，記錄。

產品體驗和測試

最後產品經理也要儘快參與到自測試階段，主要是針對業務主流程的可用性問題、易用性感覺等角度作好記錄和反饋，設計師和產品的問題與開發自提的問題統一wiki管理，最終根據問題優先級統一走到開發側修復。

通過自測試階段的發現問題、修改問題的反覆迭代以後，bug的數量和嚴重程度逐步收斂至可控範圍內，此時就能夠推動到內測階段。

3、內測階段

在內測階段，咱們的目標測試人羣要切換到咱們的真實用戶羣體，在真實的用戶場景中發現更多的隱藏問題。

此外咱們在內測階段也能夠結合咱們的熱力圖和埋點事件，收集用戶數據，提早感知下用戶在新版本的使用操做流，爲後續的公測作好風險評估。

3.1 內測用戶羣體徵集策略

在用戶的徵集上，咱們當時採用的策略是在老版本里面插播一個廣告彈框，儘可能保證內測的用戶羣體來自於咱們的真實用戶羣體，且具備老版本的使用習慣。

爲了更好地激勵用戶的積極主動性，最好是設定必定數量的物質激勵或者獎金，這樣子才能激發用戶在使用過程當中的反饋動力。

整個內測活動的時間要有期限設置，通常在1-2周左右就差很少了。

此外能夠設置單日最佳獎項，和整個活動的前15-20名獎項，基於反饋問題的質量和數量來評定用戶的名次，好比反饋100個問題的給予一等獎獎勵，獎勵信息和排名信息天天定時發到羣公告裏面，讓你們知道本身的排名，也充分激勵你們的積極主動性。

用戶經過點擊廣告彈框，瞭解本次活動的主要目的，有意願的用戶會自發報名，而後由運營人員統一整理好拉羣，內測用戶羣體仍是要設置規模限制的，過大的用戶量反饋的問題會致使內測階段沒法收斂，要依據團隊人力支撐規模來進行制定，好比300、500等。

3.2 內測問題反饋

爲了更好的牽引用戶反饋本身使用的感覺，咱們使用的是公司內部的工具相似Github的Issue功能，提早把內測用戶拉進建立好的項目裏面，默認提供幾個類型的標籤，以下圖所示：

用戶在提Issue的時候要選擇問題的標籤，打上標籤的問題十分方便產品經理對收集到的問題進行歸類整理。

每一天設置問題反饋的截止時間點，到了時間以後由產品經理肯定當日最佳以及把用戶反饋的問題標記爲是否有效，bug以及須要修改的問題，儘快整理分發的開發側，快速響應。

因爲前期已經引導用戶作好了問題標籤，此時咱們能夠根據標籤過濾用戶喜歡的功能點和不喜歡的功能點，整理分析內測階段的問題也能夠輔助評估內測用戶對新版本的體驗滿意度。

3.3 問卷調查

內測問卷的填寫能夠做爲最終獎勵的加分項，從而鼓勵內測用戶的積極填寫。

問卷調查的主要目的是補充以前進行的問題反饋數據，共同完成對內測流程的體驗度量。

問題設計能夠主要考慮以下幾個方面，固然仍是要基於團隊實際訴求進行充分設計，確保收集的數據可用性。

1. 用戶畫像收集，好比用戶當前工做類型，所屬部門信息，以前使用的相關工具平臺類型，是否使用過老版本，老版本使用時間等之類的問題；
2. 新版本的核心優化模塊的評價，能夠設置新版本核心優化點的單點評價選項；
3. 是否會繼續使用新版本，是否會主動給朋友推薦新版本等主觀意願的相關收集；
4. 待改進的場景點，收集下一步繼續優化的業務點；
5. ...

3.4 內測總結

在內測階段經過Issue的問題反饋和問卷數據收集，能夠度量出用戶對新版本的滿意度，喜好程度，也能夠經過詞雲分析獲得對新版本體驗評價的熱詞分佈，以及用戶對新版本使用和推薦的主觀意願佔比等可度量化數據。

經過這些數據能夠幫助咱們更好的制定下一步公測的計劃以及優化當前版本缺陷問題。

最後說一下咱們此次活動實際感覺，因爲激勵的存在加上咱們的工具自己你們天天就會使用，因此內測用戶的積極性很是大，一天會有300個左右的問題反饋，到了真實的用戶場景裏面確實仍然存在大量的bug和體驗性問題，極大的下降了正式上線的衝擊。

4、公測階段

4.1 公測埋點方案設計

公測階段意味着咱們的產品已經知足正式對外使用條件，爲了不對老版本用戶使用習慣的過分衝擊咱們增長了公測階段。

當時咱們是在老版本里面增長了新版本的廣告牽引彈框以及快速的訪問入口，在牽引入口的點擊事件裏面咱們作了事件埋點，考慮到用戶會互相分享連接訪問的操做，咱們在新版本里面也會識別用戶以前的版本是新or舊，若是存在舊切新的操做也會被埋點事件上報上去。

固然也會提供用戶重新版本返回老版本的入口和對應的埋點事件，對於一個Web站點交互行爲的改動確定會影響到用戶的使用習慣，給用戶帶來額外的學習成本，所以兩個版本之間的切換都要作好埋點事件。

在公測階段咱們使用的主要埋點指標以下：

1. 新用戶：首次訪問某站點的用戶；
2. 頁面訪問次數PV：頁面加載次數其實就是頁面的瀏覽量；
3. 頁面訪問人數UV：通常是指1天內訪問某站點的人數，1天內同一訪客的屢次訪問只計爲1個訪客；
4. 新增用戶：某站點訪問的新增用戶；
5. 用戶轉化率：原來使用的老版本，轉而使用新版本的用戶，佔總用戶數的比率；
6. 留存率：某一統計時間段內的特定用戶羣體中，通過一段時間後仍啓動使用的用戶數佔總用戶的百分比，分別展現新用戶和活躍用戶的日留存；
7. 跳出率：只訪問了一個頁面就離開的會話佔比；
8. 熱力圖：觀察用戶的操做熱點區域；

4.2 埋點方案自驗證

埋點方案可行性自驗證很是的重要，一旦公測入口打開，用戶的行爲就會被上報，而此時若是埋點存在問題，將會丟失最重要的用戶數據，第一天的用戶天然行爲數據是難能難得的。

針對上述方案的埋點要提早進行測試充分，確保數據上報正常。

建議在相對的獨立的自測試環境環境上對相關埋點的設計、數據上報、數據收集等階段作好演練動做。

4.3 公測數據分析

在現網環境訪問新版本的正式入口和運營的預熱活動，大量的用戶進入到新版本，因爲經歷了內測階段的調整，總體用戶的反饋主要是交互習慣的衝擊。

固然最重要的就是埋點的數據分析了，每一天下班以後產品要及時整理埋點數據作好數據分析，詳細記錄好每一天的數據變化趨勢。

以UV轉化率舉例，以下圖所示能夠明顯感受的用戶的增加變化趨勢，經過數據來佐證新版本對用戶的自發式吸引力。  

4.4 公測數據分析

在衆測階段咱們結合了埋點事件，對整個新版本的上線數據作到了可度量，經過分析彙總的數據能夠幫助咱們更好的制定新版本的正式上線時間點，以及不斷修正衆測階段出現的體驗和缺陷問題。

5、總結

體驗的感覺是主觀的，咱們不少人均可以對一個產品體驗指出大量的問題，以前微信產品張小龍不是也自嘲天天有1億人教他作產品，咱們對體驗的追求是無止境的。

上面提到的一些方法只是輔助咱們對現有方案設計進行體驗度量，說到最後一個產品的體驗仍是要靠是否真正的方便的幫助用戶解決了問題、是否存在知足用戶訴求的使用場景纔會造成自發的吸引力。

加入咱們

咱們是DevUI團隊，歡迎來這裏和咱們一塊兒打造優雅高效的人機設計/研發體系。招聘郵箱：muyang2@huawei.com。

文/DevUI 夏天的尾巴

往期文章推薦

《讓咱們來構建一個瀏覽器引擎吧（建議收藏）》

《手把手教你搭建一個灰度發佈環境》

《在瀑布下用火焰烤餅：三步法助你快速定位網站性能問題（超詳細）》