香港網頁設計完整指南：由業務目標到網站落地

一、把業務目標寫成可驗收的句子

一條公式解決八成爭議

網站專案最常見的失敗起點，是需求寫成「想要高級感」「要有 wow 感」。這些是視覺方向，不是可驗收條件。把每一項要求改寫成這條公式，問題立刻具體化：

「誰」＋「在什麼情況下」＋「輸入什麼」＋「應看到什麼」＋「之後誰處理」

判斷方法很簡單：如果一項要求寫不出這五格，就代表它還未可以交給設計或開發。這條公式同時適用於首版功能、上線後的內容修改，以及日後的改善建議。

先分清訪客類型，再定首頁

把不同訪客混作同一類人，是首頁變成「訊息倉庫」的根源。專業服務、零售、B2B 貿易的訪客問題完全不同——先列出 2–3 類主要訪客，各寫一句他們來的目的，首頁的排序就自然清楚。

例如一間設計公司的三類訪客：正在比較報價的老闆（要價錢與案例）、已收到報價想核實可信度的採購（要公司背景與客戶名單）、想應徵的設計師（要團隊與職位）。三類人要的東西不同，但首頁只需服務第一類，其餘兩類用清晰導航分流即可。想了解市場上不同公司的運作模式差異，見 外判還是自己團隊做。

二、動工前資料盤點

這一步的產出應該是一張表，而不是一次口頭會議。資料未齊不需要假裝已確認——標明缺口、負責人與截止日，比空白更有用。

圖片沒有規格，等於預約重做

最常見的浪費：設計稿用 16:9 的圖，客戶最後提供 4:5 的直幅照片，全部要重裁。動工前定好三件事——主視覺比例、商品圖比例、人物照的安全裁切範圍——就能避免。同時要問清楚授權：網上找的圖、供應商的圖、舊代理留下的圖，都可能有使用限制。

三、方案選型與驗收焦點

選型不應只看第一版做得靚不靚，而要看日後誰改、改幾多、改得幾難。三條路的分野與對應價位如下。

選型前先預演兩條流程

只寫功能名稱（「要有預約系統」），供應商與客戶會各自想像成不同畫面。務實做法是預演一條正常流程與一條例外流程：

• 正常流程：客人選日期時間 → 填資料 → 收到確認電郵 → 後台出現新預約 → 同事確認
• 例外流程：同一時段被兩人同時預約 / 客人要改期 / 客人未出現 / 需要退款——每一種的狀態、通知對象與手動處理方法都要先寫出來

能把例外流程講清楚的專案，開發時間與爭議都會少一半。各方案的成本結構比較見 香港網頁設計價錢全解析與 $1,800 方案的成本拆解。

四、角色、改稿與決策權

四種角色，可兼任但必須寫明

改稿要有規則，否則意見不會收斂

「幫我改靚啲」這類意見無法執行。建議在合約或工作文件裡定明三條規則：

1. 每次改動要寫三件事：解決哪個任務、影響哪些頁面、是否改動時程
2. 意見合併後才交出：由一位負責人整合公司內部意見，不要五個人分別 WhatsApp 傳來零散要求
3. 改稿次數與範圍寫入合約：例如視覺方向 2 輪、細節調整 3 輪，超出按小時計。這不是為了收錢，而是為了令雙方有共同的停止點

另外一個實務技巧：先驗收線稿（wireframe），再做視覺設計。在線稿階段爭論「價錢表放第幾段」很便宜；等視覺稿做完才改頁面結構，等於重做。

五、資訊架構與網址結構

網址規則一開始就要定

網址一旦被搜尋收錄或被分享，改動就要處理 301 轉址。所以第一版就要定好規則：

• 用意義清晰的英文短字，不用中文編碼或無意義編號（/web-design 而非 /page?id=12）
• 層級不超過三層（/blog/seo/technical-checklist）
• 全部小寫、用連字號分隔，不用底線或空格
• 不要把年份放進固定頁網址（/price-2026 明年就要改）
• 分類與標籤頁要決定是否允許收錄，避免大量低價值頁面

內部連結是架構的一部分，不是事後補

規劃階段就應該畫出「支柱頁 → 支援文章」的關係：每個核心主題一個支柱頁，下面 4–8 篇支援文章，彼此互相連結。這做法同時服務三個目標——訪客找得到、Google 理解主題權威、AI 搜尋容易抽取。實作原理見 GEO 生成式引擎優化入門。

六、技術落地：PHP、MySQL 與可編輯區塊

技術服務流程，不是功能名單

PHP 與 MySQL 適合把內容、表單與訂單資料放進可管理的結構，但欄位設計必須先反映業務語言。如果業務同事說「熟客價」，資料庫就應該有清楚對應的欄位與規則，而不是塞進備註欄。

敏感或例外資料不要藏在備註欄

判斷準則很明確：若某項資料會影響「誰可見」、「何時處理」或「能否提交」，它就必須是獨立欄位加規則，不能只是備註。備註只適合補充說明。行業專有資料越早命名，後期改程式與補資料的代價越低。

