用好的交互設計來管理複雜-「訂單列表」
訂單系統作為電商系統（O2O產品模式）的「生命線」，貫穿了整個電商系統的全部流程。電商產品系統應該以交易為核心，從用戶點擊確認訂單，形成訂單開始，後續的整個流程都是跟著訂單走的。其中，會有正常訂單和異常訂單，異常訂單其實就是退換貨的流程。我們在設計產品訂單列表界面時，應該根據不同的場景側重，選擇不同的交互結構。
在總結訂單模塊如何設計之前，我們先來熟悉幾個概念及定義：
訂單信息：用戶的訂單記錄列表，顯示訂單主要信息（下單時間、狀態、金額、收貨信息等）。
訂單狀態：交易過程中，訂單可能產生的過程及狀態，如下6類常見訂單狀態：
待付款：下單後的用戶，訂單生成，在此狀態未收到付款請求時，狀態不變。
已付款：訂單收到第三方傳來的付款成功token數據時；
待發貨：在經過風控規則線上和線下的審核後，綜合給出等待發貨的狀態；
已發貨：物流反饋的已發貨數據後，訂單狀態為已發貨；
待收貨（查詢物流狀態）：接入第三方物流平台的實時數據；
已完成：訂單完成，用戶可評價，或者獲得積分。
對於產品交易異常，出現退款的場景，流程如圖所示：
訂單對用戶的作用主要有兩方面，分別是：交易憑證、狀態跟蹤：
1.交易憑證：售後、維權、發票都有據可循；針對買賣雙方的爭議，提供一條依據。
2.狀態跟蹤：交易鏈條較長的訂單有跟蹤訂單狀態的需求，譬如通過淘寶購買一件產品，長時間未收到貨物，用戶希望能看到訂單及物流狀態。如，待下單、待支付、運輸中（相關物流信息查詢）待收貨、待評價......
訂單列表主要包括：訂單信息（商品信息、下單時間及金額、優惠信息等）、訂單狀態、下一步操作。
接下來，我們以各類App的訂單頁為例，分別總結不同產品模式下的訂單列表設計技巧：
較高頻、低復購型產品
用戶最關心的是「待處理」（待支付、待發貨等中間態環節）的訂單情況 ，查詢已購買產品的物流信息。
「待處理」的訂單一般有：
待付款：下單後的用戶，訂單生成，在此狀態未收到付款請求時，狀態不變。
等待發貨：在經過風控規則線上和線下的審核後，綜合給出等待發貨的狀態。
那麼，以淘寶App為例。淘寶的訂單分類，第一層是訂單流轉過程中用戶可認知的狀態，如待付款、待發貨、待收貨…；第二層，即每一種流轉狀態下訂單的子狀態，如，待發貨_買家已付款：買家已付款等待賣家發貨，待收貨_賣家已發貨：賣家已發貨等待買家確認。從買家最本能的認知來劃分訂單的狀態，給用戶最貼心的訂單進度展示，便於用戶隨時查看每一單產品的情況。
高頻、高復購型產品
用戶最關心的是如何快速找到曾購買的產品，產品最關心的是如何通過評價主動觸達用戶，創造動機促使其再次購買。若此類產品已為平台型產品，那麼需要通過篩選的功能，提供多類型訂單的切換，如京東App。京東App提供4類不同使用場景的入口形態，結合不同的需求完成不同的操作：
第一層：常用訂單狀態的快捷入口；
第二層：全部訂單固定入口；
第三層：多種訂單類型切換入口；
第四層：運入口（個人成長體系相結合，促活）、人工接入的功能入口；
還有一類產品，會在固定的訂單狀態的分類基礎之上，直接提供「分類訂單」的二級頁面，以浮層、列表等形式，提供不同的類型給用戶，自行選擇，如大眾點評App。
高頻、強跟蹤型產品
對於外賣型產品，由於存在配送員取貨/送貨的跟進，買家需要在一定時間範圍內拿到外賣。因此，對於配送員的行為，需要在訂單中實時體現，並結合適當的Push機制，讓用戶獲得必要的監控感。
以餓了么為例，其訂單按狀態可分為：未支付訂單，已支付待確認，商家已確認，訂單取消，待配送員搶單，配送員已搶單，已取餐，訂單完成幾種狀態。對於這類型產品，其訂單/支付/物流三系統主流程應有獨立的狀態（包括過程態、節點態），避免耦合在一起，否則隨著業務發展，狀態越來越複雜，降低效率和擴展性。
小Q來總結
對於產品經理而言，在設計訂單系統時，應該充分且完整的梳理清楚交易業務流程以及全部分支流程，並將此作為訂單系統的設計基礎。在做訂單這類系統中，要把訂單流轉的場景行為給梳理出來。摸清事實，構造行為場景，根據用戶不同的行為梳理產品流程。
TAG:交互設計學堂 |