酷播亮新聞
本文主要分為四個部分：簡單說一下購物車、購物車與後台的密切關係、購物車中商品的分組和排序、關於購物車你至少應該知道些什麼。
1.先簡單說一下購物車
對前台電商產品經理來說，設計一個好的購物車，整個網站的靈魂基本上就有了，“設計購物車”可絕對不是說設計購物車的外觀表現形式，而是它背後的東西— —購物車的邏輯。
前台購物車主要與後台商品中心、庫存中心、營銷中心發生關係，你品味一下這三個問題：加車的商品是什麼？ 加車的商品還有麼？ 加車的商品有優惠麼？
關於購物車的作用，大家可以類比一下線下商場的購物車，這種類比方法我已經在上一篇中提到過了。 提一下購物車最直觀的幾個作用：
存儲用戶精挑細選的商品、方便多個商品組合起來做促銷；如果你看得長遠一點就會發現，購物車甚至能幫助自營平台節省物流成本，把同類型商品提前歸集，統一派 分到同一倉庫。
思考一個問題：假設A書和B書在同一個倉庫，如果沒有購物車，A書和B書只能分兩次結算，是不是意味著會生成兩個訂單？ 分配到倉庫後，倉庫管理員有這個能力合單？ （當然，也不是完全做不到~）
在設計前台購物車的時候有兩個重要的關乎用戶體驗的點：購物車中商品的分組和排序，即在購物車中，哪些商品需要歸為一類？ 商品在購物車中怎麼排列？
大家需要注意一點，購物車中的計算、商品數量調整、促銷活動修改、優惠券領取，甚至是商品選中等等操作，都是後台邏輯，前台只是獲取服務器端的數據加以展示而已。
2.舉個例子說明購物車與後台的密切關係
舉個例子：比如商品數量調整，需要從服務器端check該商品是否有對應數量的庫存，對應兩種情況：庫存充足和不足。 實時check商品庫存能緩解‘結算按鈕’的計算壓力，同時能讓用戶購物更流暢。
怎麼理解呢？ 其實在處理前台商品數量增減功能時，如何判斷庫存的問題上，有兩種處理方式：一種是實時check商品庫存，一種是非實時check商品庫存。
說一下後者，第二種方式是在商品加車的那一瞬間（或者刷新購物車頁面）服務器端就已經告訴前台某某商品購物車最大可加車數量是多少了。
再舉個具體的例子對比2種方式的區別，希望能幫助大家深入理解：假設A商品庫存為2，用戶甲將A加入購物車，並在購物車中調整A的數量，最多能調整到2 ；這時用戶乙也將A加入購物車，並且結算了一件A。 此時，我們知道現在A的實際庫存只有1件了。
實時check庫存：用戶甲購物車只能將A數量調整為1；
非實時check庫存：用戶甲購物車仍然能將A的數量調整為2，然而只有當用戶甲點擊“去結算按鈕”時，才會再去check一遍庫存，這時候前台告訴用戶，A商品已經不足 了，您需要返回購物車調整（或者直接在彈層提示上調整A的數量）。
這就是我之前說的實時check商品庫存能緩解“結算按鈕”的計算壓力，同時能讓用戶購物更流暢。 所以，對於前台產品來說，你的購物車基本上沒有多少與你有關係的東西。
不過，你可以從用戶體驗上約定一些規則，比如check庫存的實現方式，如果技術說有難度會造成服務器壓力，那你該怎麼辦呢？ 只能嘗試說服對方，或者退而求其次在‘結算按鈕’附近優化彈層提示，盡量讓用戶體驗更流暢，這就是一個好的前台產品了，絕對不是按鈕多大、怎麼擺放的問題了。
這麼來看，對於一個前台產品，購物車的核心就落在了購物車中商品的分組和排序邏輯上。
所以，接下來的重點內容就是：
- ①如何制定相關規則，讓購物車中的商品有序，讓用戶體驗更好。
- ②關於購物車你至少還要知道些什麼？
3.購物車中商品的分組和排序
說這個分組和排序問題之前，如果大家對這個概念還不太理解，建議先去淘寶或者京東這樣的電商平台看看它們的購物車，特別是產品新人。
再說一說分組和排序大概是要解決一個什麼問題，可以看一看下圖：
從上圖的結構可以看出來，購物車中的商品是按照活動A和B以及未參加活動三個組來展示的，由此也可以看出層級關係為：（店鋪>>）活動>> 商品 （注：別忘了店舖是最大一級）。
基本上每個電商平台都有店舖的概念，也就是允許第三方商家來平台開店，豐富平台商品類目、sku。 在這種情況下，購物車中的商品按照店鋪分組無可厚非了，但是今天為了讓模型更簡單一點，假設平台只有一個店鋪（或者是純自營平台），這是大前提。 所以，接下來要說的就只涉及到參與同一個活動的商品分到一組這種分組的形式（建議再回頭看看上圖）。
然後是關於排序，我們知道給任何一組數據排序都需要給定排序規則，不然就是隨機紊亂呈現的。 對於購物車中的商品，能作為排序依據的無疑是它的加車時間，每個商品加入購物車都會記錄一個加車時間。
接下來需要解決三個問題：
- ①還原商品排序和分組的邏輯判斷與過程；
- ②新加車商品D，該放在哪兒？
- ③如果修改某個商品參加的活動，購物車該如何變動？ （第三點是最能體現用戶體驗的問題。）
假設有如下表所示5個商品，該表記錄了它們的商品名、加車時間以及參加哪個活動5條記錄。 另外，需要補充一句是：一般新加車的商品，排在購物車最上方，不然有可能導致用戶打開購物車看不到自己剛加車的商品。
先解決第一個問題：還原商品排序和分組的邏輯判斷與過程；
購物車的分組與排序是結構化的，程序員的思路也是結構化的，所以大家在考慮產品邏輯的時候，也要有結構化的思維（為了和猿友好相處），一個商品加入購物車首先 第一步是判斷（它是哪家店舖的？），它是哪個活動底下的？ 它的加車時間是什麼？ （從大到小的邏輯順序）有了這個過程之後，這個商品的位置自然也確定了，如下表所示：
你可以看到商品B1加車比商品A2晚，但是卻排在了商品A2之後，這是什麼原因呢？
這裡需要將排序問題分為三類：組與組之間排序、組內排序、組與非組（單個商品）之間排序。
- 先說第一類，有一個規則是組內最晚加車的商品為該組的加車時間，以組的加車時間為依據進行組與組之間排序。
- 再說第二類，按照組內後加車商品在上規則排序。
- 最後說第三類，組的加車時間與單個商品加車時間，後加車者在上規則排序，類似於第二類情況。
下面再解決第二個問題：新加車商品D（12:00加車），該放在哪兒？
如果D沒有參加任何活動，很明顯按照第三類規則，需要將D置於購物車第一位，這裡不用表來展示了；但是如果D參加了活動B，那麼當用戶進入購物車頁，他 將看到什麼呢？ 如下圖所示。
注意，由於商品D參加了活動B，導致商品B1和B2都跟著往上移動了。
最後再來說最重要的一個問題：如果修改某個商品參加的活動，購物車該如何變動？
說這點之前，先說為什麼它很重要，第2個有關排序的問題發生場景其實不在購物車頁，而是用戶在進入購物車場景前，就已經發生了，用戶進入購物車看到的是 一個靜態的頁面；但是第三個問題，發生場景就在購物車中，正所謂是牽一發而動全身，試想一下，用戶只是調整了一下購物車中商品所參加的活動，購物車排序大 動，導致用戶找不到剛調整過的商品，這種體驗可想而知。
還需要說到另外一點是，這也是前文制定這樣一個排序和分組規則的原因，當然也是為了解決問題3，提升用戶體驗。
假設商品C參加了活動A或B（一開始只是用戶故意選擇不參加任何活動），那麼當用戶將商品C修改為參加活動A或B後，它的位置將如何變動？ 這裡我就不再提供表格，大家去思考一下，實在不明白可以在文後提問我。
補充說明一點，為什麼會有不參加活動的選項？
大家思考一下這個問題：假設平台滿30包郵，不滿則出6元郵費，現在商品E（單價=30元）參加了滿30減5的活動，用戶購買一件E，問，該用戶應該參加 活動麼？ 為什麼？ （這個問題有一個前提是，平台計算是否滿包郵的條件是以優惠後應付金額為準）
本文最重要的一部分算是講完了，之後該講一點其他細枝末節的東西了，關於購物車你還應該知道些什麼？
4.關於購物車你至少應該知道些什麼？
我覺得關於購物車你還應該知道的應該在下面這張腦圖裡了，第一是購物車中的商品從哪兒來到哪兒去，第二是購物車至少需要具備那幾個功能點（我 這裡說的是骨架），至於其他錦上添花的功能，讀者可以留言分享給大家。
另外在設計購物車的時候，還有一個影響體驗的細節——購物車合併問題，當一個用戶在未登錄狀態加車，在他下次登陸賬戶時，應該將未登錄狀態已加車商品並 入已登錄賬戶購物車中。 這裡也有一個前提是：默認未登錄狀態也可以加購物車。
本篇到這裡算是結束了，很多東西感覺沒有說透，可能需要讀者自己去深入研究，如果有什麼心得體會，也歡迎大家一起交流。
相關閱讀
作者：QJQ，微信公眾號：倔牛的人生
本文由 @QJQ 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自pixabay，基於CC0協議