昨晚夢到甲方粑粑要搞個旅游App，做App成本又太高，所以先搞個小程序試試水。

目錄

一、引言

1.1 文檔屬性

1.2 歷史修訂

1.3 背景

甲方粑粑丟下一句話“能看、能買、能傳播”。他要一個O2O旅游小程序，第一版呢，希望用戶在小程序上可以看到各種旅游資訊（內容），還可以直接在小程序上下單（支付）

二、全局功能說明

2.1 功能邏輯流程圖

2.2 功能結構圖

ps：紅字部分可在產品1.0.0版本之后考慮分批上線。

2.3 訂單流程

三、思維導圖

3.1 產品信息結構圖

資訊模塊信息結構圖：

ps：為了照顧前端同學，富文本的玩法沒玩過，加上目前時間又緊迫，就設計出了一個圖文表，專門用來存文章中的內容的。

這樣的話，文章與圖文是1對多的關系，一組圖文包括（標題、描述、圖、標注）（這4個字段都可以選填）。

比如：

商品、用戶、訂單信息結構圖：

先只考慮旅游的商品版塊，后期會新增一個活動的商品版塊，用戶購買活動的時候，有些紙質票非電子票是需要用戶填寫收貨地址的。

在建模時，需要注意的就是：訂單主表中存儲地址庫id和買家具體地址組合成購物地址，不依賴用戶收貨地址的信息，因為用戶的收貨地址是可能發(fā)生人為的修改的。

ps：產品模型和業(yè)務模型千萬不要混在一起。

3.2 產品結構圖

3.3 業(yè)務流程圖

角色：客服、后臺運營、用戶。

用戶可線上負責預約、交易以及線下體驗，用戶通過小程序購買旅游產品下單，客服在后臺可管理訂單聯(lián)系用戶，后臺運營可管理小程序上得商品、資訊等…

用戶使用流程

3.4 頁面流程圖

四、 原型圖

4.1 歡迎頁

4.2 首頁_商城

ps：這個商城主頁有6個模塊，分別是Banner、icon模塊、新品&獨家、主題推薦、攻略資訊、猜你喜歡。

…往下滑動…

頁面邏輯：

1. Banner、主題推薦、攻略資訊：根據(jù)后臺參數(shù)跳轉不同頁面，類型如下：資訊文章、商品詳情、H5活動。
2. icon模塊：固定4個icon（國內、海外、品牌、體驗），其它的是后臺給就顯示，不給就隱藏，統(tǒng)一跳轉篩選列表，根據(jù)分類字段查詢列表信息，頁面樣式統(tǒng)一。
3. 新品&獨家、猜你喜歡：根據(jù)商品id，跳轉不同的商品詳情頁。

4.2.1 商品詳情頁

頁面邏輯：

1. 客服按鈕點擊事件:跳轉客服聊天窗口，若未登錄提示登錄。
2. “選擇套餐”與“立即預訂”跳轉至選擇套餐頁。
3. “包含費用、產品詳情、訂購須知”通過分類字段判斷查詢對應內容進行展示。

4.2.2 商品選擇套餐

4.2.3 信息填寫

4.2.4 支付

4.2.5 訂單

ps：訂單待支付狀態(tài)，超過3小時，自動失效。

ps：旅游訂單狀態(tài)有6種，已支付、待支付、賣家確認成功、預約失敗、訂單已失效、訂單已取消。

部分功能之間相互獨立，我們先可上一部分，未上傳部分：

• 小程序端（4.3 資訊、4.3.1 資訊列表、4.3.2 資訊城市、4.3.3 資訊詳情、4.4我的）
• 后臺管理系統(tǒng)
• 未完待續(xù)…

五、排期

草稿圖

六、總結7句真言

1. 可能很多人會認為原型注釋用線和箭頭，會很亂。我覺得這種注釋方法還是得分場景的，比如：我這邊小程序的整體布局是線性式的
2. 建模時注意功能之間適度顆粒大小，遵循MECE原則，相互獨立、完全窮盡。模塊之間高內聚低耦合，讓每個模塊，盡可能的獨立完成某個特定的子功能。模塊與模塊之間的接口，盡量的少而簡單
3. 服務器能做的事情，就別交給小程序做（看情況）
4. 項目開始前的啟動會議（不要以為形式感強，這是儀式感）
5. 向計算機科學家輸出一種使命感，做比自己更重要的事情！
6. 項目過程中，負面信息自己及時處理，千萬別在團隊擴散，以防帶亂節(jié)奏。適當多鼓勵，所受榮譽分享給大家（成就別人成就自己）
7. 暫時還沒想到…

以上為個人對本次項目進行解構后的理解，說的不一定對，具體情況具體分析，適合團隊的才是最好的。

#專欄作家#

Bass小南，微信公眾號：PMBass，人人都是產品經理專欄作家。擅長功能設計、原型設計，專注電商、游戲、人工智能等多領域。

本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自pexels，基于CC0協(xié)議