對 PC 版首頁的航班搜索面板進行設計優化，提升 12% 的航班搜尋率。
資訊架構、用戶流程、Wireframe
其他成員：UI 設計師
時間：一月, 2020
PC 版首頁的搜索模塊對轉化率與訂單量佔有決定性的重要性 － 在所有成功預訂機票的用戶當中，至少 70% 的用戶使用了這個功能。
在例行的數據觀察時，我發現首頁搜索率呈現下降的趨勢。在與產品經理討論後，我們一致認為，搜索率的提升可以有助解決轉化率的成長停滯。
關鍵指標報表（部分）顯示搜索率呈現下降
由於是對於現有的頁面進行優化，我們有大量的過往數據可以進行探勘與研究。
我們研究了 Google Analytics 收集到的數據，包含首頁瀏覽、跳轉情況、各個搜索面板元素的點擊數量、搜索條件以及訂單數據等等。
這些數據可以幫助我們了解一個典型的用戶是如何使用我們的搜索面板，以及擁有那些行為特徵的用戶有較高的可能性完成搜索目標。
事件數據分析（去除真實數據）展示
在量性分析之外，我們也想辦法直接觀察用戶的使用現有搜索面板的方式。我們運用了用戶行為觀察工具 Hotjar 觀察用戶在頁面的使用情況，使用了熱力圖與用戶錄像兩個功能。熱力圖功能讓我們可以以視覺化的方式理解用戶在頁面上的滑鼠軌跡、點擊分佈。錄像功能則可以讓我們實際觀察用戶的搜索行為。
儘管這類的質性研究有其侷限性，也可能會造成研究偏見，但卻可以讓我們更直觀的了解用戶是如何使用我們的產品，我們的發現也確實對後續的設計帶來極大的幫助。
Hotjar 熱力圖與用戶錄像展示（示意非此案例）
在設計使用流程時，我們發現預定來回程機票的用戶明顯的分為兩個行為模式。大多數的用戶會按照從上到下的閱讀順序，優先選擇來回程的行程類型然後再進行後續的地點與日期選擇。但也有為數可觀的用戶會先進行地點、日期的選擇，再折返將行程模式切換為來回程以選擇返程日期。如圖所示:
我們猜測會有這樣的差別的可能原因有幾個：
我們決定對我們現有的介面稍加修改，讓兩種搜索路徑都可以順暢的進行。
此外，我們也嘗試在用戶完成個別欄位輸入時主動打開下一個搜索欄位的流程引導方式。但在數據探勘之後發現許多用戶在進行搜索時不會打開每一個搜索欄位，且每個搜索條件的點擊數之間存在巨大的差異，因此我們在最後的方案中並未加上這一層的引導。
我依據研究，將航班搜索必要的元素列下，並進行卡片分類、順序調整以及標籤命名，如下圖。
在順序編排上，我依據先前觀察的數據以及用戶行為，發現最重要的元素為出發地與目的地的選擇，其次為日期，最次為人數與其他的選項。此外，考量到線上機票訂購是高度標準化的產品類型，此種較為常見的編排方式可以降低用戶的學習成本。因此我選擇依照此順序編排元素。
我們也在面板中加入了機場三字碼縮寫以及機場全稱，解決了之前只展示城市時會造成的一個城市兩個機場說明不清的情況。同時我們也對個欄位的標籤進行微調，以滿足語義以及閱讀的流暢。
Card Sorting in Process
部分競品調研
經過幾次調整，我們在決定用戶流程以及資訊架構之後設計出了兩種版式、五種樣式進行內部測試。
非常幸運的，團隊內有許多擁有豐富OTA經歷的成員，提供了許多寶貴的建議。我們在內部測試結束之後選定版本，並且依據建議進行些微修改便提交開發。
藉由適度縮小輸入匡標籤，將主要輸入匡放大。這麼一來可以降低視覺干擾，同時增加了 35% 的輸入匡面積，讓其變得更加易於點擊與閱讀。
回程日期的選擇匡常駐於介面中，若使用者點擊便可選擇回程日期，同時滿足先選行程類型（單程、往返）與後選的兩種用戶。
給予使用者即時反饋，同時讓使用者更易找到合適結果。
展示過往搜索歷史，減少使用者的操作成本與時間。
增加展示機場三字碼、機場全稱、國家名稱等資訊，減少混淆。
在新設計上線之後，首頁的航班搜索率大約提升了 12 % *左右，且對於新用戶的改善效果要大於舊用戶。
因為項目的設計限制與時間限制，我們無法對介面進行本質上的設計改動。在印度的主要OTA中，我們是唯一一個將航班搜索與酒店搜索放在同一個面板中的廠商，也是少見在PC上使用直立式佈局的廠商。如果有更多的時間與設計自由，我想我會進行更多的設計嘗試，讓產品的信息架構更為明確合理，也讓搜索變得更加易用。
*進行搜索的用戶數/總用戶數, 搜集時間為八週。
