產品經理電商規劃實錄，解構綜合性電商全維度規劃心法

壹、前言

2020 年在疫情的影響之下，各產業紛紛將銷售戰場轉移至線上電商，今天要分享我在海棠，從 PM 角度如何規劃一個中型綜合性電商專案。

專案目標很明確：提升整體平台效能，打造以用戶為中心的新產品。

因此海棠團隊從UX、UI、前後端規劃階段，均以「效能」、「易用性」作為最重要考量。只是規劃過程中常發現「效能」及「易用性」是兩個極端，需要取捨或找出平衡點，我們團隊幾乎摸索了每個單元的可能性，力求完成一個讓客戶及我們雙贏的電商專案。

而在開始正文之前，想先提醒三個設計綜合性電商時一定要注意的點：

1.效能

綜合性電商的架構通常都會很龐大，不是商品種類、數量繁多，就會有很複雜的行銷活動，而電商是最追求轉換的一種網站型態，每一次等待時間都可能讓使用者突然棄單，因此網站效能是影響成敗的一環。

在這樣的前提下，要盡可能的減少頁面上不必要的資訊，例如在商品內容頁有些平台會放上：別人也逛過什麼、大家都在找什麼、相關配件/類似商品推薦等區塊，只是不是每個區塊都有轉換率的，確可能損害易用性及效能。所以建議 PM 在設計時可以將預期需要的功能做優先性的排序，篩選出最需要的功能。

2. 一致性

另一個需要注意的地方是整個網站的頁面一致性，相似頁面若能統一，在前後端時能省下很多開發時間，整體網站效能也可以有所提升。例如購物車、訂單查詢列表、退訂查詢列表都會需要顯示商品，但商品資訊包含圖片、名稱、款式、數量、原價、特價等，這時就建議都顯示一樣的資訊。

電商的複雜之處在於每一個小功能都是小功能，但全部加總起來平台的載入速度就會慢到沒有來客的程度。

3. 資料來源

最後一個重要事項就是頁面的每個項目的資料來源，諸如是透過後台上稿什麼樣的資料、系統自動帶入什麼時間/範圍的資料、串接特定 API 或為靜態頁面等。有了資料來源，一來是可以確保項目的必要性，二來是 PM 規劃後台時資料會比較清楚，三來是工程師在開發時才不會討厭你。

尤其代理商的 PM 會需要與客戶取得共識，若沒有先定義好，就會造成後續很多的災難。例如熱銷推薦這個功能，可能工程師認為這邊由系統帶入當週的資訊即可，但客戶覺得需要後台人工上稿，或其實客戶有特定的 API 需要串接，就會造成額外的時間浪費，或因架構規劃不同，導致要整個重做這樣的災難。

貳、綜合性電商的功能清單

有了上面的概念後，接著來談綜合性電商常見的單元，並把對應單元內可能有的頁面及功能簡述在下面：

參、各單元頁面的注意事項

開頭有說到在「效能」、「易用性」的平衡下，我們團隊幾乎摸索了每個單元的每種可能性，以下就簡單說明各個單元中需要注意的內容以及可能的做法：

1. 首頁

● Header
首頁的 Header 複雜的地方在於綜合性電商的資料繁雜，包含 Navigation bar、搜尋框、分類功能等，而綜合性電商的分類通成會有 1 - 4 層，需要注意是 Header 一般是寫在全域，如果每個頁面都可以選擇分類到第 4 層，是非常耗效能的。會比較建議只提供篩選到第 2 層，接下來的分類做在商品列表頁即可。

而 Header 的另一個注意事項是在 Header 有各種列表頁、登入註冊、會員中心、訂單查詢、折價券、購物車、追蹤清單、搜尋框、各層分類時，要將哪些資料 Fixed 在最上方？如果全放，就會犧牲掉版面空間，若只放部分內容，就需要綜合考量每個資訊的必要性，且為了一致性考量，建議是每個頁面都共用同樣的 Header 及 Fixed 內容。

