網頁設計流程全指南：香港中小企由需求整理到上線驗收

網頁設計流程第一步：先回答網站要替公司完成甚麼

「我想整個公司網站，應該先準備甚麼？」網頁設計流程應由業務目標、客戶需要及資料責任開始，再安排頁面架構、設計、開發、測試和上線。老闆最先要決定的，是訪客看完網站後應做哪一件事，以及公司有沒有能力接住這個行動。

如果希望收到工程查詢，網站就要讓人知道承接哪些工程、服務範圍及查詢時需要提供甚麼；如果希望客戶自行落單，則要先整理商品、付款、存貨及送貨規則。兩者都可以有漂亮首頁，但背後的資料和操作完全不同。未分清目標便討論動畫或版面，容易做到後段才發現功能不合用。

試寫一句可以交給同事理解的目標，例如「讓首次接觸公司的採購人員看懂產品類別，並提交包含型號及數量的查詢」。這句話同時交代讀者、資料和行動，比「提升公司形象」更容易落實。形象仍然重要，但要透過清楚的內容、穩定的操作和一致的視覺呈現，不能只靠形容詞驗收。

把成功條件寫成可觀察的結果

先選一項主要任務，再列輔助任務。主要任務可以是提交查詢；輔助任務可以是下載產品資料或了解服務程序。不同任務需要不同頁面，不宜在每個位置同時要求訪客致電、填表、下載和購買。按鈕很多未必有幫助，反而令讀者不知道下一步。

目標亦要配合內部接手能力。假設公司只在辦公時間處理查詢，表格確認訊息便應說明已收到資料及後續安排，不要自動承諾即時回覆。若需要先審核附件才可報價，頁面應解釋附件用途和可接受格式。這些文字看似細節，卻決定網站承諾與實際工作是否一致。

• 主要訪客是首次接觸公司的客戶，還是已有帳戶的合作商戶？
• 他們進站前最想確認甚麼，哪項資料會影響下一步？
• 網站收到的行動由誰處理，有沒有清楚的接手程序？
• 哪些成果可以透過操作測試驗收，哪些需要上線後持續觀察？

把網站需求文件寫到可以討論，也可以驗收

網站需求文件不必是一份厚重的技術報告，但至少要交代功能、資料來源、使用者和限制。只寫「有查詢表格」仍然太粗略：誰可填寫、哪些欄位必填、附件如何處理、成功提交後顯示甚麼，以及通知失敗時如何追查，都會影響製作範圍。

用實際任務描述功能

假設一間新蒲崗的小型貿易公司，希望採購人員查詢多個產品。與其要求「加個專業產品頁」，不如寫成「訪客可把多個型號放入查詢清單，填寫數量後一併提交」。接著確認型號從哪裏取得、是否有停產商品，以及清單是否需要保留。這是需求例子，不代表任何真實客戶項目。

整理資料時，可以把公司網站設計範圍與內部工作流程放在一起核對。設計團隊需要知道的是訪客要完成甚麼，以及公司如何接收結果，才能判斷使用一般內容頁、表格，還是需要額外程式。先把業務說清楚，比預先指定一堆未必需要的功能更有效。

分開必須、可延後及尚未決定的項目

第一版不一定要把所有想法做完。可以用「沒有便無法營運」「有了會方便」「仍需驗證」三組分類，但每個延後項目都要說明後果。例如優惠碼可以延後，付款確認卻不能含糊；新聞分類可以簡化，客戶是否能提交有效查詢則直接影響網站用途。

尚未決定的事項要有負責人及確認條件。若公司仍未決定是否公開產品價格，產品頁、查詢方式和後台欄位都可能受影響。把問題放進待決清單，約定由誰在甚麼階段確認，能避免設計師、程式員和老闆各自使用不同假設。

還可以替每項需求加上「不包括甚麼」。例如查詢清單只把型號交給營業同事跟進，不包括即時報價或自動扣減存貨；下載產品目錄不包括限制下載次數。這種界線不是為了減少功能，而是讓大家知道第一版的實際行為，日後新增工作也有清楚起點。

如果不同部門對同一欄位有不同理解，應在文件中保留定義。營業同事說的客戶編號，可能與會計系統的帳戶編號不同；畫面上都寫「編號」，程式整合時卻會出現配對問題。先用少量假設資料走一次流程，確認每個欄位從哪裏來、由誰改及交往哪裏。

內容先行：先有可以閱讀的資料，才知道需要多少頁

