Shopify 2.0 讓多數 template 可以加入 sections，內容團隊不必為每張活動頁找工程師。但若每個 section 都有數十個開關，或所有內容都塞進同一個萬用模組，編輯器會變得難以理解，前台也容易失去一致性。
規劃區塊時要同時服務兩種人：顧客需要清楚、穩定的頁面；營運者需要在不破壞品牌和交易流程的前提下更新內容。
先從頁型任務開始
列出首頁、商品、集合、活動、文章與品牌頁的主要任務。商品頁要協助理解、選擇和購買，活動頁要快速組合主張、商品與證據。相同視覺不代表相同責任；一個 hero 若在商品頁要讀取商品資料，在活動頁則需要人工選圖，可能適合分成不同 section。
再找出跨頁重用的內容模式，例如媒體加文字、賣點卡、FAQ、logo wall 和推薦商品。只有會被重複使用且規則一致的模式，才值得抽成共用模組。
Section 負責一段完整內容
Section 應有清楚目的和外層版面，block 則代表可重複或可排序的子項目。例如 FAQ section 內含多個 question block；圖文 section 內的圖片與文字通常是一組 settings，未必需要拆成 blocks。
Shopify 的 blocks best practices建議依功能決定 section 與 block 的邊界。切得太碎，營運者要拼很多零件；切得太大，又無法調整內容順序。
Schema 是內容介面
每個 setting 使用最符合資料的型別：image picker、rich text、product、collection、URL 或 metaobject reference。名稱應用營運語言描述用途，例如「行動版主圖」，不要用程式變數名稱。help text 只解釋容易誤用的規則，避免每個欄位都塞一段教學。
提供合理預設值和 preset，讓新增 section 時能看見基本結構。必須成對的欄位要處理缺一個的狀態；文字長度若影響版面，可在說明和設計規範中給範圍，不要直接截斷顧客資訊。
自由度要有護欄
顏色、字級、間距和圓角應優先來自 Theme settings 與 design tokens。若每個 section 都能輸入任意色碼和像素，頁面很快會出現不一致組合。可提供少量語意化選項，例如「一般、強調、深色」，並讓每個選項有完整的對比和狀態規則。
Blocks 可設定最大數量，避免內容無限制堆疊。會影響效能的影片、輪播或大型圖片，也應限制使用方式並提供替代呈現。
動態資料和人工內容分開
商品規格、價格與庫存應讀取 Shopify 資料；行銷主張和素材由 section settings 管理。若一段資料會被多個商品或頁面引用，可用 metafield 或 metaobject，避免每次複製。內容來源清楚，日後才能知道該在哪裡修正。
Dynamic source 連接後仍要處理空值。某商品沒有尺寸資訊時，section 應隱藏、顯示替代內容，或提示編輯者補資料，不能在正式頁留下空框。
編輯器與前台一起驗收
測試新增、刪除、排序、複製 template、block 選取和 preview。再用短文字、長文字、缺圖、直式與橫式圖片、多個 blocks 和零 blocks 檢查前台。行動版的內容順序與觸控也要獨立確認。
設定變更也需要版本觀念
Template JSON 和 Theme settings 會隨營運調整，不能只把 Liquid 視為程式來源。重大活動前備份 Theme，記錄哪個 template 被修改、由誰核准，以及回復時會失去哪些新內容。若 Git 流程會同步 JSON，必須避免開發環境的舊設定覆蓋 production。
Section schema 更新時也要考慮既有頁面。更改 setting id、block type 或預設值，可能讓已發布內容消失。先在 Theme 副本載入 production template，準備資料遷移與回歸案例，再發布新版。
用模組使用率決定後續整理
每季查看哪些 sections 被大量使用、哪些從未使用，以及哪些頁面反覆出現例外客製。常用模組應加強文件與測試；用途重疊的模組可以合併；沒有 owner 又未被引用的模組則安排退場。這比持續增加新版 section 更能控制編輯器複雜度。
最後建立 section catalog，記錄用途、可用 template、資料來源、設定、範例和不適用情境。這份文件能減少重複開發，也讓內容團隊知道何時該用哪個模組。需要進一步統一元件和 token 時，可將 catalog 納入 Shopify 設計系統服務的治理範圍。