● 搜尋
搜尋則有幾種做法，一種是完全匹配，另一種則是模糊搜尋。前者就是只會出現文字完全一模一樣的資料；後者則是有兩種變形，分為交集（多個關鍵字都包含）以及合集（多個中包含其中一個就可以）。因為每個人想像的搜尋方式都不同，在一開始也會需要先做好定義。

2. 登入註冊


● 登入註冊
登入註冊的話，常見的註冊方式就不贅述了。而如果是有第三方綁定的話，會有兩種做法：

a. 一種是每一個第三方登入都算是一個帳號，假設 A 用了 Google、FB、Line、一般註冊的方式，那在會員資料就會有 4 筆。

b. 另一種則需要先註冊一個主帳號，之後在進到會員中心去綁定第三方登入的資料，好處是當使用者習慣使用多種第三方登入方式時，資料可以整併，資料庫內也不會有很多一樣的會員資料。

不過後者的製作也是比前者來得複雜，建議評估整體工時後再確認製作方式。

● 訪客購買
而會員登入的另一個支線是訪客購買，讓使用者在不登入的情況下即可購買，不過這個方式要另外設計流程讓使用者不登入也可以查詢訂單，且無法追蹤會員資料做行銷活動，也可能會遇到奧客在訪客購買幾次後發現沒有累積到會員點數，而找上客服要求要將點數納入會員資料等麻煩。當然也有電商先做了訪客購買，但在最後面詢問是否要加入會員，這也是一個可行的流程。

● 忘記密碼
忘記密碼的流程也有幾種：

a. 一種在登入頁點擊忘記密碼後，會跳出輸入帳號、OTP 的地方，OTP 輸入後可直接更改密碼。

b. 一種是帳號輸入完後，會發送帶有帳號的連結給使用者，點擊連結開啟忘記密碼頁面。

c. 最後一種是帳號輸入完後會直接寄送新密碼給使用者，之後在由使用者去會員中心修改。

第一種的好處是如果透過手機操作，在 Email 或訊息跳出時會直接看到 OTP，可以直接輸入不用在跳轉；但如果是電腦就會需要拿手機或開啟信箱看密碼，且需要在切回本來的頁面。第二種的好處是連結開啟後可以直接輸入新密碼，只是一定會需要開啟信箱或拿手機。第三種的好處是省去使用者先輸入新密碼再登入的麻煩，而是可以直接登入，只是第三種可能會有密碼被他人看到的疑慮。

3. 商品列表頁

● 特殊列表頁
列表頁部分，則有一般的商品列表頁、品牌列表頁、團購列表頁、直播列表頁、紅利專區列表頁、代購專區列表頁、福利品列表頁、員工專區列表頁等列表頁形式，可以依照商品特性或公司屬性去設計特定的列表頁。

●一般列表頁
而一般的商品列表頁也可以有很多變形，例如每一層都可以有一個對應的列表頁，拿冰箱來說，可能的分層為 家電 > 大型家電 > 冰箱 > 180L以上 冰箱 > 特定冰箱，但當然頁面一多整體網站的運轉速度就會變慢，所以建議還是依照上面的建議，安排好每個區塊的優先順序，從優先序高的地方製作起。像 Momo 就省略了大型家電的列表頁，只有製作家電、冰箱的列表頁，並在冰箱列表頁提供公升、品牌的搜尋功能。

4. 商品內容頁
商品內容頁部分，則有幾點需要注意：

● 圖片
圖片常見做法有兩種：

a. 一是很簡單的一整個商品上 6–8 張圖，再點選款式時圖片不會對應更改。

b. 二是先幫整個商品上 overall 的圖，但點選款式時圖片區塊都會對應更換，但後者在後台的時候會需要每個商品都上對應的圖片，且前端製作時也會耗費比較多時間、效能。

而觀看細部圖片的做法常見的也有兩種： 一是使用者可點選後瀏覽，瀏覽方式可以選擇，或點擊圖片出現燈箱 Hover 上去出現放大鏡等。

