客製化網站怎麼規劃？把功能需求寫成可驗收規格

客製化網站不是把模板換成獨家配色，也不是功能越多越好。真正需要客製的情況，通常是網站必須依企業自己的規則處理資料與流程，例如不同角色看到不同內容、表單會進入審核、產品組合影響金額，或需要和付款、預約、會員及內部系統串接。若需求只寫「做一套客製官網」，設計、開發與委託方很容易各自想像不同成果。

以下先聚焦客製功能的需求規格與驗收。公司資訊怎麼分層可看 企業網站規劃指南；品牌故事、作品與視覺接觸點屬於 品牌網站設計；挑選供應商與合約評估另見 網頁設計公司選擇指南；費用組成則由 網站設計費用指南說明。

封面取自法西納的有紀莊園案例 ，可觀察商品、價格與售完標示如何排列。這是網頁視覺呈現，庫存判斷、資料串接與後台規則仍需另訂規格；畫面金額與商品狀態不代表現行銷售資訊。下文的 SJS 網頁作品則用來觀察內容與行動入口的安排。

一、先記住四個判斷

二、什麼時候才值得做客製化網站？

先列出網站的必要任務，再判斷現成系統是否真的無法支援。一般公司介紹、文章、作品與聯絡表單，常可由成熟內容管理系統完成；若差異只在字體、色彩、版面和內容順序，重點是客製視覺與內容，不一定需要自行開發功能。

當業務規則無法合理套入現成功能，客製才有明確價值。常見訊號包括多階段申請、依條件顯示欄位、分店與總部權限、複合商品試算、會員專屬資料、跨系統同步，或同一筆資料會經歷草稿、送審、退回、核准與封存。判斷依據不是競品有沒有，而是少了這項能力，主要任務是否無法完成。

三、需求不要寫功能名稱，要寫一條可走完的任務

「需要會員、預約和後台」仍不是規格。以預約為例，要先回答誰能預約、可選哪些時段、何時鎖定名額、取消後是否釋出、逾時怎麼處理、誰會收到通知，以及管理者能否代為修改。每個答案都會改變頁面、資料欄位、程式邏輯與測試範圍。

可以用同一個句型撰寫：在某項前置條件成立時，某角色執行一個動作，系統保存什麼資料、回傳什麼狀態；若條件不成立，使用者會看到什麼提示，資料是否保留。先把最常發生的一條主流程走通，再補失敗、取消、重複與逾時。

已填規格：訪客預約一個時段

假設訪客不必登入，必填聯絡人、手機與時段；送出前已閱讀個資告知。系統在送出時重新確認名額，成功才保存一筆預約並提供確認編號。若已額滿，保留已填聯絡資料，提示改選時段；若網路重送同一請求，使用同一送出識別回傳原結果，不再新增名額占用。

驗收可讓兩個瀏覽器同時搶最後一個名額，確認最多只有一筆成功；再重送成功請求，核對預約筆數、剩餘名額與通知紀錄。這些是本示例選定的規則，實際專案仍要先決定名額鎖定、取消釋出與通知重試方式。

四、先畫資料與狀態，再畫漂亮頁面

客製功能的核心通常是資料關係。產品是否有規格與庫存、文章能否屬於多個分類、同一會員是否能管理多間門市，都要先形成一致資料模型。欄位命名、必填條件、排序方式與歷史紀錄也應在設計前確認，否則畫面完成後才發現資料裝不下，會連帶重做介面和後台。

狀態要使用清楚且互斥的名稱。以申請流程來說，「處理中」不足以區分待補件、待審核與已排程；若管理者與申請人看到的用語不同，也要建立對照。畫一張狀態轉換表，註明可執行角色、觸發通知及能否返回上一階段，會比在會議中說「後台可以改」更可靠。

五、法西納案例：SJS 把商品選擇轉成網站內容

法西納為 SJS 完成禮盒與網頁設計 。作品資料記錄以四季花語發展禮盒視覺；網頁設計畫面則可直接看到「試吃預約」的內容編排，包含選擇、服務說明與行動入口。這類頁面要進入製作時，不能只確認排版，還要把選項來源、送出欄位、確認方式與無法受理的情況寫進需求。

這組畫面適合觀察商業規則如何被整理成讀者看得懂的內容；實際的技術架構、後台與串接方式仍須依專案另行規劃，畫面中的日期、金額與活動條件也應以品牌現行方案為準。

六、把商業規則拆成可計算、可追溯的條件

金額、資格、名額與日期若會彼此影響，應整理為規則表，而不是只放在說明文案。每條規則要有輸入值、優先順序、計算結果、四捨五入方式、生效區間與修改人。若優惠不能併用，也要指定衝突時採哪一條；若管理者可人工覆寫，應保留原因與操作者紀錄。

畫面顯示與後端判斷必須使用同一套規則。不能只靠前端隱藏按鈕，也不能讓通知信的結果和管理畫面不同。涉及購物或產品頁時，可再用 電商頁面視覺系統指南 整理頁面資訊與狀態；交易流程與例外情境則可參考 電商流程設計指南 ，但仍要依實際系統能力確認。

七、第三方串接要先分清楚誰負責、失敗怎麼辦

付款、簡訊、地圖、電子報、登入與企業內部系統，都可能有申請資格、費率、額度、審核、測試環境與停機限制。需求文件要記錄帳號由誰持有、金鑰放在哪裡、測試資料怎麼取得、正式切換由誰執行，以及服務中斷時網站顯示什麼。第三方說「串得上」不等於整條任務已完成。

