產品設計實錄-基于購物場景來設計訂單基礎流程

2 評論 4606 瀏覽 21 收藏 9 分鐘

編輯導語:流量時代,如今不少線下商家都會選擇使用門店小程序作為用戶引流的方式之一。本篇文章中,作者通過自動售貨機線上購物小程序項目,與大家分享小程序端的訂單模塊設計心得。

前段時間筆者接手了一個自動售貨機線上購物小程序的項目,花了幾天時間設計小程序端的訂單模塊,積累了一點設計心得。

今天我結合自身經驗,基于用戶場景的帶入來給大家分享自動售貨機線上訂單交易模塊的設計規則,也記錄一下這次項目經歷。主要有兩個部分:

  1. 基于用戶購物場景的訂單交易需求
  2. 從訂單狀態開始構建整體訂單邏輯框架

一、基于用戶場景的訂單交易需求

在設計訂單模塊之前,我們首先需要了解用戶的購物場景。我們的支付寶小程序同時接入了自動售貨機和智能貨柜。

和電商的訂單交易場景最小閉環流程不同(選購商品——直接購買/加入購物車 ——去購買——填寫地址等信息——支付——等待收貨),自動售貨機線上購買流程如下:

選購商品——加入購物車(自動售貨機沒有這一環節)——支付——取貨 。

梳理整個購買流程,可能會出現以下場景:

  • 購買前:我要買樓下售貨機的某個飲料,在小程序上了買等會下去吃飯的時候取;
  • 支付成功后:唉,我在小程序買了之后,去哪兒怎么取貨???
  • 啊,我忘記取貨了,我付了錢怎么辦?
  • 取貨時:怎么回事,飲料卡在里面出不來了,我已經給錢了怎么辦?
  • 取貨后:這瓶飲料好像味道不太對啊,我要退款!

基于上述場景我們可以歸納產品要體現出的場景包括:

1. 購買前:用戶能夠實現連貫下單支付操作

這里有幾個問題值得注意:

(1)購買機器點位問題

雖然能夠在購買頁手動選擇要購買的機器點位,但是為了讓用戶的操作成本降到最低,滿足用戶“懶”的心里,我們需要能夠盡可能準確判斷用戶最可能去取貨的機器的點位,用戶可以不用手動選擇自己想要購買的機器。這里的購買首頁點位顯示的一期邏輯是:

  • 對于有過訂單記錄的用戶(定義為老用戶),購買首頁展示用戶上一次購買的機器點位;
  • 對于沒有過訂單記錄的用戶(定義為新用戶),購買首頁展示離用戶地理位置最近的機器點位。

(2)是否能夠添加商品到購物車?

自動售貨機的交易特點是用戶單次購買僅能購買一件商品,而智能貨柜的交易數據顯示,用戶單次購買往往是一次性購買多件商品。因此,在智能貨柜線上購買過程中,需要有加入購物車這一功能,以方便用戶一次性購買多件商品。

2. 購買后:用戶能夠準確便捷地取貨

產品頁面設計時,需要結合用戶購買流程明確地指導用戶取貨地址和取貨方式,避免用戶因不知如何取貨而導致的客訴。

圖1:支付成功后引導取貨-原型

相應地,待取貨訂單展示中需要明確標識取貨機器、取貨方式、取貨時間等信息。

圖2:待取貨訂單強調取貨信息-原型

3. 遇到異常情況時,產品設計能夠快速幫助用戶解決問題

每一筆訂單都可能出現異常情況,比如用戶去取貨的時候發現機器卡貨了,或者取貨之后發現商品過期了等等,一些出貨失敗的情況系統會自動退款,但一些系統無法識別是否出貨失敗的情況,需要用戶手動申請退款。

接下來我們就開始從訂單交易框架搭建開始詳細講下如何設計自動售貨機線上購買的交易流程。

二、構建整體訂單邏輯框架

訂單交易最基礎的部分是交易流程,從設計最小閉環開始,逐漸往最小閉環里補充交易流程。訂單模塊的核心分為兩塊:

1. 訂單狀態

訂單狀態是定義訂單將按照哪幾個步驟進行的依據,就像我們人的生命周期一樣,有嬰兒期、少年期、中年期、老年期。訂單狀態具有幾個特點:

  • 順序性:訂單狀態需要按照一定的規則,從前之后順序發生,不能跳躍,不能逆向。
  • 特殊性:訂單狀態包容異常情況,在順序的過程中都可能因為一些操作隨時進入異常態。
  • 可擴展性:訂單狀態可以隨著業務場景的需要添加,但一般不會刪減。這樣會影響歷史數據。

自動售貨機小程序的訂單設計的訂單狀態:

  • 待取貨:用戶支付完成之后,需要在幾小時內去線下取貨,因此在用戶取貨之前訂單狀態為待取貨;
  • 訂單已取消:在設計支付流程的時候,我們是希望盡量能夠讓用戶一步到位地支付成功,但往往因為各種原因,用戶可能不能完成支付。比如:調起支付后,用戶的余額不足無法支付,再比如,在調起支付之后,用戶突然發現自己選錯了智能貨柜的點位,不想支付了,再或者是由于網絡不好無法完成支付等等。這時候用戶退出支付,訂單狀態則為取消訂單;
  • 訂單已完成:用戶支付且取貨成功之后,訂單狀態為已完成狀態;
  • 退款中:用戶提交退款申請之后,或者用戶超時未取貨,或者機器出貨失敗的時候,用戶需要看到退款是在處理的狀態;
  • 退款成功:客服人員在后臺手動處理,退款成功后的訂單狀態。

2. 訂單操作

訂單操作是基于訂單狀態下,可給用戶觸發的對該訂單的操作。訂單狀態一般都由訂單操作觸發才會發生改變。比如買家點擊取貨按鈕后,觸發訂單由待取貨狀態變成了已完成狀態。

在訂單操作設計上需要考慮對訂單功能的用戶群體包括哪些。電商常見的用戶群體包括買家、商家、平臺管理員。

對于自動售貨機線上購買交易場景來說,訂單模塊的用戶群體主要包括買家平臺管理員(暫不涉及商家端)。此文僅討論用戶端的訂單基礎流程設計(平臺端的訂單模塊設計下次我們再討論hh~)

綜合而言,最后小程序所有的訂單狀態和用戶對應的訂單操作如下圖:

三、總結

最后,我們再來復盤下如何基于場景來構建訂單體系結構:

第一步:分析用戶場景,找到訂單模塊需要滿足的產品需求;

第二步:根據用戶購買操作流程設計訂單狀態和訂單操作,注意不要忘記訂單異常情況的處理。

 

本文由 @六元兒 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 沒有待支付狀態,所有支付不成功的都是已取消會讓用戶訂單列表里多出很多垃圾數據吧,而且意外的支付失敗后用戶還要重新下單,會不會影響轉化率。

    來自北京 回復
  2. 學到了√

    來自廣東 回復