詢價前的網站需求清單
不需要先寫出完整規格書，但至少要說清楚網站要達成什麼目標、誰會使用、需要哪些頁面與功能。已確定的先填；不確定的標註「需要討論」，不必為了詢價而猜答案。
- 網站目標
- 希望取得詢問、展示作品、提供產品資訊、接受預約，還是讓客戶自行購買？最重要的訪客行動是什麼？
- 目標使用者
- 主要訪客是一般消費者、企業採購、既有客戶，還是內部員工？
- 預計頁面
- 列出首頁、關於我們、服務介紹、案例、文章、常見問題及聯絡我們等頁面，並估計各類頁數。
- 內容與素材
- 文字、照片、Logo 與產品資料由誰提供？是否需要協助撰寫文案或製作圖片？
- 必要功能
- 是否需要聯絡表單、搜尋、會員、預約、付款、下載、多語言或第三方系統串接？
- 更新方式
- 上線後誰會修改文章、圖片及服務內容？是否需要管理後台？
- 既有資產
- 是否已有網域、主機、舊網站與分析工具？舊網址或資料是否需要搬遷？
- 時程與預算
- 希望何時上線？是否有活動期限？可接受的預算區間是多少？
把「第一版一定要有」與「以後可以做」分開。例如第一版只需要服務介紹與詢問表單，就不必把會員和付款都列為必要功能。
可直接複製的需求描述範例
這份描述的目的，是讓開發方先判斷範圍，並指出哪些問題會影響報價與時程。空白處可依你的專案填寫。
我們是一家提供＿＿＿＿服務的公司，想建立一個以＿＿＿＿為主要訪客的網站。網站最重要的目標是＿＿＿＿，希望訪客完成的動作是＿＿＿＿。
第一版預計包含＿＿＿＿個頁面，必要功能有＿＿＿＿。文字與圖片由＿＿＿＿提供；上線後預計由＿＿＿＿更新內容。
我們目前已有／尚未有網域與舊網站。希望於＿＿＿＿前上線，預算約為＿＿＿＿。以下項目尚未確定，希望開發公司協助評估：＿＿＿＿。
網站驗收不能只寫「畫面完成」
驗收方式應在開發前討論，而不是網站做好後才臨時決定。以下以包含首頁、服務頁、案例頁與聯絡表單的企業網站為例；實際項目仍須依雙方約定的範圍調整。
- 頁面與內容
- 對照核定的頁面清單，確認文字、圖片、連結與按鈕；未完成內容列入待補清單。
- 手機與桌機版面
- 在事先約定的手機尺寸和桌機瀏覽器檢查可讀性、選單與表單操作，且沒有非預期的水平捲動。
- 聯絡表單
- 測試正常送出、必填未填及 Email 格式錯誤；確認訊息送達約定信箱或儲存位置，並顯示清楚的結果。
- 內容後台（若有）
- 使用交付的管理帳號實際修改、預覽及發布一篇文章或一個服務頁，確認權限與操作方式。
- 基礎搜尋設定
- 檢查公開頁面的標題、描述、主要標題、網址及站內連結，並核對 sitemap 與索引設定。
- 上線與交接
- 以正式網址檢查頁面和表單，交付約定的帳號、程式碼或後台權限、操作說明與已知待處理事項。
速度也應先約定要測哪些頁面、裝置、工具與環境，以及未達目標時如何處理。不要只寫「網站要快」，也不要把單次測試分數當成所有訪客的實際體驗。
交付前確認所有權與後續責任
網站上線後，誰擁有帳號、誰負責更新與維護，往往比畫面細節更影響能否持續經營。至少確認以下事項：
- 網域與主機登記在誰的帳號？續費由誰處理？
- 程式碼、設計檔、圖片及授權素材如何交付？
- 管理帳號由誰保管？需要哪些權限？
- 內容、程式、主機與備份分別由誰維護？
- 發生錯誤時由誰接收通知、如何聯絡？
- 驗收後的錯誤修正期間有多久？新增功能如何另行估價？
例如「完成聯絡表單」不等於「日後所有表單欄位修改都包含在原報價內」。把交付範圍、排除項目與變更方式寫清楚，才能減少開發中途的認知落差。
從四件事開始就夠了
一份好的網站需求，不是把所有功能想得鉅細靡遺，而是讓雙方知道第一版要解決什麼問題，以及怎樣算完成。先整理網站目標、頁面清單、必要功能和驗收方式；其餘技術選擇，再與開發團隊一起判斷。