如何基于購物場景來設(shè)計(jì)訂單基礎(chǔ)流程？

電商產(chǎn)品中，最核心的模塊莫過于訂單。一筆訂單從創(chuàng)建到結(jié)束，涉及到復(fù)雜的邏輯跳轉(zhuǎn)和眾多異常處理。本文就結(jié)合電商實(shí)戰(zhàn)經(jīng)驗(yàn)及淘寶訂單設(shè)計(jì)案例教大家如何基于購物場景來設(shè)計(jì)電商產(chǎn)品的訂單基礎(chǔ)流程。

說到電商類產(chǎn)品，我們都不會陌生，做為普通人也應(yīng)該知道電商產(chǎn)品是完成人們購買商品的平臺。但作為產(chǎn)品經(jīng)理，需要用模塊化的視覺來看電商產(chǎn)品。我們可以根據(jù)用戶使用場景簡單的將電商產(chǎn)品拆分成瀏覽商品、下單交易，訂單跟蹤三個(gè)模塊。在每個(gè)模塊的設(shè)計(jì)中都需要基于場景來進(jìn)行功能及邏輯設(shè)計(jì)，在經(jīng)歷過十幾年的電商發(fā)展歷史，用戶早已被教育的傻白甜。最快速的找到想到的商品，最簡單的下單購買，最便捷的交易處理，這些才是用戶需要的。如果從上面的三個(gè)模塊來看

瀏覽商品模塊 – 設(shè)計(jì)怎樣的商品頁面展示，分類，搜索，推薦，排名等方式，才能更快度的讓用戶找到自己想要的商品?；谄脚_又需要考慮如何平衡商品的權(quán)重，讓其盡可能維持一個(gè)可持續(xù)的生態(tài)。

下單交易模塊 – 設(shè)計(jì)怎樣的規(guī)則能快速識別用戶對某一商品感興趣了，又怎么設(shè)計(jì)能快速刺激用戶進(jìn)行下單，在用戶下單時(shí)又怎樣盡可能簡單連貫的讓用戶完成支付行為。

訂單跟蹤模塊 – 設(shè)計(jì)怎樣的訂單跟蹤及提醒操作才能讓用戶放心的把訂單交給系統(tǒng)，設(shè)計(jì)怎樣的便捷操作才能讓用戶在遇到問題是快速解決。

正如本文主題所示，這篇文章不是要跟大家講明白電商產(chǎn)品的設(shè)計(jì)規(guī)則，我也不可能在一篇文章中把淘寶十幾年的東西給大家講明白。但我們可以專注來看下訂單交易的基礎(chǔ)部分，訂單模塊邏輯設(shè)計(jì)。也就是上面說的第三個(gè)模塊問題訂單跟蹤模塊。我將結(jié)合自身經(jīng)驗(yàn)和淘寶設(shè)計(jì)規(guī)則，基于用戶場景的帶入來給大家分享訂單交易模塊的設(shè)計(jì)規(guī)則。主要有三個(gè)部分

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

從訂單狀態(tài)開始構(gòu)建整體訂單邏輯框架

不能忽視的訂單異常處理

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

在設(shè)計(jì)訂單跟蹤模塊前，我們要先看看現(xiàn)在的用戶怎么在網(wǎng)上下單的。如上所說，現(xiàn)在的人們都被電商行業(yè)教育的越來越懶的，搞的很多創(chuàng)業(yè)公司一開始就要設(shè)計(jì)較完整的交易閉環(huán)，耗費(fèi)大量人力和時(shí)間。那用戶的“懶”的場景體現(xiàn)在哪些方面呢?

我要購買時(shí)，就給我一步支付了吧。不要兩步，懶得我只要一步。

購買成功后，我就不管了?？爝f要到時(shí)記得告訴我就好，那個(gè)快遞小哥，放我家門口就好，不點(diǎn)收貨了。

不買了，退錢。不要問我為什么，你們?nèi)ジ碳医忉尠?，把錢退給我就行。

還有很多“懶”的場景，用戶之所以能這么懶，是因?yàn)樗麄冇袘械馁Y本，而這些的資本都是通過不斷完善的交易流程和產(chǎn)品功能體現(xiàn)的，是產(chǎn)品背后幫助用戶和商家之間規(guī)避了很多風(fēng)險(xiǎn)，隱藏了很多需要用戶思考和操作的步驟。那么在產(chǎn)品層面需要考慮哪些關(guān)鍵流程來滿足用戶的“懶”呢?基于上述場景我們可以歸納產(chǎn)品要體現(xiàn)出的場景包括：