● 加購品
加購品的做法有包括全站共享一樣的加購品、單一供應商共享一樣的加購品、個別商品有自己的加購品、同樣的加購品在不同的商品內容頁加購會有不同價錢等做法，依據不同的加購規則會影響到內容頁及購物車的設計。

除了加購品來源外，購買每 1 個主商品能加購的加購品數量可能是「每種加購品上限都是 10；或是「所有的加購品加起來上限為 10」；或是購買 1 個主商品時，「每種加購品都要有自己的加購上限」，有些可能是 1，有些可能是 10 之類的。越後面的做法在後台設計上就會越複雜。

在規劃這類加購品邏輯時，還要注意因為效能關係，不可能使用者每點擊一次加購品或主商品數量，就自動計算加購品規則是否正確，會是全部選擇後，點擊加入購物車才做計算。那樣當使用者選擇了超過主商品可購買的加購品時，要求使用者重新選擇數量的加購品的動作可能會讓使用者棄單而去。

當然要規避上面的問題也可以將加購品做在購物車內，但隨之而來的問題是每更新一次加購品數量，就需要確認一次庫存數量，會影響到網站效能，且若加購品數量繁雜，購物車頁面的資訊就會太複雜，也可能造成使用者棄單。更別提若還有複雜的行銷規則的話，購物車的效能、頁面都會變成一個災難。

● 贈品
贈品的來源與加購品大致上一樣，但贈品會比加購品來的簡單很多，沒有那麼多計算的問題，畢竟贈品本來就是額外的東西，若沒貨或選擇不多也不太會影響使用者，也不會影響到整體的價格，因此贈品需注意的反而是要將規則寫清楚，以免使用者以為會送這個贈品，最後卻沒收到引起的客訴。

● 規格、款式
規格及款式在無庫存時也有兩種常見做法，取決於是否要讓使用者在沒貨時可以點選貨到提醒，若會提供貨到提醒，則當該規格已沒有該款式時，加入購物車的按鈕就會改成貨到追蹤的按鈕，因為沒有庫存，不能加入購物車。但若是不會提供貨到提醒的電商，則是在選擇規格後，將沒有的款式反灰，且不能點擊，反之亦然。

5. 購物車
購物車可以說是整個網站最複雜的地方，分成幾個部分來說明：

● 結帳時需區分成幾台車
這邊又可分為商品類型、出貨類型，前者主要是區分商品為冷凍、冷藏、無溫層，後者則依照出貨類型而定，一般一定會區分宅配、超取，有些則會區分這是由電商統一出貨，或供應商出貨，或特殊出貨（如快速出貨、團購、員工專區等）。而供應商出貨也有兩種，一種是一個供應商就一台車，一種是只要是一樣的出貨類型，不論幾個供應商都在同一台車。要區分不同的購物車則與運費有關。

● 付款方式
目前常見的結帳方式為信用卡一次付清、信用卡分期零利率、信用卡分期有利率、Line Pay、Apple Pay、Google Pay、街口、貨到付款、ATM 付款、超商取貨付款、銀聯卡等，也有些會採用 Paypal 或新型態付款方式 Aftee 先享後付等。

這邊的做法主要就是看公司想要串接什麼樣的金流，能否負擔金流費用。但需要注意的是全站共用一樣的結帳方式，或可以依照不同的商品類型／金額／供應商提供不同的結帳方式。而結帳方式也會影響到後續取消訂單的流程，這個會放在訂單部分說明。當然，如同前面一直說明的，越客製化的項目就需要越多的工時，也會比較耗網站的效能。

● 發票方式
目前常見的發票方式則是包含個人、公司發票、捐贈發票，個人的部分有手機條碼、自然人憑證、會員載具，會員載具的做法通常是經由平台向財政部電子發票整合服務平台申請成為會員載具，經核准後，該會員卡（帳號）即可作為儲存雲端發票的載具。當然也可以委託例如綠界等公司協助處理該類發票問題。

● 購物小車
購物小車顧名思義就是小車，一般都會放在 Header 的最右邊，讓使用者可以隨時點擊查看目前購物車內的商品，做法也有幾種：