網站頁數應由內容任務決定，而不是先訂一個數字再硬塞資料。兩項服務若對象、程序及查詢需要不同，通常值得分頁說明；若只是同一服務的不同叫法，可以在同頁自然交代。把所有內容放首頁，訪客難以細讀；每個小問題都拆成一頁，又可能造成內容零碎。

建立一份內容盤點表

每個預定頁面記錄主要問題、已有資料、欠缺資料及確認人。產品相片要知道使用權和型號對應；服務內容要由熟悉實際工作的同事核實；聯絡資料則需確認地址、電話及電郵是否仍在使用。不要把資料夾內的檔案直接當作已批准的網站內容。

公司簡介也應有用途。讀者需要理解公司做甚麼、適合處理哪些需求，以及如何開始合作。沒有來源的規模、排名或成效不應加進去。若有資格、認證或案例資料，應先確認可公開範圍及證據；若沒有，就以清楚的服務說明和工作安排建立理解，毋須借用別人的故事。

相片命名最好與產品或服務資料一致，保留原檔和可公開版本。尺寸太細的圖片不能靠放大補回細節，只有社交平台截圖亦未必適合網站。應提前交代所需畫面及比例，讓公司安排拍攝或選圖，而不是版面完成後才發現全部圖片都不合用。

1. 列出每頁要回答的一個主要問題。
2. 把現有文字、圖片和文件對應到頁面。
3. 標示未確認的內容及所需補充資料。
4. 指定業務確認人，集中回覆內容問題。
5. 用接近正式的資料檢查版面，不以佔位文字代替驗證。

網站架構要配合人找資料的方式

選單名稱最好讓首次接觸公司的讀者看得懂。公司內部部門名稱不一定是客戶搜尋或理解服務的方式。假設一項服務跨越兩個部門，也不用因此拆成兩個難以辨認的頁面；前台可按客戶任務組織，內部再分派處理。

可以請一位沒有參與製作的同事，只看文字版選單尋找指定資料。若他要猜幾次才找到，問題往往在名稱或分組，而非顏色。這類小測試成本不高，卻能在設計尚未固定前揭露架構問題。測試時記錄他實際選了甚麼，不要先教他正確路線。

內容亦需要狀態管理。未批准、已批准和已上載的檔案最好分開標示，否則同事可能把舊版本重新寄給製作團隊。尤其電話、商品規格及服務限制，一個字的差異也可能改變意思。每次確認保留日期及版本名稱，比在多個聊天群組翻找最後一句回覆可靠。

若某頁依賴尚未取得的資料，可以先決定替代安排。沒有合適工程相片時，是否暫用文字交代服務範圍；某項服務仍未確定推出時，是否先不公開。不要因為版面預留了位置，就把沒有核實的內容填進去。留待資料齊備後發佈，往往比之後逐頁更正更容易控制。

由線框到視覺稿：每一輪應確認不同事情

線框是用簡單區塊表示內容先後和操作位置，重點在資訊是否完整、順序是否合理。視覺稿才進一步處理字體、色彩、間距和圖片風格。兩個階段若混在一起，團隊可能花很多時間調整按鈕顏色，卻沒有發現主要查詢資料被放得太後。

先驗證路線，再選外觀

逐頁問三件事：訪客怎樣來到這頁、在這裏需要知道甚麼、看完之後去哪裏。產品頁可以從分類進入，也可能直接由搜尋結果進入，因此不能假設每位訪客都先看過首頁。頁面本身要有足夠背景，並提供合適的下一步。

視覺回饋應描述問題和原因。例如「手機上兩個按鈕太接近，容易選錯」比「感覺不夠高級」更可處理。若確實涉及品牌喜好，可以提供參考方向及不希望出現的元素，但不要要求照抄其他網站的文字、圖片或整個版面。參考應用來說明偏好，不是代替設計判斷。

不同畫面要一併考慮。桌面橫排的規格表到了手機可能需要重新安排；長中文標題和英文產品名稱的換行也不一樣。至少應使用真實長度的內容檢查手機及桌面主要頁面，避免只批准一張內容很短、畫面很寬的展示稿。

亦要看沒有資料或操作失敗時的畫面。搜尋沒有結果，應提供重新搜尋或返回分類的方向；清單尚未加入產品，應解釋下一步；提交失敗時則要避免顯示成功訊息。這些狀態未必出現在漂亮的首頁示範稿，卻是訪客實際會遇到的操作部分。