每個串接至少測成功、拒絕、逾時、重送與回傳資料缺漏。若使用者已付款但回傳延遲，網站不能直接建立第二筆訂單；若通知寄送失敗，也不應把主要資料一起刪除。重試次數、人工處理入口與對帳紀錄都應在開發前說明。

八、表單蒐集資料時，告知文字也是功能規格

聯絡、預約與會員表單會碰到個人資料。全國法規資料庫的 個人資料保護法第 8 條 列出直接向當事人蒐集時應明確告知的事項，包括機關或單位名稱、蒐集目的、資料類別、利用期間與方式、當事人權利，以及不提供資料的影響。專案應由企業依實際流程確認告知內容與法源；設計與開發驗收只負責已核准文字、連結、勾選及紀錄是否正確呈現，不能代替法律判斷。

九、手機版不是縮小稿，要用任務驗收重排

客製流程常有長表單、步驟列、篩選器或資料表，桌機並排後直接縮小，容易造成橫向捲動、按鈕被遮住或錯誤訊息離欄位太遠。W3C 的WCAG 2.2「Reflow」成功準則要求一般內容在相當於 320 CSS 像素寬時，不因雙向捲動而失去資訊或功能；需要二維配置的資料表等內容有例外，但例外不應擴張到整個頁面。

驗收時不要只看固定尺寸截圖。要實際放大文字、開啟鍵盤、輸入很長的姓名或地址、顯示欄位錯誤，並走完登入、送出與返回。若手機版改成分步流程，也要確認重新整理、返回上一步與逾時後，使用者不會無故遺失已輸入內容。

十、安全要求要變成測試清單，不是寫一句「有 SSL」

登入、會員資料與管理後台需要明確的權限、紀錄與復原方式。 OWASP Application Security Verification Standard 提供可用於開發、測試與採購的網站應用程式安全驗證基礎。專案可依風險挑選適用要求，寫入帳號、存取控制、輸入處理、錯誤紀錄與資料保護的驗收範圍；是否達到特定等級，應由具相應能力的人員驗證，不應只由畫面或口頭承諾判定。

十一、法西納案例：試算畫面要能回到計算規則

SJS 的另一張網站設計稿整理不同禮盒款式、內容組合、價格區間與試算步驟。這張可見畫面適合說明複合條件如何讓讀者理解；若要轉為可操作功能，仍要指定選項來源、數量限制、折扣先後、金額精度與失效條件。設計稿把算式說清楚，不代表後端規則已自動成立。

把一個數量變更，算到訂單摘要

上方原稿保留完整的商品組合與試算編排；下圖另外用一組教學數字，放大「數量變更後，折扣與總額一起更新」的規則。假設每盒 480 元、滿 12 盒商品小計打 95 折，再加固定運費 120 元：11 盒為 5,400 元，12 盒為 5,592 元。這不是 SJS 的售價或系統畫面，而是可交給設計與工程共同驗收的已填情境。

十二、用可重現情境驗收，不用「感覺差不多」

每項功能至少準備正常、邊界與失敗三類測試。正常情境確認主要任務能完成；邊界情境放入最大長度、零筆結果、額滿、重複名稱或跨日資料；失敗情境則模擬斷線、第三方拒絕、權限不足與通知未送達。測試單要寫前置資料、操作步驟、預期結果、實際結果、裝置與日期，修正後再由同一情境複測。

• 訪客看不到管理功能，低權限帳號不能直接開網址讀取他人資料。
• 重複點擊、返回或重新整理，不會建立重複交易與通知。
• 欄位錯誤能指出位置與修正方式，已填資料不會無故清空。
• 第三方逾時後有可追查狀態、重試規則與人工處理窗口。
• 桌機與手機都能走完主要任務，鍵盤焦點與提示不被遮住。
• 管理者修改資料有必要的時間、操作者與原因紀錄。

十三、交付不只原始碼，還要讓下一位能接手

上線前要列出網址與網域、主機、程式碼儲存庫、部署平台、資料庫、第三方服務、分析工具及寄信服務的最高權限持有人。帳號宜由企業持有，再授權合作團隊；金鑰不要只存在個人電腦或聊天訊息。交付文件應含環境設定、部署步驟、備份與還原、定期工作、已知限制及緊急聯絡方式。

同時區分保固、維護與新增需求。原規格無法運作屬缺陷；套件更新、第三方改版與例行監控屬維護；新增角色、欄位與流程則要重新估算。若舊站改版，還要先盤點資料搬移、網址、寄信與表單紀錄，並約定上線失敗時的回復條件。能回復，才算有完整上線計畫。

十四、客製化網站常見問題

十五、帶著一條真實任務開始規劃

客製化網站的專業度，體現在需求能否被不同角色一致理解、功能能否被重現測試，以及發生例外時能否恢復。先挑一條最重要的任務，整理角色、資料、狀態、規則與第三方依賴，再決定哪些部分需要客製，會比先列一串功能名稱更接近可交付成果。

若已經有主要任務、現行作法、必要欄位與預計上線時間，可以查看法西納的設計服務，或透過 聯絡表單 提供需求。第一次討論先確認範圍、限制和驗收方式，再評估適合用既有系統、客製介面或獨立功能完成。