旅游行業一直是我很看好的行業，現在我以一個旁觀者的身份，結合過去幾年的旅游產品經歷，簡單分析一下旅游產品實操的相關流程。

旅游：是你去到一個地方以當地人的視角去體驗當地人的生活，旅游離不開吃，住，行，購物，玩，安全，天氣等。

旅游是一個必須要出發的消費過程，其目的地對旅客來說是比較陌生的，那么這就決定了旅游的用戶群體：有經濟來源，行動方便，有一定社會閱歷和應變能力，有空閑時間；按照這個用戶畫像你大概能定位旅游的用戶群體年齡段是：16~70歲之間，那么包括三個年齡階段，青少年，中年，老年。

旅游類APP/網站的目的就是為了解決旅游相關的需求的，因此在做產品前，要考慮清楚產品的要素，目的是為了做到心中有數，知己知彼。

在考慮清楚要素后，就是要弄清楚通過哪些業務系統來幫助到消費者，解決旅遊出行需求。

業務表現層是羅列了旅游產品線涉及的相關業務（上圖概括不是很全面，吃，娛 等沒列出），但是具體開發哪些系統要根據實際情況和公司的戰略而定。

如：老年用戶選擇的旅游產品形態是團隊游比較多，中青年選擇的產品形態是自由行比較多，那么對不同年齡層要提供相應的產品系統； 如果公司只專注周邊游，那么交通選擇是汽車，+酒店+保險+門票等就可以搭建符合公司的產品框架了。 如果定位的是服務港澳用戶，那么交通就只能選擇：機票/船票，因為香港和澳門都是島嶼；如公司定位的服務群體是國內，那么簽證系統就沒必要開發。

如果我獲取的需求是公司要求開放 機票系統，酒店系統，度假系統，那么下面就以這個三個需求來進行實操說明。

一、 產品的流程

互聯網產品都包含前端和后端，其對應的用戶不同，產品流程也不同，可以分為如下三個流程：

頁面流程：是指APP/H5，Web 網站前端頁面走向，頁面流程有一個特點就是下一個頁面的產生是依賴上一個頁面的操作的，有明顯的流向性。

操作流程： 是后臺處理流程，后臺操作頁面是預置的，功能和模塊是固定存在的，后臺操作流程受：賬戶權限和訂單狀態影響。所以狀態其實控制了后臺的操作流程順序。

邏輯流程：主要是代碼層面上的邏輯，并沒有頁面可見，頁面與頁面之間的操作，在后臺會做很多接口回調，task ，觸發器等處理。

二、訂單類（電商，旅游）產品流程的特點

頁面流程：一般包括的主界面有：查詢首頁，產品列表頁，產品詳情頁，會員登錄頁，用戶資料頁，付款頁，提交成功頁，訂單詳情頁

操作流程：后臺的流程界面有：基礎資料維護，訂單查詢，訂單處理，結算，報表，郵件，權限設置，CRM，Task；其特點是可以增，刪，改，查，怎么合理的安排增刪改查是操作流程里要考慮的，訂單處理的流程是狀態的改變(提交待處理，確認供應商，確認資源，出票，確認收款，配送/發貨，成交，取消)

邏輯流程：在這里講有點抽象，可以去了解一下資源的融合，還有像付款時的風控體系：調用風控接口，返回風控結果，根據風控結果確定是否hold預授權，task自動扣款，釋放預授權諸如這類。

三、分析需求

我們產品的業務目的就是能幫助用戶：買到機票，預訂到酒店，預訂到度假產品。

為了實現業務目的，我們需對機票/酒店/度假系統的基本特性進行提煉。如下圖：

根據上面信息和已有認知，進行頭腦風暴：

1. 機票和度假系統都有出發地和目的地，但是酒店產品沒有出發地；
2. 機票和度假一定有去程出發日期，也可以有返程日期，那么去程資源和回程資源應該是兩個單程資源， 一個資源是A~B，另一個是B~A,A 和B 都是對應到的城市。
3. 酒店資源有入住日期，并且一定要有退房日期
4. 機票和度假產品 精確到的時間是:XX時XX分，因為航班有一個時間點，酒店精確到 X日就ok
5. 機票和度假產品有區分成人/兒童，而酒店產品只講總人數
6. 機票會受到機場的限制，度假會受到航線和停落地限制，酒店受限制很少
7. 產品都應該有價格，有總價也會有明細
8. 旅游是必須出發的消費，那么要知道是誰出發，怎么聯系出發者
9. 會有一些外部因素導致流程受阻，怎么完成流程（流程的終點有兩個，一個是成功，一個是失?。?/li>
10. 要展示一些信息給用戶，用戶才能對產品有一個大概的了解。
11. ?等等

第一個頁面怎么做？ 為什么這么做，依據是什么？

