Shopify 改版若從競品截圖和首頁 moodboard 開始，團隊很容易花大量時間換視覺，卻保留原本的商品資料、搜尋、變體和營運問題。研究的目的是找出誰在哪個任務受阻、證據有多強、修正後如何驗收，再決定要調整 Theme、流程、內容或系統。
先寫三到五個決策問題，例如「手機商品頁為何選錯規格」或「行銷為何每次活動都要工程支援」。
建立量化基準
從 Shopify、GA4、搜尋、客服、退貨、廣告和速度資料整理裝置、市場、來源與新舊客。觀察商品到加購、購物車到結帳、付款錯誤、搜尋零結果、退貨原因和內容發布時間。先檢查事件品質，不把缺漏追蹤當成顧客流失。
基準使用一段足以涵蓋週期的資料，標記大促、缺貨和網站事件。總平均可能掩蓋手機或特定市場問題，分群才有行動意義。
客服和站內搜尋提供問題語言
將 ticket、聊天和退貨原因分類，保留顧客原句與出現頻率。站內 query 顯示顧客用什麼詞找商品、哪些需求沒有結果。這些資料適合產生研究假設，仍需搭配頁面和使用情境確認原因。
和客服、門市、電商、內容與倉儲訪談，找出人工 workaround。顧客看不到的後台摩擦也會造成價格、庫存和回覆延遲。
訪談與任務測試分開
訪談了解習慣、理解和過去經驗；可用性測試則觀察顧客實際找商品、比較、選 variant 和付款。不要在訪談裡問「你喜歡這個新版嗎」代替任務。招募涵蓋主要品類、裝置、市場與新舊客，不只找內部同事。
測試現有網站，能找到真實問題；測 prototype 則驗證新方向。兩者有不同目的，報告應標明證據來源。
做內容與技術 audit
盤點頁型、sections、metafields、App、integrations、redirect、schema、accessibility 和 performance。找重複內容、孤兒頁、無 owner 欄位、App 重疊和直接修改 production Theme 的流程。這些限制會影響設計能否落地。
技術 audit 不直接決定重建。把每個問題連到顧客或營運影響，再比較局部修正、Theme 更新、重新設計與 Headless 的成本。
競品研究看模式和差異
選相同品類、相同商業模式與高品質跨產業參考，完成同一組任務。記錄資訊、互動、內容與限制，不複製畫面。競品都有的功能可能是類別預期，也可能只是共同習慣，需要自己的研究驗證。
保留來源日期和市場，避免把已過時或不適用台灣金物流的模式帶進需求。
將發現寫成證據表
每項發現包含問題、受影響使用者、來源、頻率、嚴重度、商業風險、假設和驗收方式。三角驗證比單一訊號可靠，例如搜尋零結果、客服詢問和任務測試都指向尺寸命名問題。
優先處理交易阻斷、資料錯誤和高頻摩擦，再安排品牌與內容機會。沒有證據的想法保留為探索，不冒充已知需求。
招募不能只找最方便的人
依主要市場、品類、裝置、購買頻率、新舊客和需要輔助技術者建立樣本。內部同事熟悉商品與公司術語，適合早期 smoke test，不適合代表一般顧客。若 B2B 有採購、使用者和核准者，也要分別研究。
記錄招募條件、實際樣本和缺口。五位訪談能發現問題，不能直接推估全體比例；量化問卷也需要避免自選偏差和引導題。
研究資料需要隱私治理
Session replay、客服、訂單和訪談可能包含個資。只收集決策必要資料，遮蔽付款、地址和敏感欄位，限制存取與保存期限。錄影與逐字稿取得同意，參與者知道用途和退出方式。
研究工具供應商也要核對資料區域、subprocessor、刪除和權限。不要為了改版方便，把 production 顧客資料任意下載到個人裝置。
先做小修正再決定重建
研究若找到明確、低風險問題，例如尺寸入口難找或 App 重複，可先修正並觀察。不是每項發現都需要整站重設。相反地，資料模型、導覽和多市場流程彼此牽連時，才可能需要較大範圍。
建立 option table，比較不改、局部改善、Theme 重構、換 Theme 和 Headless 的成本、風險、依賴與可逆性。這能避免「既然做研究，就一定要大改」的預設結論。
最後把研究轉成 Shopify 專案需求書、旅程、內容模型、元件與測試基準。上線後用同一指標和任務回測，才能知道改版解決了什麼，而非只證明網站看起來不同。