中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

電商產品中，最核心的模塊莫過于訂單。一筆訂單從創建到結束，涉及到復雜的邏輯跳轉和眾多異常處理。本文就結合電商實戰經驗及淘寶訂單設計案例教大家如何基于購物場景來設計電商產品的訂單基礎流程。

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

• 瀏覽商品模塊 – 設計怎樣的商品頁面展示，分類，搜索，推薦，排名等方式，才能更快度的讓用戶找到自己想要的商品?；谄脚_又需要考慮如何平衡商品的權重，讓其盡可能維持一個可持續的生態。
• 下單交易模塊 – 設計怎樣的規則能快速識別用戶對某一商品感興趣了，又怎么設計能快速刺激用戶進行下單，在用戶下單時又怎樣盡可能簡單連貫的讓用戶完成支付行為。
• 訂單跟蹤模塊 – 設計怎樣的訂單跟蹤及提醒操作才能讓用戶放心的把訂單交給系統，設計怎樣的便捷操作才能讓用戶在遇到問題是快速解決。

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

1. 基于用戶場景的訂單交易需求
2. 從訂單狀態開始構建整體訂單邏輯框架
3. 不能忽視的訂單異常處理

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

在設計訂單跟蹤模塊前，我們要先看看現在的用戶怎么在網上下單的。如上所說，現在的人們都被電商行業教育的越來越懶的，搞的很多創業公司一開始就要設計較完整的交易閉環，耗費大量人力和時間。那用戶的“懶”的場景體現在哪些方面呢？

1. 我要購買時，就給我一步支付了吧。不要兩步，懶得我只要一步。
2. 購買成功后，我就不管了?？爝f要到時記得告訴我就好，那個快遞小哥，放我家門口就好，不點收貨了。
3. 不買了，退錢。不要問我為什么，你們去跟商家解釋吧，把錢退給我就行。

還有很多“懶”的場景，用戶之所以能這么懶，是因為他們有懶的資本，而這些的資本都是通過不斷完善的交易流程和產品功能體現的，是產品背后幫助用戶和商家之間規避了很多風險，隱藏了很多需要用戶思考和操作的步驟。那么在產品層面需要考慮哪些關鍵流程來滿足用戶的“懶”呢？基于上述場景我們可以歸納產品要體現出的場景包括：

1. 能對買家實現連貫下單支付操作，不要給用戶猶豫和思考的空間，他只需要點點點，你只需要彈彈彈，直到支付訂單完成。
2. 能在有人購買訂單后給商家快捷的發貨操作。商家也只需要根據你的彈彈彈來進行點點點即可，直到發貨成功。
3. 系統要能實時跟進訂單進度，適時給用戶和商家提醒訂單狀態和物流狀態。系統要能像管家一樣幫助用戶跟蹤交易，確認收貨。
4. 當用戶發大小姐脾氣取消訂單時，你要知道他發脾氣的原因，也要實時幫助她處理好訂單，也要及時通知和安撫好商家。
5. 當用戶需要你出來幫助時，你要能讓她快速找到你，且及時處理問題。

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

1. 設計最小訂單交易閉環，幫助用戶完成基本交易
2. 設計每個交易狀態下的系統觸發機制，幫助用戶自動完成基本交易
3. 設計每個交易狀態下的異常處理，幫助用戶解決更多異常交易場景的問題

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

構建整體訂單邏輯框架

訂單交易最基礎的部分是交易流程，從設計最小閉環開始，逐漸往最小閉環里補充交易流程。但如何設計最小閉環呢，這里我們要先介紹訂單交易里兩個最核心的元素根據場景來定義狀態。核心的部分在于

1、訂單狀態?

2、訂單操作

訂單狀態

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

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

訂單操作

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

一些特殊交易平臺的訂單還包括其他角色，比如夠格產品上有代售功能，就包括的紅人角色。在這里因為管理員是超級權限，基本啥都能干，還可能還會設置等級。所以我們就不做為討論范圍。接著再考慮給對應角色開放什么權限前，先確認改狀態下可以有哪些權限，然后再根據角色身份進行分布。

1. 劃分用戶角色
2. 定義該狀態下所有訂單操作
3. 根據角色設置訂單操作

下面我們就基于訂單狀態來討論下買家和商家對應的訂單操作。

在訂單狀態上，基于訂單交易場景下，完成最小閉關搭建，一般常見的訂單交易最小閉環流程如下

待支付 ?– 待發貨 – 待收貨 – 訂單完成 四種狀態流轉。

1. 待支付：雖然系統設計上盡量讓用戶一步完成支付了，但未支付的狀態還是要保留，因為你永遠不知道用戶啥時候就沒支付。
2. 待發貨：支付完成的訂單，此時買家處于等待狀態，后面基本不需要做什么操作。會通知商家進行發貨。
3. 待收貨：商家已發貨訂單，此時設計最關鍵的功能便是物流跟蹤。
4. 訂單完成：當買家點擊收貨后，這筆訂單才算完全交易完成。

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

商家：查看物流

買家：確認收貨，取消訂單，查看物流

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

• 在狀態時間軸上設置系統定時器功能，替代人工操作更改訂單狀態。如自發貨算起，15天后自動收貨。
• 出于業務需要，添加新的訂單狀態。比如拼團功能需要有待成團狀態。
• 出于業務需要，添加新的訂單操作，比如商家可能無貨了，還沒修改庫存。當有人下單時需要給賣家取消訂單操作。需要在待支付那里商家端添加取消訂單操作。

下面是淘寶的訂單狀態和買家對應的訂單操作。

不能忽視的訂單異常狀態

如果按照正常的訂單狀態走下去，當然是ok的。但并不符合實際情況，在實際場景中，每一筆訂單都有可能因為外界原因導致訂單異常。一般異常的主要情況包括

1. 商家因為某些原因無法發貨
2. 買家因為某些原因要求退款/貨
3. 買家因為某些原因取消訂單

…

在產品層面上，需要對這類異常訂單進行處理。因為異常會發生在任何訂單狀態下，所以需要在對應訂單狀態下考慮異常的可能性，然后根據可能性分別提供給不同用戶角色對應訂單操作按鈕。對異常處理的結果有分兩種：

• 一種是取消異常回歸到正常狀態下
• 一種是處理異常交易結束

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

最后我們再來看下淘寶所有的訂單狀態和買家對應的訂單操作。

最后，我們再來復盤下如何基于場景來構建訂單體系結構。首先我們要分析用戶場景，找到需要訂單系統滿足的需求和提供的能力。其次我們需要定義訂單流程的最小閉環滿足這個需求，在最小閉環中又要借助 定義狀態、設置操作的設計思路來搭建最小閉環。然后我們需要在最小閉環的基礎上，基于業務需求，同樣采用狀態到操作的設計流程補充完善訂單流程。最后，我們要考慮異常處理的狀態和操作，最終完善訂單流程完整閉環。

作者：水度力子，微信公眾號：jdccPM，一年咨詢顧問，兩年產品經驗。曾就職世界500強外企，兩年創業經歷。產品，運營，咨詢分析。

本文由 @水度力子 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議