能對買家實(shí)現(xiàn)連貫下單支付操作，不要給用戶猶豫和思考的空間，他只需要點(diǎn)點(diǎn)點(diǎn)，你只需要彈彈彈，直到支付訂單完成。

能在有人購買訂單后給商家快捷的發(fā)貨操作。商家也只需要根據(jù)你的彈彈彈來進(jìn)行點(diǎn)點(diǎn)點(diǎn)即可，直到發(fā)貨成功。

系統(tǒng)要能實(shí)時(shí)跟進(jìn)訂單進(jìn)度，適時(shí)給用戶和商家提醒訂單狀態(tài)和物流狀態(tài)。系統(tǒng)要能像管家一樣幫助用戶跟蹤交易，確認(rèn)收貨。

當(dāng)用戶發(fā)大小姐脾氣取消訂單時(shí)，你要知道他發(fā)脾氣的原因，也要實(shí)時(shí)幫助她處理好訂單，也要及時(shí)通知和安撫好商家。

當(dāng)用戶需要你出來幫助時(shí)，你要能讓她快速找到你，且及時(shí)處理問題。

ok，以上只是訂單交易過程中可能發(fā)生的場景，產(chǎn)品需要從這些場景中抽象出產(chǎn)品需要解決的問題，進(jìn)而設(shè)計(jì)功能模塊和邏輯框架。當(dāng)然，我們也要帶著產(chǎn)品自己的體系去設(shè)計(jì)功能，畢竟用戶是需要在體系里被教育的，不過是教育他們更好的使用產(chǎn)品獲得更好的體驗(yàn)罷了。那我們從場景中進(jìn)行抽象訂單交易過程需要解決的問題包括

設(shè)計(jì)最小訂單交易閉環(huán)，幫助用戶完成基本交易

設(shè)計(jì)每個(gè)交易狀態(tài)下的系統(tǒng)觸發(fā)機(jī)制，幫助用戶自動完成基本交易

設(shè)計(jì)每個(gè)交易狀態(tài)下的異常處理，幫助用戶解決更多異常交易場景的問題

接下來我們就開始從訂單交易框架搭建開始詳細(xì)講下如何設(shè)計(jì)電商交易流程

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

訂單交易最基礎(chǔ)的部分是交易流程，從設(shè)計(jì)最小閉環(huán)開始，逐漸往最小閉環(huán)里補(bǔ)充交易流程。但如何設(shè)計(jì)最小閉環(huán)呢，這里我們要先介紹訂單交易里兩個(gè)最核心的元素根據(jù)場景來定義狀態(tài)。核心的部分在于

1、訂單狀態(tài)

2、訂單操作

訂單狀態(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ù)。

訂單操作

訂單操作是基于訂單狀態(tài)下，可給用戶觸發(fā)的對該訂單的操作。訂單狀態(tài)一般都由訂單操作觸發(fā)才會發(fā)生改變。比如買家點(diǎn)擊收貨按鈕后，觸發(fā)訂單由待收貨狀態(tài)變成了已完成狀態(tài)。訂單狀態(tài)一般設(shè)計(jì)為買家和商家共用，但訂單操作一般是獨(dú)立設(shè)計(jì)的。所以在訂單操作設(shè)計(jì)上就需要考慮對訂單功能的用戶群體包括哪些。常見的用戶群體包括買家、商家、平臺管理員。

一些特殊交易平臺的訂單還包括其他角色，比如夠格產(chǎn)品上有代售功能，就包括的紅人角色。在這里因?yàn)楣芾韱T是超級權(quán)限，基本啥都能干，還可能還會設(shè)置等級。所以我們就不做為討論范圍。接著再考慮給對應(yīng)角色開放什么權(quán)限前，先確認(rèn)改狀態(tài)下可以有哪些權(quán)限，然后再根據(jù)角色身份進(jìn)行分布。

劃分用戶角色

定義該狀態(tài)下所有訂單操作

根據(jù)角色設(shè)置訂單操作

下面我們就基于訂單狀態(tài)來討論下買家和商家對應(yīng)的訂單操作。

在訂單狀態(tài)上，基于訂單交易場景下，完成最小閉關(guān)搭建，一般常見的訂單交易最小閉環(huán)流程如下

待支付 – 待發(fā)貨 – 待收貨 – 訂單完成 四種狀態(tài)流轉(zhuǎn)。

待支付：雖然系統(tǒng)設(shè)計(jì)上盡量讓用戶一步完成支付了，但未支付的狀態(tài)還是要保留，因?yàn)槟阌肋h(yuǎn)不知道用戶啥時(shí)候就沒支付。

