香港企業網站需求書:8 項資料與上線驗收清單
直接答案:委託香港企業網站設計前,先準備網站目標、目標客戶、頁面清單、文字與圖片、功能、品牌素材、預算和上線時間。報價應列明誰提供內容、手機版、修改次數、網域與後台歸屬,以及上線後支援。交付時按同一份清單在桌面和手機實測。
網站需求書不必寫成技術規格書。它的作用,是讓你和設計公司在同一份文件上回答「網站要幫誰完成甚麼事」,並把未確定的地方列出來。若只說「做一個像某網站那樣的網站」,不同公司會假設不同的頁數、功能與內容工作,得到的報價自然無法比較。下面八部分可直接作為首次溝通和最後驗收的共同底稿。
從實際畫面看網站需求
先看目標
活動影像引入後,訪客要能找到服務、案例與查詢方式;設計需要為下一步服務。
再看手機
同一批重要資訊要在手機保持可讀,並以適合單欄的次序顯示。
最後驗收
用真實文字、相片及連結逐項核對,不能只看一張漂亮的情境圖。
一、網站要讓訪客完成甚麼?
先選一個最重要的行動:提交查詢、預約、致電、報名、瀏覽產品,還是下載資料。首頁可以承載多項資訊,但主要行動不宜同時有五個同樣顯眼的按鈕。你可以寫一句話:「我們希望第一次來訪的香港中小企負責人,在看完服務及案例後,填寫網站查詢。」這句話比「設計要高級」更能指導資訊排序。若網站要服務兩類客戶,請分別寫出他們的問題和路徑;不要假設兩者都會從首頁讀到頁尾。
| 網站目標 | 訪客下一步 | 應核對的頁面 |
|---|---|---|
| 獲得查詢 | 提交表單或主動聯絡 | 服務頁、聯絡入口 |
| 建立信任 | 查看作品與團隊資料 | 案例頁、關於我們 |
| 完成報名 | 選擇活動並確認資料 | 活動頁、報名流程 |
二、訪客最先想知道甚麼?
把「所有人」收窄成一至兩個真正會作決定的群體。企業採購者可能先找規格、交期和供應能力;家長可能先找日期、地點和安全安排。這些問題會決定導航名稱、首頁順序及表單欄位。請提供客戶實際常問的五條問題、成交前要看的證據,以及不能公開的資料。不要把內部產品分類直接當成客戶理解的服務名稱;先用真實查詢驗證字眼。網站可以有英文和中文,但各語言都應有完整、有用的內容,不應只翻譯選單。
- 客戶是誰寫職責或情境,不只寫年齡。
- 客戶想知道甚麼從電郵、WhatsApp、銷售電話整理真問題。
- 客戶信甚麼準備可展示的作品、流程、資歷或服務條件。
三、要做哪些頁面?如何讓訪客找到?
列出首頁、服務、個別產品、案例、關於我們、常見問題及聯絡頁,然後在每頁旁寫「它回答哪個問題」。若兩項服務的規格、對象和報價方式不同,通常值得分開寫清楚;若只是改一個區名、正文幾乎相同,勉強拆成多頁反而增加維護負擔。網站地圖不是越長越好,而是令客戶以最少步驟找到答案。技術上,網站應讓重要頁面透過一般連結到達,並讓 sitemap、正式網址及頁內 canonical 指向同一版本。Google 的 sitemap 指引及 canonical 指引都把這些視為搜尋引擎識別偏好網址的訊號;它們並不保證排名。
四、文字、照片與 Logo 由誰準備?
內容是最常被低估的工序。請逐頁標記「已有定稿文字/需整理現有資料/需要重新撰寫」,並記錄審批人。照片要註明來源、用途及授權,尤其是人物、學校和客戶活動影像。Logo 應提供原始向量檔或可用的高解析版本;不要從社交平台頭像截圖再放大。若有多語言,請列明哪一方提供翻譯、由誰校對專有名詞。圖像的替代文字要描述資訊或功能,而純裝飾圖可留空;可參考 W3C WAI 圖像教學。沒有內容的頁面無法只靠好看的版型變得清楚。
| 頁面 | 文字狀態 | 素材 | 最後確認人 |
|---|---|---|---|
| 首頁 | 服務介紹待精簡 | Logo、主圖已備 | 品牌負責人 |
| 服務頁 | 規格需核實 | 實際項目照片待授權 | 服務主管 |
| 聯絡頁 | 電話及地址待確認 | 地圖和營業時間 | 行政同事 |
五、手機版是否保留同樣重要的答案?
只把桌面畫面縮窄,不等於完成手機體驗。手機上要重新看標題是否易讀、選單能否操作、按鈕是否容易按、表格是否能橫向瀏覽,以及聯絡方法是否在讀者需要時出現。Google 的 mobile-first indexing 指引指出,搜尋系統主要使用網站的手機版本內容;因此手機版不應隱藏桌面版才有的重要說明。驗收時應拿一部真手機逐頁檢查,而不只看設計工具中的縮小預覽。不同尺寸的畫面可重排,但服務條件、價格說明和行動入口要保持一致。