開發前確認資料怎樣流動，避免畫面完成但工作接不上

前台畫面只呈現操作的一部分。提交表格後資料存在哪裏、誰可查看、如何匯出及通知到哪個地址，都要在開發前確認。若依賴另一個系統提供資料，也要查明接口、權限及測試方法是否已具備，不能只憑「應該可以接駁」便排好上線日。

內容管理與交易功能分開考慮

內容管理系統要方便指定人員更新，但不是每位同事都需要所有權限。負責新聞的人未必應修改付款設定；外判內容人員也未必需要下載查詢資料。把帳戶權限按工作分配，可以減少誤改，交接時亦較容易知道誰負責哪一部分。

若網站涉及購物車和收款，應把網上商店開發需要列成獨立工作範圍，確認訂單、付款和存貨狀態之間的關係。客戶看見付款完成，不代表每個後台步驟都已成功；系統需要處理通知延遲、重複提交及取消等情況，並保留可追查紀錄。

表格欄位亦有取捨。每多收集一項資料，公司就多一項保管和使用責任。只要求處理查詢所需的內容，並交代用途及接收安排；涉及個人資料的具體聲明，應由合適人員按實際做法核對。複製別人的私隱文字，不能代替盤點自己的資料流程。

把外部依賴列入時間表

域名帳戶、付款審批、圖片授權及第三方接口，都可能由不同人掌握。應列明誰提供、何時需要，以及未取得時哪些工作無法進行。開發團隊可以先做部分畫面，但不代表正式交易或通知已可測試。以可取得的前置條件排程，比只用完成百分比回報更實際。

假設商戶仍未獲得付款系統的正式帳戶，測試環境完成只能證明一部分流程可運作。上線前仍要按供應商規則檢查正式設定及交易紀錄。這類依賴應提前列出，不要到最後才把整個等待時間當成網站製作延誤。

時間、預算與修改：用確認節點管理變動

排程應包含公司內部整理資料、審稿和測試的時間。只計設計及程式工作，而假設所有回覆都即日完成，通常無法反映真實安排。每個節點最好有明確輸入和輸出：內容確認後交設計，設計確認後進入開發，功能可操作後才進入完整驗收。

修改本身不是問題，沒有區分修改性質才容易爭議。修正原定功能的錯誤、調整已批准設計，以及新增原先沒有的功能，是三種不同工作。收到改動要求時，先確認對內容、程式、測試和日期的影響，再決定是否放入本次上線。

回饋最好由一名指定窗口整合，但不代表其他同事不能參與。業務、營運和管理層可以各自提出問題，再由窗口處理相互矛盾的意見。若同一頁上午要求簡化，下午另一人要求增加大量內容，團隊需要知道哪個方向才是公司最後決定。

預算討論亦應以工作範圍為基礎。多語言、資料整理、特殊整合及後續維護各有不同工作量，不應只用頁數判斷。可以先確認哪些內容由公司提供、哪些由服務團隊協助，以及後續修改如何處理；沒有足夠資料時，不宜把粗略估算當成固定承諾。

搜尋與推廣準備，要在上線前放進工作清單

網站內容需要清楚的頁面標題、摘要和層級，讓讀者知道每頁用途。網址一經使用，日後修改便要考慮舊連結如何處理。若公司已有網站，應先保存現有網址及重要內容，再確認哪些沿用、哪些合併，以及哪些需要轉址，不能只看新版畫面是否完成。

若計劃配合網上廣告推廣安排，應提早確認廣告落到哪一頁，以及頁面承諾是否與實際服務一致。廣告寫某項服務，進站後卻只看見籠統首頁，讀者仍要重新找資料。查詢追蹤亦要分清按下按鈕和成功提交，不能把所有點擊都當成新客戶。

流動裝置上的主要內容不應為了畫面簡潔而隨意刪掉。可以重新排序或使用清楚標題，但服務限制、聯絡方式及重要說明仍須容易找到。效能檢查則要用真實頁面和內容測試，不能只看沒有圖片或資料的空白示範頁。

• 核對每頁標題、摘要及主要標題是否對應內容。
• 檢查正式頁面沒有誤留測試用的禁止索引設定。
• 確認舊網址有合適去向，未存在頁面沒有被當成有效內容。
• 測試主要查詢動作及其紀錄方式，排除測試提交。

驗收與上線：把「睇落無問題」變成完整操作證據

