編輯導(dǎo)語(yǔ)：流量時(shí)代，如今不少線下商家都會(huì)選擇使用門店小程序作為用戶引流的方式之一。本篇文章中，作者通過自動(dòng)售貨機(jī)線上購(gòu)物小程序項(xiàng)目，與大家分享小程序端的訂單模塊設(shè)計(jì)心得。

前段時(shí)間筆者接手了一個(gè)自動(dòng)售貨機(jī)線上購(gòu)物小程序的項(xiàng)目，花了幾天時(shí)間設(shè)計(jì)小程序端的訂單模塊，積累了一點(diǎn)設(shè)計(jì)心得。

今天我結(jié)合自身經(jīng)驗(yàn)，基于用戶場(chǎng)景的帶入來給大家分享自動(dòng)售貨機(jī)線上訂單交易模塊的設(shè)計(jì)規(guī)則，也記錄一下這次項(xiàng)目經(jīng)歷。主要有兩個(gè)部分：

1. 基于用戶購(gòu)物場(chǎng)景的訂單交易需求
2. 從訂單狀態(tài)開始構(gòu)建整體訂單邏輯框架

一、基于用戶場(chǎng)景的訂單交易需求

在設(shè)計(jì)訂單模塊之前，我們首先需要了解用戶的購(gòu)物場(chǎng)景。我們的支付寶小程序同時(shí)接入了自動(dòng)售貨機(jī)和智能貨柜。

和電商的訂單交易場(chǎng)景最小閉環(huán)流程不同（選購(gòu)商品——直接購(gòu)買/加入購(gòu)物車 ——去購(gòu)買——填寫地址等信息——支付——等待收貨），自動(dòng)售貨機(jī)線上購(gòu)買流程如下：

選購(gòu)商品——加入購(gòu)物車（自動(dòng)售貨機(jī)沒有這一環(huán)節(jié)）——支付——取貨 。

梳理整個(gè)購(gòu)買流程，可能會(huì)出現(xiàn)以下場(chǎng)景：

• 購(gòu)買前：我要買樓下售貨機(jī)的某個(gè)飲料，在小程序上了買等會(huì)下去吃飯的時(shí)候取；
• 支付成功后：唉，我在小程序買了之后，去哪兒怎么取貨??？
• 啊，我忘記取貨了，我付了錢怎么辦？
• 取貨時(shí)：怎么回事，飲料卡在里面出不來了，我已經(jīng)給錢了怎么辦？
• 取貨后：這瓶飲料好像味道不太對(duì)啊，我要退款！

基于上述場(chǎng)景我們可以歸納產(chǎn)品要體現(xiàn)出的場(chǎng)景包括：

1. 購(gòu)買前：用戶能夠?qū)崿F(xiàn)連貫下單支付操作

這里有幾個(gè)問題值得注意：

（1）購(gòu)買機(jī)器點(diǎn)位問題

雖然能夠在購(gòu)買頁(yè)手動(dòng)選擇要購(gòu)買的機(jī)器點(diǎn)位，但是為了讓用戶的操作成本降到最低，滿足用戶“懶”的心里，我們需要能夠盡可能準(zhǔn)確判斷用戶最可能去取貨的機(jī)器的點(diǎn)位，用戶可以不用手動(dòng)選擇自己想要購(gòu)買的機(jī)器。這里的購(gòu)買首頁(yè)點(diǎn)位顯示的一期邏輯是：

• 對(duì)于有過訂單記錄的用戶（定義為老用戶），購(gòu)買首頁(yè)展示用戶上一次購(gòu)買的機(jī)器點(diǎn)位；
• 對(duì)于沒有過訂單記錄的用戶（定義為新用戶），購(gòu)買首頁(yè)展示離用戶地理位置最近的機(jī)器點(diǎn)位。

（2）是否能夠添加商品到購(gòu)物車？

自動(dòng)售貨機(jī)的交易特點(diǎn)是用戶單次購(gòu)買僅能購(gòu)買一件商品，而智能貨柜的交易數(shù)據(jù)顯示，用戶單次購(gòu)買往往是一次性購(gòu)買多件商品。因此，在智能貨柜線上購(gòu)買過程中，需要有加入購(gòu)物車這一功能，以方便用戶一次性購(gòu)買多件商品。

2. 購(gòu)買后：用戶能夠準(zhǔn)確便捷地取貨

產(chǎn)品頁(yè)面設(shè)計(jì)時(shí)，需要結(jié)合用戶購(gòu)買流程明確地指導(dǎo)用戶取貨地址和取貨方式，避免用戶因不知如何取貨而導(dǎo)致的客訴。

圖1：支付成功后引導(dǎo)取貨-原型

相應(yīng)地，待取貨訂單展示中需要明確標(biāo)識(shí)取貨機(jī)器、取貨方式、取貨時(shí)間等信息。

圖2：待取貨訂單強(qiáng)調(diào)取貨信息-原型