六、表單、預約、付款與後台要做到哪一步?
「需要表單」仍然太籠統:欄位有哪些、送出後到哪個收件箱、客戶是否收到確認、誰要處理資料?預約要不要即時顯示空檔、收取訂金或連接現有日曆?付款要用甚麼服務、涉及退款和稅務資料嗎?這些決定了功能、測試時間和持續費用。把每項功能分成「上線必要」「上線後可加」「暫時不用」,避免第一階段做太多卻未完成核心查詢路徑。後台也要寫清楚:誰需要新增文章、更新產品或查看查詢,並由誰保管登入權限。
| 功能 | 第一階段 | 驗收方式 |
|---|---|---|
| 查詢表單 | 必要 | 測試送出及收件 |
| 預約日曆 | 視乎營運流程 | 測試可選日期與通知 |
| 網上付款 | 先核對商業需要 | 測試付款與失敗情況 |
七、誰擁有網域、內容、原始碼和分析帳戶?
簽約前要問清楚網域登記人、主機帳戶、網站原始碼或後台的交付方式、相片與字體授權,以及 Google Analytics、Search Console 的管理權限。若日後換供應商,企業至少應能取回自己的內容、域名控制權及可用的網站資料。把每年可能繼續支付的網域、主機、第三方工具與維護費逐項寫在報價中,並說明不續約時網站會怎樣。這不是要求每個網站用同一套技術,而是要避免「網站已上線,但誰都不知道帳戶在哪裡」的情況。
- 建立清單網域、主機、網站系統、分析及表單服務。
- 指定擁有人寫明公司管理員、供應商權限與移交方式。
- 安排交接確認資料備份、續費日期及離任同事的權限回收。
八、上線前應如何驗收?
驗收不是「看起來差不多」。用已確認的頁面清單逐頁核對文字、照片、電話、價格和政策;在桌面與手機按過每條主要路徑;測試表單成功與失敗情況;檢查連結、404、圖像替代文字、標題與描述。搜尋設定需檢查 robots、sitemap、canonical 與網址是否一致。可用 Chrome Lighthouse 作速度、無障礙與 SEO 的初步檢查,但分數不能代替真人試用和內容核對。最後記錄「誰簽收哪個版本」以及上線後首週由誰接收查詢和修正問題。
| 核對項 | 通過的證據 | 負責人 |
|---|---|---|
| 內容與圖片 | 逐頁對照已確認稿 | 客戶內容負責人 |
| 手機與桌面 | 實機操作,沒有重要內容遺失 | 設計及測試人員 |
| 查詢流程 | 測試送出並收到指定通知 | 銷售及技術人員 |
| 搜尋入口 | 正式網址與 sitemap 一致 | 網站管理員 |
常見問題
未有全部文字與照片,可以先詢價嗎?
可以。請先列出預計頁數、哪些內容已備妥、哪些仍需撰寫或拍攝;報價應明確區分已包含和另行處理的內容工序。未定稿的資料可能影響排期。
網站需求書是否需要列明預算?
建議提供可接受的預算範圍。設計公司才可把必要功能與後續可加功能分開,並說明不同範圍的成本,而不是憑猜測提交一份無法比較的報價。
驗收後才發現手機版有問題怎麼辦?
先對照已確認的頁面、功能與驗收記錄,列出可重現的裝置、步驟和畫面。屬已承諾範圍的問題應按合約修正;新需求則另行確認版本、費用與排期。