網站專案會拖延、會超出預算，多半不是因為設計不好看或技術做不到，而是雙方對「現在做到哪一步、下一步該由誰交東西」沒有共識。企業端常以為把需求講完就可以等成品，實際上每個階段都有非企業端不可的確認與提供項目。這篇把從需求訪談到上線驗收的完整流程拆開，說明每一段的產出是什麼、客戶端要提供什麼、要確認到什麼程度才適合往下一階段走。
需求訪談要問出的是決策條件，不是喜好
第一次會議如果只聊「喜歡簡約風格」「希望大氣一點」，這場會議的效益會非常有限。真正該釐清的是幾件具體的事：這個網站主要要說服誰、對方看完之後你希望他做什麼動作、目前生意上最想改善的環節是什麼、內部有哪些不能更動的限制（例如既有系統、品牌規範、法規要求）。
企業端在這個階段要準備的，是內部已經有共識的答案。最常見的問題不是資料不足，而是不同部門對網站目的的期待不一致，業務想要詢價表單、行銷想要形象、資訊部門在意維護成本。這些分歧如果沒有在訪談階段浮上檯面，會在視覺定稿甚至上線前才爆發，那時候修改的代價高很多。
架構與線框階段，要確認的是層級不是顏色
訪談結束後，通常會產出網站地圖與線框稿。網站地圖處理的是「有哪些頁、彼此的從屬關係」，線框稿處理的是「單頁上有哪些區塊、由上到下的順序」。這個階段的圖看起來很陽春，但它是整個專案裡修改成本最低、影響最大的一段。
企業端在這裡要確認的是：頁面清單有沒有漏、選單的分類方式符不符合客戶找東西的習慣、每一頁的區塊順序是否合理、表單要收哪些欄位。要刻意忍住不去討論顏色與字體，因為一旦話題轉到視覺，結構問題就會被蓋過去。這一階段簽核之後，後續視覺與程式都以此為基礎，改架構等於前面白做。
視覺定稿之後才動工，是為了保護雙方
介面設計階段會把線框轉成完整的視覺稿，包含配色、字級、圖片風格、按鈕與各種狀態。慣例上會先做首頁與一到兩個代表性內頁，確認調性之後再展開其餘頁面，這樣可以避免整站做完才發現方向不對。
企業端在這個階段的責任是收斂意見。實務上最消耗時間的情況，是每次回饋都來自不同的人、而且彼此矛盾。比較好的做法是內部先彙整成一份書面意見，指定一位有決策權的窗口統一回覆，並且明確標示哪些是必須修改、哪些是建議。視覺定稿要有正式的簽核紀錄，這對雙方都是保障：對廠商是動工的依據，對企業是驗收的基準。
資料與素材的交付，是最常拖住整個專案的一段
- 文案：各頁的正式內容由誰撰寫、什麼時候交、是否需要外部協助，要在合約階段就講定，不要留到切版完才處理。
- 影像素材：照片的解析度、是否具備使用權、需不需要重新拍攝或去背，都會影響時程與呈現品質。
- 產品或服務資料：品項數量、欄位結構、有沒有現成的表格可以匯入，直接決定上架要花多少人力。
- 品牌規範：標誌原始檔、指定色與字體規範，若沒有現成的，要先確認由誰定義。
- 網域與主機資訊：管理權限在誰手上、能不能取得，這件事常在上線前一週才發現卡住。
- 法遵相關文字：隱私權政策、服務條款、產業別的必要標示，需要企業端確認後提供。
這一段之所以常延誤，是因為它落在企業端而不是廠商端，卻沒有被排進內部的工作清單。建議在專案啟動時就把素材清單與交付日期列出來，並指定負責人。
測試與上線驗收要逐項打勾，而不是憑印象
網站做完之後的驗收，不該是打開首頁看一眼覺得沒問題就結案。合理的驗收會分成幾個面向逐項確認：各頁面的內容是否與提供的資料一致、表單送出後是否確實收到通知、在不同尺寸的螢幕上版面有沒有跑掉、內部連結有沒有失效、後台的各項操作是否都能正常執行。
除了功能之外，還有一組容易被忽略的交接項目：後台最高權限帳號、主機與網域的管理資訊、網站分析與站長工具的權限、備份機制的說明、以及後台操作教學。這些沒有在驗收時一併確認，日後要處理會變得很麻煩。驗收清單建議在專案中期就先擬好，讓雙方都知道最後要對到什麼標準，而不是等到交付當天才開始想。
常見問題
整個網站製作流程通常要多久？
時程主要取決於頁面與版型的數量、功能複雜度，以及企業端提供素材與回覆意見的速度。實務上廠商端的設計與程式工作通常是可以估算的，真正的變數多半落在內容準備與內部簽核。如果希望時程可控，最有效的做法是在啟動時就把素材交付日與各階段的確認期限一起排進去。
可以跳過線框稿，直接看設計稿嗎？
可以，但風險要自己承擔。跳過線框稿代表結構與視覺會一起被討論，一旦後來發現區塊順序需要調整，設計稿也得跟著重做，等於把最便宜的修改階段換成最貴的。只有在頁面極少、結構非常單純的專案，跳過線框稿才比較划算。
企業內部應該指派幾個人參與這個專案？
建議至少要有一位窗口負責彙整意見與跟催素材，以及一位有最終決策權的主管。窗口不必懂技術，但要能協調內部各單位、掌握誰欠什麼東西。人太多而沒有指定決策者，是專案反覆來回的主因；只有一個人但沒有決策權，則會讓每次確認都拖上好幾天。
上線之後才發現想改東西，算在專案範圍內嗎？
要看改的是什麼。原本就約定要有、卻沒做到或做錯的，屬於瑕疵修正，一般在保固範圍內；上線後新產生的想法或新增的功能，屬於新需求，通常另外計算。這條界線最好在合約裡先寫清楚，包含保固期間多長、回應時間如何計算，避免上線後雙方對範圍認知不同。
驗收清單應該由誰來準備？
通常由廠商提供初版，企業端再依自己的實際使用情境補充。廠商比較清楚技術面要檢查哪些項目，企業端則清楚哪些流程是日常真的會用到的，例如表單通知要寄給哪幾個信箱、後台由哪個職務的同仁操作。兩邊合併之後的清單，才是能真正反映使用狀況的驗收依據。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
加入京采 LINE 好友相關主題
下一步
如果你正在評估「網頁製作流程」相關的規劃，可以參考我們的網頁設計服務，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。