產(chǎn)品設(shè)計(jì)實(shí)錄-基于購物場景來設(shè)計(jì)訂單基礎(chǔ)流程

六元兒
2 評論 4662 瀏覽 21 收藏 9 分鐘
🔗 B端产品经理需要进行售前演示、方案定制、合同签订等,而C端产品经理需要进行活动策划、内容运营、用户激励等

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

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

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

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

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

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

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

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

梳理整個(gè)購買流程,可能會出現(xiàn)以下場景:

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

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

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

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

(1)購買機(jī)器點(diǎn)位問題

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

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

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

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

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

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

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

相應(yīng)地,待取貨訂單展示中需要明確標(biāo)識取貨機(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)會自動退款,但一些系統(tǒng)無法識別是否出貨失敗的情況,需要用戶手動申請退款。

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

二、構(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ù)場景的需要添加,但一般不會刪減。這樣會影響歷史數(shù)據(jù)。

自動售貨機(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);
  • 退款中:用戶提交退款申請之后,或者用戶超時(shí)未取貨,或者機(jī)器出貨失敗的時(shí)候,用戶需要看到退款是在處理的狀態(tài);
  • 退款成功:客服人員在后臺手動處理,退款成功后的訂單狀態(tài)。

2. 訂單操作

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

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

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

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

三、總結(jié)

最后,我們再來復(fù)盤下如何基于場景來構(gòu)建訂單體系結(jié)構(gòu):

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

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

 

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

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

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

    來自北京 回復(fù)
  2. 學(xué)到了√

    來自廣東 回復(fù)
专题
19553人已学习13篇文章
本专题的文章分享了跨境支付的行业、发展、支付方式和商业等信息。
专题
15317人已学习14篇文章
交互设计本质上就是设计产品的使用方式的过程,“如何才能做出合理的B端交互决策”是很多人都在思考的问题。本专题的文章分享了B端交互设计指南。
专题
12426人已学习15篇文章
当业务进入某一阶段之后,用户新增可能会趋向疲软,这个阶段里,运营人员可能会需要召回流失用户。本专题的文章分享了用户召回策略。
专题
12363人已学习12篇文章
关于如何写简历、简历上些什么的文章大家看了很多。那么细分到产品经理这个岗位来说,写简历又有什么需要注意的呢?本专题的文章分享了产品经理如何写简历。
专题
14977人已学习13篇文章
本专题的文章分享了搭建营销中心指南。