01情境
先讓人知道這件商品為何存在
- 使用者決策
- 這是不是為我的情境與問題而做？
- 需要證據
- 使用情境、差異、限制與能被確認的核心承諾。
設計後果
首屏先建立方向，規格與深度內容再支撐它。
Shopify 商品頁決策藍圖
商品頁要做的，是幫顧客完成選擇。
一張有效的商品頁，需要讓產品故事、證據、選項、價格條件、疑慮、履約與量測彼此接得起來。這份藍圖先把七個決策層拆開，再用三個工作流重新組合。
商品頁決策介面7 layers / 1 decision
- 情境01
為誰，解決什麼
- 證據02
為何值得相信
- 選擇03
如何選對
- 方案04
現在買到什麼
- 信任05
疑慮在哪解開
- 履約06
接下來會發生什麼
- 量測07
如何看懂決策
- 每項主張
- 有證據
- 每個選擇
- 有狀態
- 每個變更
- 可驗證
商品頁結構
七個區塊，不等於七段內容
這七層描述決策責任，不限定版型。它們可以合併、重排或逐步揭露，但不能在沒有人負責的情況下消失。
02證據
每個主張都要找到最近的證據
- 使用者決策
- 我為什麼應該相信這個差異？
- 需要證據
- 材質、規格、方法、比較、政策或可公開的使用證據。
設計後果
證據跟著主張出現，細節再按需要展開。
03選擇
把選項翻成使用者能判斷的差異
- 使用者決策
- 哪個尺寸、規格或組合才適合我？
- 需要證據
- 差異規則、相容條件、庫存與不可用原因。
設計後果
預設、有效、無效、售罄與錯誤狀態都要可理解。
04方案
讓價格、內容與條件同時改變
- 使用者決策
- 這個選擇現在包含什麼，我付的是什麼？
- 需要證據
- 商品內容、價格組成、優惠或持續條件與例外。
設計後果
摘要、價格與動作必須對應同一個當前狀態。
05信任
在疑慮出現的位置回答疑慮
- 使用者決策
- 如果不適合、出錯或與期待不同，我有什麼依據？
- 需要證據
- 可確認的退換、保固、材質、使用限制與正式政策。
設計後果
避免通用徽章堆疊；把答案放回相關主張與動作附近。
06履約
購買前說清楚下一步
- 使用者決策
- 我能不能買、如何收到，以及有什麼尚未確定？
- 需要證據
- 庫存、履約方式、區域、資格與資料來源。
設計後果
在動作前交代方向，也為未知與不可用狀態提供出口。
07量測
量測決策，不只量測按鈕
- 使用者決策
- 團隊能否知道問題出在理解、證據、選擇還是銷售方案？
- 需要證據
- 事件定義、介面狀態、測試案例與變更註記。
設計後果
事件跟著真實決策節點，避免把每個點擊都當成成功。
僅使用本機狀態的規劃工具
從產品複雜度與問題，收斂三個工作流
先選一種產品複雜度，再標記最多三個 PDP 問題。結果固定回傳三個方向性工作流，讓設計、內容、技術與量測可以談同一件事。
這個規劃器只使用目前頁面的 React 狀態：不儲存、不送出，也不要求輸入網址、產品資料或個人資訊。重新整理後會清空。
範圍邊界
方向可以先形成，範圍要靠證據確認
Planner 幫團隊排列問題，不會代替真實商品、內容來源、系統限制與量測現況。把兩種狀態清楚分開，才能避免把建議誤讀成承諾。
目前可作方向判斷
現在可以形成的方向
用現況描述與代表問題，建立共同語言與需求探索順序。
- 優先處理的 PDP 決策層
- 需要交叉合作的三個工作流
- 候選證據、狀態與驗證輸出
- 需要被回答的範圍問題
探索後才能確認
取得證據後才能確認
只有看過真實資料、狀態與責任邊界，才能定義可驗收的工作。
- 需要新增、改寫或沿用的內容模組
- 佈景主題、App、資料與整合層的責任
- 產品狀態、履約與政策的例外範圍
- 事件、測試案例與發布驗收方式
確認範圍前，需要看見的四種證據
代表商品
選出簡單、複雜、缺貨、例外與高考慮商品，不只看理想樣本。
內容與政策來源
確認誰維護主張、規格、比較、退換、保固與履約資訊。
介面與系統狀態
列出佈景主題、App、商品資料、庫存、價格與購物車的實際責任。
量測與變更紀錄
理解現有事件、資料品質、發布節奏與能被比較的基準。
證據交接
把商品頁交接成可檢查的決策
每一步都留下能被下一個角色使用的輸出。流程可以並行或反覆，但不能靠一句『照設計稿做』跳過責任。
- 01
盤點決策
以代表商品找出七層架構的缺口、矛盾與未知。
交接證據
商品樣本、問題地圖、責任與待確認清單
- 02
排列證據
將主張、選項、銷售方案、疑慮與履約資訊連到可靠來源。
交接證據
主張與證據矩陣、內容順序與來源標記
- 03
設計狀態
讓主要流程、錯誤、售罄、未知與回復路徑都能被看見。
交接證據
狀態圖、互動原型、窄寬與鍵盤案例
- 04
驗證交接
將可見內容、商務結果、事件與發布檢查放在同一套驗收語言。
交接證據
驗收案例、事件字典、異常分派與變更註記
FAQ
商品頁藍圖常見問題
這份藍圖是 Shopify 佈景主題模板嗎？
不是。它先定義商品頁需要承擔的決策、證據與狀態，並不指定佈景主題、區段組合或技術實作。那些範圍需要在需求探索時依現況確認。
Planner 的三個工作流就是專案交付範圍嗎？
不是。三個工作流是方向性假設，用來準備訪談與證據盤點。實際內容、設計、工程與量測範圍，要看過代表商品、資料來源、系統狀態與責任邊界後才能確認。
每個商品頁都需要完整呈現七個區塊嗎？
不需要固定七個視覺區塊。七層代表決策責任，可以合併、重排或按需要揭露；重點是每個必要問題都有可靠答案與可理解狀態。
可以只改首屏，不處理選項與履約嗎？
可以先聚焦首屏，但要清楚記錄它與後續選擇、銷售方案、信任及履約資訊的依賴。若上游主張和下游狀態互相矛盾，單改首屏可能只是把問題往後移。
如何知道商品頁問題來自內容、設計還是技術？
先用代表商品與邊界狀態重現問題，再核對可見內容、資料來源、互動狀態與事件紀錄。證據足夠前，應保留多個假設，不急著把問題歸因到單一職能。