待發(fā)貨：支付完成的訂單，此時(shí)買家處于等待狀態(tài)，后面基本不需要做什么操作。會通知商家進(jìn)行發(fā)貨。

待收貨：商家已發(fā)貨訂單，此時(shí)設(shè)計(jì)最關(guān)鍵的功能便是物流跟蹤。

訂單完成：當(dāng)買家點(diǎn)擊收貨后，這筆訂單才算完全交易完成。

在基于四種訂單狀態(tài)，我們從商家、買家兩種用戶角色上進(jìn)行劃分。比如待收貨狀態(tài)，一般包括“確認(rèn)收貨”“取消訂單”“查看物流”操作。確認(rèn)收貨是相對買家的權(quán)益保護(hù)，只能開放給買家。取消訂單按道理商家也可以開放，但一般出于對訂單保護(hù)，尤其在賣家已經(jīng)發(fā)貨的狀態(tài)下。不會開放給商家，只會開放給買家。查看物流是雙方都可以進(jìn)行的操作。所以我們可以安排如下：

商家：查看物流

買家：確認(rèn)收貨，取消訂單，查看物流

按照這個(gè)思路，我們就可以得出待支付、待發(fā)貨、待收貨、訂單完成狀態(tài)下的訂單操作。從而得出最小閉環(huán)的訂單流程。后面可以基于這個(gè)最小閉環(huán)完善訂單流程。一般常見的操作包括:

在狀態(tài)時(shí)間軸上設(shè)置系統(tǒng)定時(shí)器功能，替代人工操作更改訂單狀態(tài)。如自發(fā)貨算起，15天后自動收貨。

出于業(yè)務(wù)需要，添加新的訂單狀態(tài)。比如拼團(tuán)功能需要有待成團(tuán)狀態(tài)。

出于業(yè)務(wù)需要，添加新的訂單操作，比如商家可能無貨了，還沒修改庫存。當(dāng)有人下單時(shí)需要給賣家取消訂單操作。需要在待支付那里商家端添加取消訂單操作。

下面是淘寶的訂單狀態(tài)和買家對應(yīng)的訂單操作。

不能忽視的訂單異常狀態(tài)

如果按照正常的訂單狀態(tài)走下去，當(dāng)然是ok的。但并不符合實(shí)際情況，在實(shí)際場景中，每一筆訂單都有可能因?yàn)橥饨缭驅(qū)е掠唵萎惓?。一般異常的主要情況包括

商家因?yàn)槟承┰驘o法發(fā)貨

買家因?yàn)槟承┰蛞笸丝?貨

買家因?yàn)槟承┰蛉∠唵?/p>

…

在產(chǎn)品層面上，需要對這類異常訂單進(jìn)行處理。因?yàn)楫惓l(fā)生在任何訂單狀態(tài)下，所以需要在對應(yīng)訂單狀態(tài)下考慮異常的可能性，然后根據(jù)可能性分別提供給不同用戶角色對應(yīng)訂單操作按鈕。對異常處理的結(jié)果有分兩種：

一種是取消異?；貧w到正常狀態(tài)下

一種是處理異常交易結(jié)束

異常訂單需要添加兩種狀態(tài)，一種是處理中狀態(tài)，一種是處理結(jié)束狀態(tài)。比如“申請退款中”是處理中狀態(tài)，“交易關(guān)閉”是處理結(jié)束狀態(tài)。在淘寶中，給用戶看到的狀態(tài)只有兩類，一是正常交易狀態(tài)，一是異常處理結(jié)束狀態(tài)，其產(chǎn)品系統(tǒng)后臺將所有異常處理中的狀態(tài)都封裝了。

最后我們再來看下淘寶所有的訂單狀態(tài)和買家對應(yīng)的訂單操作。

最后，我們再來復(fù)盤下如何基于場景來構(gòu)建訂單體系結(jié)構(gòu)。首先我們要分析用戶場景，找到需要訂單系統(tǒng)滿足的需求和提供的能力。其次我們需要定義訂單流程的最小閉環(huán)滿足這個(gè)需求，在最小閉環(huán)中又要借助 定義狀態(tài)、設(shè)置操作的設(shè)計(jì)思路來搭建最小閉環(huán)。然后我們需要在最小閉環(huán)的基礎(chǔ)上，基于業(yè)務(wù)需求，同樣采用狀態(tài)到操作的設(shè)計(jì)流程補(bǔ)充完善訂單流程。最后，我們要考慮異常處理的狀態(tài)和操作，最終完善訂單流程完整閉環(huán)。