3. 遇到異常情況時(shí)，產(chǎn)品設(shè)計(jì)能夠快速幫助用戶解決問題

每一筆訂單都可能出現(xiàn)異常情況，比如用戶去取貨的時(shí)候發(fā)現(xiàn)機(jī)器卡貨了，或者取貨之后發(fā)現(xiàn)商品過期了等等，一些出貨失敗的情況系統(tǒng)會(huì)自動(dòng)退款，但一些系統(tǒng)無法識(shí)別是否出貨失敗的情況，需要用戶手動(dòng)申請(qǐng)退款。

接下來我們就開始從訂單交易框架搭建開始詳細(xì)講下如何設(shè)計(jì)自動(dòng)售貨機(jī)線上購(gòu)買的交易流程。

二、構(gòu)建整體訂單邏輯框架

訂單交易最基礎(chǔ)的部分是交易流程，從設(shè)計(jì)最小閉環(huán)開始，逐漸往最小閉環(huán)里補(bǔ)充交易流程。訂單模塊的核心分為兩塊：

1. 訂單狀態(tài)

訂單狀態(tài)是定義訂單將按照哪幾個(gè)步驟進(jìn)行的依據(jù)，就像我們?nèi)说纳芷谝粯?，有嬰兒期、少年期、中年期、老年期。訂單狀態(tài)具有幾個(gè)特點(diǎn)：

• 順序性：訂單狀態(tài)需要按照一定的規(guī)則，從前之后順序發(fā)生，不能跳躍，不能逆向。
• 特殊性：訂單狀態(tài)包容異常情況，在順序的過程中都可能因?yàn)橐恍┎僮麟S時(shí)進(jìn)入異常態(tài)。
• 可擴(kuò)展性：訂單狀態(tài)可以隨著業(yè)務(wù)場(chǎng)景的需要添加，但一般不會(huì)刪減。這樣會(huì)影響歷史數(shù)據(jù)。

自動(dòng)售貨機(jī)小程序的訂單設(shè)計(jì)的訂單狀態(tài)：

• 待取貨：用戶支付完成之后，需要在幾小時(shí)內(nèi)去線下取貨，因此在用戶取貨之前訂單狀態(tài)為待取貨；
• 訂單已取消：在設(shè)計(jì)支付流程的時(shí)候，我們是希望盡量能夠讓用戶一步到位地支付成功，但往往因?yàn)楦鞣N原因，用戶可能不能完成支付。比如：調(diào)起支付后，用戶的余額不足無法支付，再比如，在調(diào)起支付之后，用戶突然發(fā)現(xiàn)自己選錯(cuò)了智能貨柜的點(diǎn)位，不想支付了，再或者是由于網(wǎng)絡(luò)不好無法完成支付等等。這時(shí)候用戶退出支付，訂單狀態(tài)則為取消訂單；
• 訂單已完成：用戶支付且取貨成功之后，訂單狀態(tài)為已完成狀態(tài)；
• 退款中：用戶提交退款申請(qǐng)之后，或者用戶超時(shí)未取貨，或者機(jī)器出貨失敗的時(shí)候，用戶需要看到退款是在處理的狀態(tài)；
• 退款成功：客服人員在后臺(tái)手動(dòng)處理，退款成功后的訂單狀態(tài)。

2. 訂單操作

訂單操作是基于訂單狀態(tài)下，可給用戶觸發(fā)的對(duì)該訂單的操作。訂單狀態(tài)一般都由訂單操作觸發(fā)才會(huì)發(fā)生改變。比如買家點(diǎn)擊取貨按鈕后，觸發(fā)訂單由待取貨狀態(tài)變成了已完成狀態(tài)。

在訂單操作設(shè)計(jì)上需要考慮對(duì)訂單功能的用戶群體包括哪些。電商常見的用戶群體包括買家、商家、平臺(tái)管理員。

對(duì)于自動(dòng)售貨機(jī)線上購(gòu)買交易場(chǎng)景來說，訂單模塊的用戶群體主要包括買家平臺(tái)管理員（暫不涉及商家端）。此文僅討論用戶端的訂單基礎(chǔ)流程設(shè)計(jì)（平臺(tái)端的訂單模塊設(shè)計(jì)下次我們?cè)儆懻揾h~）

綜合而言，最后小程序所有的訂單狀態(tài)和用戶對(duì)應(yīng)的訂單操作如下圖：

三、總結(jié)

最后，我們?cè)賮韽?fù)盤下如何基于場(chǎng)景來構(gòu)建訂單體系結(jié)構(gòu)：

第一步：分析用戶場(chǎng)景，找到訂單模塊需要滿足的產(chǎn)品需求；

第二步：根據(jù)用戶購(gòu)買操作流程設(shè)計(jì)訂單狀態(tài)和訂單操作，注意不要忘記訂單異常情況的處理。

本文由 @六元兒 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

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