a. 一是單純是進入購物大車的入口

b. 二是可以 Hover 過去會展開購物車內的商品，根據顯示的項目越詳細，會遇到越多問題，例如可以只顯示每台購物車內有幾個商品的數字（這邊的數字還有兩點注意事項：一是數字顯示的方法，可以以商品品項顯示，假設我買10個一樣的保溫瓶，那數字會出現 1，或以整體數量顯示，數字就會是 10。二是加購品、贈品的算法，有些平台加購品會算，因為有金額，但贈品就不會算一個數量）

c. 三是可以顯示到目前購物車的總數量加上總金額（這邊的問題會是折價券的扣抵要不要出現在購物車，像有些平台會在頁面上一個價錢，但進到購物車是另一個價錢，這邊要顯示頁面上價錢或購物車價錢也是需要討論的）。

d. 最後是直接顯示目前購物車內有的所有商品、數量、特價金額、折價金額等。

只是購物小車通常是做在全域的，如果要運算太多資料，會超級無敵耗效能，一般只有單一產品類別的品牌電商會顯示到那麼細，真正大型的綜合性電商如 PChome、Momo、Pinkoi 都是採用單純進入購物大車的入口的作法。

6. 行銷活動
行銷活動則是最百家爭鳴的地方，每個平台都有一套自己的邏輯，以下
可以分成商品、折價券、購物金三種來說明：

● 商品行銷活動
在商品部分的行銷活動有幾種，折扣方式有只要購買就折 X 折、折 X 元、送贈品等，或要滿 X 件或 X 元（這可以是 X 件／元以上，或需 X 件的倍數）才可以折 X 折、折 X 元、送贈品等。

而適用對象則可以是依照全站、特定館別、特定供應商、特定品牌、特定商品等。這種行銷活動多半都直接與商品綁定，不需要再輸入折價券的折扣碼。

● 折價券行銷活動
在折價券部分的行銷活動與上方商品形式類似，差別在於折價券通常是需要透過輸入折扣碼、按鍵領取或只是給某些特定資格的會員使用。

● 購物金行銷活動
最後是購物金，有些可能稱作紅利金、平台幣等，多是購買了商品且已過商品鑑賞期後，會提供購物金回饋，而這個回饋可以使用在下次結帳時，可以全額使用或依比例使用等。也可能是該購物金可以用在購物金專區，購買專門的商品等。

麻煩的地方在於購物金的到期時間、取消訂單時的購物金返還方式及到期時間等，若是每筆訂單獲得的購物金會有不同的到期時間，在系統就需要額外去計算要先折抵效期較短的購物金。例如若我有 50 點可折抵，20 點 10/30 到期，30 點 11/30 到期，那我 09/15 使用 21 點，就需優先折抵 10/30 的 20 點。也是規則越複雜，在測試、開發上都越困難。

行銷活動最麻煩的地方在於當方式一多，什麼折扣可以與什麼折扣疊加就會需要清楚的列出來，例如使用了商品類型的行銷活動是否能與折價券、購物金疊加使用，若可以疊加但損害到商品毛利率時是要無視毛利率規則，或是所有行銷活動疊加到最後可折抵金額須符合商品特價的哪個比例等。

而在購物車部分是否要幫助使用者算出最優惠的組合，或是都預設什麼樣的資料，再由使用者選擇等。這邊誠心的建議所有要設計行銷活動的 PM 們，一定要記住當這個網站完成後，光是產出測試文件時你就會想吐了，更別提如果你自己就是 QA 的人員，你一定會想回到過去殺死想要「盡善盡美」的自己。

7. 會員中心

會員中心值得注意的地方在「訂單查詢的流程」、「取消訂單的流程」兩種，這個部分建議各位 PM 先由後台規劃起，再規劃前台頁面，原因在於付款、出貨、退貨、退款方式會與目前串接的金流商、物流商、供應商有關，如果先設計了一個訂單是一筆出貨進度條，但到後台時發現是由不同供應商出貨，那前台頁面就要更改，為了減少不必要的時間浪費，建議是由後台規劃完成後，在進行前台頁面的設計：