失敗情境必須先寫進測試表

以下六種平日不常見，但一出現就令前台與後台說法不一致：

1. 必填欄位未填 → 前台提示是否清楚、是否保留已填內容
2. 重複提交（連按兩次） → 是否產生兩筆紀錄
3. 權限不足 → 顯示什麼、是否記錄嘗試
4. 電郵寄送失敗 → 資料是否仍存入後台、誰會知道
5. 第三方服務超時（付款、地圖、物流） → 用戶看到什麼、狀態如何回復
6. 上載超大檔案或錯誤格式 → 提示與伺服器保護

技術文件至少要記錄四樣：欄位、狀態、通知對象、手動處理方法。伺服器與資料安全層面見 網頁寄存服務；技術範圍對照見 網頁設計服務內容。

七、時間表：標準流程 vs 快線

兩者的分別不是「快就是好」，而是換了什麼：快線用現成版塊換掉線稿與視覺階段，用「一次交齊內容」換掉來回補件的時間。如果你的專案有客製流程或需要品牌獨特視覺，就應該走標準流程。

八、測試與驗收

用真實內容、真實帳戶、真實裝置

空白示例（Lorem ipsum、佔位圖）很少揭示真正問題。測試必須放入：最長的服務名稱、沒有圖片的商品、錯誤的電話格式、重複提交、以及超長的中文標題。四條必跑情境：

1. 一個全新用戶完成主要任務（查詢或下單）
2. 一個已有資料的用戶改動或取消
3. 一個錯誤輸入，確認提示與紀錄正確
4. 由非項目成員按說明書重做一次（這一條最能揭示文件是否足夠）

問題紀錄模板（照抄即可用）

編號：BUG-014
嚴重程度：阻斷 / 影響體驗 / 微調
裝置與瀏覽器：iPhone 14, Safari 17 / Android 13, Chrome
頁面網址：https://example.com/contact
操作步驟：
  1. 開啟聯絡頁
  2. 只填姓名與電話，服務類別留空
  3. 按「提交」
預期結果：顯示「請選擇服務類別」，已填內容保留
實際結果：頁面重新載入，已填內容全部清空
截圖／錄影：附件
發現者與日期：陳小姐 / 2026-09-12

「有時唔得」不能讓開發者定位原因——一定要寫得可重現。驗收會議的次序也要定好：先處理阻斷任務的問題，全部解決後才討論文字與視覺微調，否則兩種嚴重程度混在一起，重要問題會被淹沒。

上線前必查的八項

• 所有表單實測收件（Gmail、Outlook、iCloud 各一次，確認不進垃圾郵件）
• 電話、WhatsApp、地圖連結在手機上可正常開啟
• 手機實機測試主要流程（iOS 與 Android 各一次）
• 全站 HTTPS，無混合內容警告
• 404 頁有搜尋與熱門連結
• 每頁有獨立 title 與 description
• GA4 與 Search Console 已接好並驗證事件
• 每日備份已啟用並測試還原一次

速度相關的驗收項目見 Core Web Vitals 實戰指南；網店另有額外 30 項，見 開網店前必看九項清單。

九、上線與追蹤

改版前必做：舊網址對照表

如果舊站已有被搜尋收錄或被分享的頁面，改版時必須列出三欄：舊網址、對應新頁、是否需要 301 轉址。沒有去向的連結會令訪客走到 404，也會令過往累積的排名與外部連結失效。

完整做法見 網站改版不跌排名：301 轉址實務。

追蹤只量度可回答的問題

不要把一長串數字當成果。上線時先約定三至五個要改善的動作，再設對應事件：

• 表單是否成功送出（generate_lead 或 form_submit）
• 哪類服務頁帶來查詢（以頁面路徑分組）
• WhatsApp 與電話按鈕的點擊次數
• 哪些內容促成下一步（訪客路徑報告）
• 手機與電腦的轉換率差距（若差距大，先修手機版）

上線後第一輪檢查應排在 7–14 日內——這時內容與技術都仍可快速調整。推廣與內容的持續經營見 網上推廣服務。

十、移交與維護

移交不只是交出登入帳戶

可用的移交文件要答四條問題：誰可以改什麼、改動後怎樣檢查、遇到例外找誰、緊急情況怎樣處理。移交清單建議包含：

• 域名、寄存、資料庫、GA4、Search Console 的帳戶與擁有權（要在客戶名下）
• 原始檔與資料庫備份（實際交付一次，不是口頭承諾）
• 後台操作說明（建議錄一段 15–20 分鐘螢幕錄影，比文件實用）
• 權限矩陣：誰是管理員、誰只能改內容、誰可以發佈
• 維護安排：備份頻率、更新責任、支援時間與回應承諾
• 首版未做功能的紀錄：原因、優先次序、需要補的資料

下一階段要留在已知邊界內

首版未做的功能不應用一句「日後再加」帶過。寫下原因與所需資料，下一輪啟動時就能從紀錄判斷，而不是重新猜測。新需求出現時，先問一條問題：它是否改變了主要任務？如果是，開新的變更工作並重新評估時程；如果不是，排入下一輪更新。