機票系統和度假系統本來是有出發地 ，但是出發地也有固定出發地，和非固定出發地之分。如產品早期，受到公司資金，手中資源，業務處理等因素影響，出發地是固定一個城市，則只有目的地是可選擇的。

產品后期，公司資金充足，業務擴展了，機票系統和度假系統的出發地不再固定為一個城市，系統則要提供出發點選擇列表和 目的地選擇列表，并且這里的列表數據都要有機場才行，否則會導致列表失效。

資源的豐富程度會決定系統實現的模式，如攜程的機票，酒店，度假產品，其出發地 和 目的地 的可選列表數據全面，那么決定其使用 查詢模式 作為入口才是高效的。 如果像永安旅游度假產品，公司戰略決定了出發地是固定香港的，并且其目的地覆蓋城市不多，那么采用 目的地分區歸類的形式展示比較實用。

如下圖，資源豐富性和服務廣度決定了實現方式的不同：

根據系統需要結合實際情況，可以基本確定各系統首頁元素（其他沒考慮到的地方可以后期優化，布局上要預留優化空間）：

• 機票采用查詢首頁（出發地，目的地，出發日期（單程/往返去程），回程日期（往返回程），艙等，人數（成人/兒童））；
• 酒店采用查詢首頁（入住城市，入住日期，退房日期）
• 度假根據出發地是否固定來設計首頁（固定則用目的地分區歸類顯示；不固定則用查詢出發地+目的地分區歸類顯示）。

找到系統的入口后，我們就可以根據前一流程的結果推導出下一流程。

查詢首頁后一般會得到一個數據結果集，這個結果集怎么設計布局要根據你的產品理念來，如酒店，查詢后一定得到一個對應城市的酒店列表，酒店與房型是1：X ，你可以在酒店列表頁展示出房型數據，也可以新開一個頁展示房型。這種細節的考慮是能反應產品經理的產品感。

我們規劃的這個流程要能把用戶想要的功能塞進去，怎么塞？這個就是具體頁面功能的展示設計了。你可以在EXCEL里把所有的功能都列出來，然后把草圖畫出來，最后對功能進行“類 Swot的分析”。

機票/酒店/度假 通過首頁查詢出來進入資源列表頁，資源列表頁要展示的資源比較多，則要排序，提供篩選規則；具體到數據的展示項時，酒店要給用戶展示（酒店圖片，酒店名，星級，位置，價格等），機票則要展示（出發時間，承運航空，艙等，航站樓，價格），度假產品則要展示（產品圖片，產品名稱，產品類型，起價等）

資源詳情頁，可以說是用戶真正執行需求的開端點。

下面的步驟已經是深入到解決方案設計的層面了。圍繞中心是，需要什么功能才能解決用戶需求。

用戶需要訂到XX酒店的XX房型，用戶需要預訂到XX城市到XX城市的機票位置，用戶需要預訂到X出發日期的XX產品。設想一些用戶使用場景，參考一些成熟網站的做法，設計出頁面的功能模塊。

功能模塊是軀殼，數據是軀殼的“肌肉”，數據來源情況，特殊數據的兼容等是產品設計時需要考慮的（根據優先級放在后面的優化項目里處理）。

產品經理對行業的業務開展要有一定的體驗，至少“沒吃過豬肉也要見過豬跑”。

旅客資料頁的設計要求有一定的業務常識，酒店你只要輸入入住人姓名或者聯系人按理都是OK的。那就要為客人減少輸入項，只要求必須輸入項就OK。 但是機票和度假會涉及到較嚴格的規則校驗，從一個地方到另一個地方是有政策風險的，那么就要證件，姓名，性別等較全面的輸入項。

支付頁，提交成功頁，詳情頁等設計時要考慮客戶可能喜歡用上面支付方式，系統是否有必要，有沒有安全風險。那些內容是提交頁需要展示的，那些可以放到詳情里，頁面之間的銜接流程怎么樣的。

完成上面步驟后產品的初始模樣已經成型,會產出低保真的交互模型 和 功能說明的需求文檔。然后產品還要放到團隊里去評審，打磨，不斷優化，最終定稿。

UI 設計師會根據定稿的低保真原型，調優，畫出高保真的原型。 高保真通過審核后就可以交付給開發人員。

這里由于篇幅問題只講了前端的頁面流程，后臺的操作流程和邏輯流程沒講。其實后臺流程的設計決定了前端頁面的流程，如機票的資源：設置為往返，那么資源列表頁展示的都是往返機票，選擇去程就會固定返程。如果設置為單程，那么兩個單程就可以組成一個往返程，操作頁面就必須先選擇去程，再打開另外一個頁面展示返程。這些以后有機會再講。

這里寫的都是我個人經歷后的理解，不免都說錯了。張小龍說“我說的都是錯的”，他是謙虛，我是實話實說。

其實產品是一直在路上的~~

本文由 @飄雪的南方小城 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議