數據與設計的關系，業界向來頗多熱議——有“數據驅動設計”之說，有“數據引導設計”之論，也有類似“數據關注削弱用戶體驗”的抱怨。看似感性主觀的用戶體驗設計與理性客觀的數據分析，究竟怎樣才能相互作用進而碰撞出產品的靈感火花?
本文試拋一磚，將通過酒店產品設計中的兩個案例來介紹數據在攜程產品設計過程中的應用實踐，以及攜程所構建的專業數據體系。
產品設計的數據觀
作為互聯網產品設計者，首先要樹立對數據的正確認知，我們稱之“數據觀”。
數據貫穿設計全過程，產品設計要學會用數據說話
數據是人創造的，只有人會解釋和分析數據
明確業務/設計目標，根據需求來采集、分析數據
上線后關注數據變化，發現問題，快速迭代
持續監測、評估數據，以檢驗設計目標是否達成
數據不能替代用戶體驗，改進仍需結合多種手段
而要讓數據分析真正有效地推進產品設計，又有以下必備條件：
首先是數據源，“巧婦難為無米之炊”，完善的數據采集、展示體系，是進行分析的先決條件。
然后是數據感，也就是從數據中捕捉、挖掘、分析的能力。林彪當年在遼沈戰役聽取一場遭遇戰的戰報時，敏銳地發現繳獲短槍長槍之比、小車大車之比、俘虜軍官士兵之比，都顯著高于平常，于是判斷敵軍指揮所就在附近。果然，經專門部署，在后續戰斗中俘獲了主將廖耀湘。林彪并沒有大數據分析工具，但是他有經驗的積累，數據感出色，當數據異于平常時就能做出準確預判。
再次是對數據的分析法，常見的專業方法有多維分析、路徑分析、留存分析、回訪分析等，將多種方法結合使用會更有助提升數據支撐的深度。
最后，如何將從數據分析中洞見的用戶行為與態度，在設計中予以體現，那就需要設計師的設計力。
攜程的數據體系
數據分析在攜程有著重要地位，這或許與攜程創始人梁建章系出計算機專業又曾在Oracle任職的經歷有關。在攜程，數據既是考量工作績效的指標，也是未來業務拓展的探針。
在攜程產品的整個生命周期中，數據始終貫穿其間。始自一個創意的誕生，需求分析階段就有基于數據的診斷性研究；隨后在產品設計環節，又會有數據做出價值預估，并給出目標建議；在產品上線初期，海量數據環境的A/B測試，數據波動關注，一直到產品上線穩定后的運營監控、定制報表，數據無一不是重要的考察因素。
工欲善其事，必先利其器。攜程平臺打造了多款數據利器，幫助員工善用數據：
利器之一，UIP用戶洞察平臺。它將主要數據指標一網打盡，產品設計可根據需要，基于頻道、頁面、地理位置、提交渠道、流量來源等，逐一查看各種PV、UV指標，以及跳出率、二跳率、退出率、轉化率、頁面停留時間等數據。
利器之二，頁面點擊插件。點擊頁面上的每個模塊，可以查看到它的點擊概要、訪問趨勢、統計數據明細、瀏覽器統計、頁面熱力圖等信息。
利器之三，A/B 測試，也就是切取部分流量，采用科學取樣方法，讓新舊設計版本在同一時間段同質的用戶群體內“以實踐來檢驗”，直觀地從轉化率數據評判出設計的價值。這種方法穩定、高效，目前在酒店產品線已得到廣泛應用，測試的成功率達到15%以上。由于A/B測試僅在一定樣本內進行，不致對全局業務產生影響，于是設計師獲得更大空間去發揮他們的創意，敢于試錯；數據比對會幫助他們不斷修正設計中的方法偏差。當然，A/B測試著力相對短期，不能過度依賴，且更適用海量用戶的測試。
利器之四是定制開發的KPI Portal，它根據各個項目的具體需求，將與項目相關的各類數據指標集成在一起，做出趨勢看板，供項目中人快速、直觀地了解項目目標達成情況。有趣的是，這些指標還可換算成收益！
然而光有這些數據分析工具，不免還有所欠缺。比如酒店詳情頁上展示的房型和設施信息，要從點擊數據上分析用戶對它們優先級的排列和分組的看法，就非常困難。因為定性的問題很難通過定量的分析工具來得到解決。此時，攜程的用戶研究團隊就受命登場了。
用研團隊會通過對典型用戶的訪談、焦點小組、卡片分類、眼動追蹤等一系列專業手段，挖掘出用戶的行為與態度特征，幫助產品設計理解表象行為后的內在原因，為優化設計提供依據和佐證。
攜程民宿頻道的設計進化或許就可歸因于這種定量與定性分析的結合。
案例一，攜程民宿頻道進化史
近年來，住宿市場上獨具個性和人情味的民宿、客棧異軍突起，深受游客追捧，于是攜程應運市場趨勢，在攜程旅行客戶端推出了民宿頻道。用戶訪問的路徑是：民宿頻道首頁(選擇城市與時間段)-列表頁(選擇客棧)-詳情頁(了解客棧的房型信息)-預訂填寫頁(對具體房型下單購買)。
最初，民宿頻道只是將具有民宿、客棧屬性的酒店收錄進來，其頁面樣式仍然沿襲常規酒店的模板。很快，數據發現，民宿頻道各頁面的轉換率低于常規酒店。用研給出結論：民宿頻道功能照搬常規酒店，沒有考慮民宿用戶的特定需求；頻道定位不清晰，沒有凸顯特色。
于是，改版優化開始。首先，通過對訂單數據的挖掘，我們發現民宿類酒店提前預訂天數較之常規酒店更長，預訂距離更遠，說明民宿用戶訂單特征跟主頻道差異明顯，基本是度假出游類型；隨后通過用戶訪談，對用戶特征做出了分類畫像；再經過對競品的對比研究，新的設計方案脈絡清楚起來：
首頁：著重瀏覽和推薦，弱化搜索功能；整體布局高、大、松；視覺暖色調，小清新
列表頁：嘗試提供大圖模式，讓用戶出行前提前了解民宿特色
詳情頁：增強模塊感，每個模塊均外露一部分內容，讓用戶對模塊內容有預覽
第一版的設計方案上線即伴隨A/B測試，結果發現訂單轉化率上升明顯，而具體到各頁面，轉化率變動情況如下：
首頁：首頁-列表頁的轉化率出現了20%的下降(分析：用戶找不到查詢模塊，迭代時需加強)
列表頁：轉化率上升10%，但是大圖效果差于小圖列表(后續默認切換為小圖列表，同時保留大圖列表)
詳情頁：到預訂填寫頁的轉化率上升(信息外露對用戶有效，后續外露更多內容幫助用戶更快決策；同時讓價格常駐頁面底部，減少用戶來回拖動頁面尋找的費力度)
在第一版基礎上的迭代在兩周后上線，A/B測試的結果令人欣喜，首頁到列表頁的轉化率由原來的下降逆轉為上升2%，訂單轉化率繼續上升26%。
面向客戶的C端產品在數據指導下獲得了明確的迭代方向，而面向商戶的B端產品，也可以借助數據分析幫助用戶獲得工作效率的提升。
案例二，客棧通APP訂單詳情頁優化
客棧通是一款幫助民宿客棧老板管理房態、處理訂單的軟件，在這款APP上，訂單詳情的展示對老板至關重要，但是訂單內信息較多，在最初的版本上做了逐行展示，用戶要看全信息必須上下滑動3屏。
產品上線后就開始監測這個頁面所涉及的數據指標，我們發現，進入訂單詳情的用戶大多只是查看信息，做出修改的只占13%；而修改操作中，修改訂單狀態的又遠多于修改訂單內容的。訂單修改頁面的平均停留時長達到11秒，說明用戶定位到要修改的信息再完成修改有一定費力度。雖然對訂單信息做了逐行展示，但有些字段長度有限，可以考慮合并；而有些字段(如房型名稱、房間號)長度可能超出但對用戶這全不是問題——客棧老板對自己的房間如數家珍，并不強求完整展示。
于是，改版設計方向明確，我們對訂單信息重新布局，分成預訂、住客、房間和結算四個小模塊，每個模塊內信息精簡展示，令一屏內能完整展示訂單的重要信息；將低頻的修改訂單內容操作(如添加房間、入住人)通過入口隱藏起來；同時將我們要強化的修改狀態操作置底顯示，引導用戶進入主流程(辦理預訂-辦理入住-辦理離店)。
商戶端產品的用戶數與客戶端不在一個數量級，因此設計驗證我們未采用更適于海量數據的A/B測試，而是實地走訪多家客棧，通過高保真原型演示和任務模擬，直接觀察客棧老板的操作，來進行可用性測試。
優化版本上線后的數據令人欣喜，訂單查看和修改頁面的PV有了30%以上的增長，訂單平均修改時長由11秒顯著降低至4秒；而與此同時，APP的訂單修改量增加了30倍。顯然，快捷方便的體驗令更多用戶把修改訂單操作由PC轉向手機。
對數據的研究終須落足于人
小結這兩個案例，對數據的監測和分析始終貫穿于產品的生命周期。而在對數據的探究中，始終圍繞著以下幾個問題：
問題和目標是什么？
影響哪些用戶？
影響哪些流程？
你希望的結果是什么？如何測量？
是否有交叉影響(導致此升彼降)？
我們的體會是，數據必須與使用場景緊密結合，明確目標來采集分析數據，同時引入用戶調查、情境訪談等定性研究，多管齊下，善用數據資源去改進問題和發現新的可能，而非“為數據而數據”，或是被各種數據目標牽著走。
數據貫穿設計全過程，但不可能取代用戶體驗設計。所有的數據探索、研究和分析，到最后都要落足于人，所謂“設計以人為本”——通過數據和設計的彼此作用、相輔相成，最終去影響人的態度與行為，收獲業務目標和良好用戶體驗的雙雙達成。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
本文標題：數據分析在攜程產品設計中的應用
相關文章