行業差異會改變什麼

行業差異改的是欄位與流程，不只是換圖片。

電商相關的流程邊界見 電商平台服務；需要配合手機應用的情況見 Apps 製作；社交渠道與網站的分工見 社交平台推廣。

五個常見誤解

名詞速查

需求文件（Brief／Spec）

雙方確認的書面範圍，包含頁面、欄位、流程與驗收條件。

資訊架構（IA）

網站的內容分類與層級關係，通常以網站地圖表達。

線稿（Wireframe）

只有結構與內容位置、沒有顏色與圖片的版面草圖。

設計系統

可重用的元件與規則（字級、間距、顏色、按鈕狀態）。

測試環境（Staging）

與正式站分開的環境，用於測試與驗收。

驗收（UAT）

由使用方按真實情境操作並確認符合需求。

301 轉址

永久轉址，把舊網址的流量與搜尋權重導向新網址。

權限矩陣

列明每個角色可以看到與改動什麼的對照表。

支柱頁（Pillar page）

一個主題的總覽頁，連結該主題下的所有支援文章。

變更工作（Change request）

超出原定範圍的新需求，需獨立評估時程與費用。

常見問題

動工前要預備什麼？

七樣：服務清單、最終版文字、合規格圖片、常見問題紀錄、現有查詢數據、帳戶權限、決策人名單。無法一次備齊也不要緊，但要標明每份資料的負責人與交付日，並先確認首版必需內容與不能延後的帳戶權限。

整個專案要幾久？

市場標準是 6–14 週（10–30 頁網站）：發現 1–2 週、架構 1 週、線稿 1–2 週、視覺 2–3 週、開發 3–6 週、測試 1–2 週、上線 3–5 日。用標準化版塊加一次性交齊內容，最快可壓到 3 個工作日。

範圍應該何時確認？

在架構與設計開始之前，並用頁面、欄位、流程與驗收條件四種形式表達。確認後若有新增任務，應記錄它影響哪些內容、測試與上線安排，而不是直接插進已排好的工作。

內容未齊可以開始嗎？

可以先做資料盤點、導航與首版流程，但不要假裝空白位置日後自然會補好。缺口要保留真實長度與標記，並指定最後交稿時間——否則手機版排版與測試結果都會失真。

怎樣安排驗收才有效？

由一位不參與製作的人按真實步驟操作，記錄裝置、輸入、預期結果與實際結果。先處理阻斷任務的問題，再討論文字或視覺微調，避免不同嚴重程度混在一起討論。

改稿次數應該怎樣定？

建議分兩層：視覺方向 2 輪、細節調整 3 輪，超出按小時計。更重要的是規定「意見要合併後才交出」與「每次改動要寫明解決哪個任務」，否則零散意見會無限循環。

日後誰可以更新內容？

按角色分配：內容人員改文字與圖片，決策人核對發佈，技術人員處理欄位與流程改動。每次更新後應有一個簡短檢查步驟，確認前台顯示與後台資料一致。

出現例外流程怎樣處理？

每個例外都要有明確狀態、負責角色與手動處理方法——資料不全、重複提交、需要覆核、第三方服務失敗。不能只在備註寫「跟進」，否則不同同事會用不同方式處理，紀錄也無法重現。

應該選平台還是自建？

看內容是否常改、流程有沒有例外、日後誰維護。流程標準、預算有限，標準化方案或現成平台最快；例外規則多、要與內部系統對接，自建的可控性與長期成本較好。決定前先預演一條正常流程與一條例外流程。

網站上線後多久要檢查一次？

第一輪 7–14 日內（趁內容與技術仍可快速調整），之後每季覆核一次核心頁面的數據與內容時效。有真實訪客數據之後的調整，比上線前的猜測有效得多。

移交要拿到什麼才算完整？

六樣：域名與寄存帳戶（在你名下）、原始檔與資料庫備份、後台操作說明、權限矩陣、維護安排、以及首版未做功能的紀錄。只交出一個後台登入不算移交。

怎樣開始與團隊溝通？

開始前帶齊四樣東西：業務目標、現有資料、需要解決的問題、以及可以拍板的人。有這四樣，第一次會議就能產出可執行的需求文件，而不是又一次「我們再想想」。

延伸閱讀

• 香港網頁設計價錢全解析：市場價目表與報價陷阱
• 做網站只需 $1,800？零外判 + AI 提速的成本拆解
• 外判還是自己團隊做？網頁公司運作模式拆解
• 網站需求文件模板：可直接填寫的 12 個欄位
• 開網店前必看：香港電商九項準備清單
• Core Web Vitals 實戰：手機快兩秒的十個做法
• GEO 生成式引擎優化入門：讓 AI 引用你的網站
• 中小企技術 SEO 檢查清單：上線前必做的 18 項
• 網站改版不跌排名：301 轉址與網址對照表實務
• WordPress 還是自建 CMS？長期維護成本比較