● 訂單查詢
訂單查詢的流程設計則要看平台想放上什麼樣的訂單資訊，在查詢列表多半會有訂單編號、訂購日期、付款狀態、出貨狀態、物流狀態、結帳金額、商品明細、發票號碼等。在設計上要先界定出貨方式，有些平台是由供應商自行出貨，則在同一個訂單編號下就需要有多條物流狀態才能讓使用者清楚個別的商品進度，而會不會同個供應商還分不同的出貨方式也是需要先確認的。

當然有些平台會提供物流單號、連結供使用者自行查詢，不會再額外做進度條，這也的確是一個比較精簡的做法，至於要不要做可以取決於平台本身有沒有這個動能。

● 取消訂單查詢
至於取消訂單流程就是一個可怕的工程了，首先要決定同一筆訂單需不需要全部一起退貨，通常會依照金流、供應商而定，例如如果是串接聯信的信用卡分期付款就會需要一次退一整筆訂單，無法退訂單內的單一商品；或超商取貨付款在付款前也無法退訂單一商品，而是需要取貨後再行取消訂單。

但另一種狀況是如果平台有多個供應商，在退貨時建議是退訂單一商品，在後台的資料呈現會比較清楚，同時有些商品可能會是無法退訂的，例如貼身衣物或食品等，那當使用者選擇退訂 A 供應商的貼身衣物及 B 供應商的鍋子時，就可能會因為 A 商品不能退而卡住整個流程。

8.追蹤清單

● 追蹤清單與貨到通知
電商的商品繁雜，多半都會提供追蹤清單功能，有些平台也可能將追蹤清單與貨到提醒放在一起，目前常看到的追蹤清單做法是在商品內容頁會提供加入追蹤清單的按鈕，在追蹤清單頁可以單純只是放追蹤的商品，或也可以顯示追蹤商品的到貨、特價狀況，但後者和貨到提醒就會蠻雷同。

若平台同時有追蹤商品和貨到通知的頁面的話，一般差異在於追蹤商品頁面的追蹤價格比目前頁面上低時會在站內或寄信通知使用者，通知後不刪除，而貨到通知頁面則是點選貨到通知後會出現在貨到通知頁面，到貨通知後就從該頁面消失，只通知一次等，好處是使用者可以有一個頁面查找曾經把哪些內容加入貨到通知，不過要不要因此多一個頁面也可以由 PM 自己決定。

另一個可行的做法是使用者點擊貨到通知後，貨到了就寄送一次性的 Email 給使用者即可。

9. 服務中心

● 服務中心
比較常見的服務中心頁面樣式是包含標題、Banner、內文，另一種頁面樣式則是採用 Q&A 的表格形式。在設計後台時建議要加上排序功能，整體操作起來會更順暢。不過服務中心倒不一定要開後台，取決於資料的變動性是否很高，如果其實更新頻率不高，那當作靜態網頁製作，在請工程師修改文字即可。

● 最新消息
一般最新消息都會有後台，這邊的樣式就是常見的標題、Banner、內文，且內文開設 HTML 編輯器即可。不過要注意的是最新消息的上架可能會在非上班時間，所以在設計後台時建議要加上上下架時間，另外是有些會有置頂的需求，那也可以視預算加上置頂或排序功能。

肆、結語

本篇分享我與專案成員在規劃階段的激盪成果，專案雖然會遇到客戶商業策略限制因素影響，在限制之下會有無法改變的規則或功能，但由於我們一直秉持著把專案當成產品來經營的角度，來為客戶規劃數位產品，所以站在我的角度會把所有已知的可能性都提出來討論，期望能確實改善客戶的痛點。

接下來即將進入開發階段，可能又會出現許多可以「借鑑」的經驗，期待下一篇再分享落地經驗。

最後，只要在設計時都記住「效能、一致性、資料來源」（然後還有測試腳本的辛酸），相信你可以規劃一個符合客戶，以及你所期待的網站。