驗收不是只逐頁睇畫面，而是按真實任務從頭做到尾。測試表格時，應包含有效輸入、漏填必填欄位、格式不符、附件不合規及重複提交。出現錯誤時，要看提示是否清楚、資料是否保留，以及同事能否找到相應紀錄。

問題紀錄應寫清頁面、裝置、操作步驟、預期結果及實際結果。只傳一句「網站有問題」，處理人未必能重現；相反，提供具體條件可以較快判斷是內容錯誤、程式問題，還是不同裝置的顯示差異。修正後應重做原本失敗的步驟，不能只確認檔案已更新。

測試環境與正式環境的差異也要列出。兩者可能使用不同的寄信帳戶、付款設定、資料庫及域名。測試通過之後，仍要由有權限的人核對正式設定，並移除測試帳戶或不應公開的資料。正式網站不應展示測試客戶姓名、假訂單或內部註解。

簽收時可以把未完成事項分成阻礙主要任務與可後續處理兩類，但分類要由雙方確認。無法提交查詢與一處次要文字間距不同，對營運的影響並不一樣。若決定帶着某些已知問題上線，應留下負責人、處理安排及可接受條件，不應把問題從紀錄中刪掉。

最後安排一次由公司同事主導的操作交接。讓他親自登入、修改資料、預覽及發佈，再示範如何找回剛提交的查詢。若只由技術人員展示一遍，公司未必已具備日常操作能力。交接文件應放在指定位置，並確認管理帳戶的復原方法掌握在公司手上。

正式切換前，要確認域名、憑證和網站寄存及運行環境的安排，並知道出現問題時由誰接手。網站和電郵可能共用同一域名的不同記錄，修改網站設定時不應順手刪去其他服務資料。先保存設定及備份，再按已核對的範圍修改。

上線日應有人可以批准切換、驗證主要功能，以及在必要時執行回復。回復不是一句「有問題就還原」：要知道還原哪一個版本、資料如何處理，以及切換後新增的查詢或訂單怎樣保留。涉及交易時，這些安排尤其需要在切換前說清楚。

常見問題

未寫好全部文字，可以先開始設計嗎？

可以先討論目標及架構，但核心頁面應有接近正式長度的內容，才容易判斷版面是否適合。若一直使用短句或佔位文字，正式加入產品規格、限制和多語言內容後，可能需要重新安排。先完成主要頁面，再分批補齊其他內容，通常較容易管理。

公司只有少量服務，是否一頁網站就足夠？

要看服務差異及客戶需要。一頁可以適合任務集中、資料不多的情況；若各項服務有不同對象、流程或查詢資料，分頁會較清楚。先列出讀者問題和內容，再決定結構，不應把一頁或多頁當成固定的好壞標準。

批准了設計稿，是否代表網站已完成？

設計稿主要確認視覺與內容安排，仍未證明表格、後台、權限和外部整合可正常運作。之後需要開發及操作測試。簽收文件應分清設計確認、功能驗收和正式上線，不要用同一個「完成」涵蓋不同階段。

網站做好後，是否自然會有查詢？

網站提供接收查詢的基礎，但結果亦受需求、內容、搜尋曝光、推廣及公司處理能力影響。上線前應把可查閱的資料和主要行動做好，上線後再觀察訪客來源與有效查詢。不能把完成製作等同保證排名或保證客戶數量。

為甚麼上線後仍需要維護？

公司資料會改變，執行環境及外部服務也可能更新。帳戶、備份、憑證、功能相容性和內容都需要有人負責。維護範圍要事先說明，分清例行檢查、故障處理及新增功能，避免以為交付後任何變動都屬同一項工作。

開始前，先帶齊一份可以討論的清單

公司可以先準備主要訪客、網站任務、現有資料、已知限制和負責人五項內容。即使部分答案仍未確定，只要清楚標示，討論便能集中在需要作出的決定。不要等所有技術名詞都弄懂才開始，也不要把所有判斷完全交給製作團隊。

• 一項主要業務目標，以及希望訪客完成的動作。
• 已有內容與欠缺內容，連同可確認資料的人。
• 必要功能、可延後功能及外部系統依賴。
• 希望的上線安排、內部審稿能力及交接需要。

Black Media 提供網頁設計、程式編寫、網上商店及相關寄存服務。若你已整理以上資料，可以透過提交網站需求清單開始討論，先釐清哪些工作需要製作、哪些資料需要公司補充，再安排下一個確認節點。