網站內容動筆前，如何寫好頁面目的簡報

先別把利害關係人帶來的標題、版型或「請寫一頁」直接排進製作。動筆前，先完成一份頁面目的簡報，依序寫清楚預定受眾、使用者問題、頁面角色、核心訊息、必要證據、期望行動、內容形式、負責人與檢視日期。再把提案放回既有網站與完整旅程檢查；合理結果可能是更新、合併、重新導向、駁回或建立，而不一定是新增頁面。

為什麼必須先決定頁面目的，才能開始寫？

因為團隊必須先確認需求是否成立、頁面在旅程中是否有獨特工作、主張需要哪些證據、讀者使用後應得到什麼結果，以及誰承擔後續維護責任，才有足夠條件委派撰稿。GOV.UK 的使用者需求指引同樣要求內容對應有效需求，並記錄可能的使用者、任務、證據及驗收條件。

若從預設標題或指定格式直接起稿，撰稿者只能自行猜測受眾、問題、證據、下一步及既有內容關係；文稿即使句子完整，也可能同時服務多個互不相容的目的。九欄方法是本站整合需求、內容規劃及生命週期治理原則的編輯工具，不是官方標準，更不能代替探索研究、無障礙檢查、事實查核、技術評估或必要的專業核准。

核准另一個頁面前，團隊應先查什麼？

先搜尋目前網站、站內搜尋結果與相關任務旅程，找出已在回答同一問題的頁面、下載資料、工具、交易步驟及其他服務管道。接著比較它們的受眾、權威來源、更新狀態與下一步。官方指引建議新增前先找出可更新內容、重複內容及任務資訊缺口；相近頁面也可能讓使用者難以判斷哪一處才是可靠來源。

• 更新：既有頁面已擁有該需求與角色，只需補強內容或證據。
• 合併：片段分散在多頁，形成彼此競爭或不完整的答案。
• 重新導向：舊頁已失去權威性，應把使用者帶往現行來源。
• 駁回：沒有足夠需求證據、沒有獨特角色，或其他管道更合適。
• 建立：需求、角色、證據、行動、形式、負責人與檢視計畫彼此一致。

不要機械式合併所有相似內容。交易或工具的操作當下，少量重複提示可能正好降低來回尋找的負擔；真正要避免的是多個頁面都自稱完整而權威，卻各自維護不同版本。決策重點不是頁面主題是否相近，而是每份內容在旅程中是否有清楚且不衝突的工作。

別先要求撰稿者生出一個頁面；先要求組織說清楚這個頁面憑什麼存在。

如何界定預定受眾與使用者問題？

請用會實際改變內容決策的任務、情境或知識程度來界定受眾，再用他們認得的說法寫出一個有證據的核心問題。像「所有客戶」或「一般使用者」無法告訴編輯應解釋多少背景、採用哪些例子，也無法判斷頁面是否解決了問題；較有用的寫法會指出他們正處於哪個任務階段，以及已經知道什麼。

一個核心問題可以包含緊密相連的子問題，不必強迫每個問句各有一頁；檢查標準是它們能否形成一致需求，並由同一角色妥善解決。可採用的證據包括網站分析、客服或服務台紀錄、先前研究及相關外部資料，但每種資料都要回答明確問題。流量能顯示多少行為，不能單獨證明使用者為何造訪；內部偏好、工作標題或指定影片也都不是需求證據。

頁面角色、核心訊息與必要證據如何互相配合？

三者要依序回答「這頁在旅程中做什麼」、「讀者最終必須知道什麼」及「我們憑什麼這樣說」。頁面角色應指出它不可被既有頁面、工具、交易或其他管道取代的工作；核心訊息則把那項工作濃縮成一個必要結論，讓最重要、最能協助任務的內容先出現，而不是先鋪陳組織背景。

必要證據要分成兩組：第一組證明這項使用者需求確實存在，第二組支持頁面即將發布的個別主張。後者可能包含現行文件、資料紀錄、示範結果或負責領域專家的查證。若某頁是管理員進入設定工具前的先決條件說明，它可以解釋權限、相容性及必備資料，但設定本身仍由工具處理；如此才能避免說明頁與交易介面互相越界。

完稿後，把頁面標題、主標題與開頭拿回來對照簡報的核心訊息。WCAG 2.4.2 要求頁面標題描述主題或目的，W3C 也說明描述性標題有助於辨識、區分頁面及判斷相關性。不過，這項對照只能檢查目的是否清楚，不能被當成完整無障礙驗證。

期望行動應如何決定內容形式？

先寫出讀者使用內容後應能決定、理解、比較、找到或繼續完成什麼，再選擇最能促成該結果的形式。期望行動不是預先指定的按鈕，也不必是留下名單、送出表單或購買；把它當成驗收條件，是要讓審稿者能問：「這份內容是否提供了足以完成下一步的資訊與路徑？」

形式必須跟著需求、角色及旅程走。穩定而需查閱的細節可能適合參考頁；需要辨別差異的任務可能適合比較內容；複雜選擇也可能需要工具或互動流程，而不是更長的文章。若修改交易步驟、改善工具或由客服管道承接更合適，簡報就應記錄那項決定。本文列舉的是選項，不是適用所有商務網站的固定分類。

誰負責頁面，又該在何時檢視？

請指定一位可歸責的人或一個團隊，對頁面的準確性與維護負責，並把貢獻者、主題專家、核准者、無障礙審查者、法務或法規審查者及技術執行者分開記錄。內容治理涵蓋建立、維護、更新與移除；負責人的工作是協調並確保決策有人承接，不是親自取代每一種專業判斷。

檢視日期則應依已知變動、內容波動性、錯誤風險、證據狀態及發布承諾安排，實務上最好同時記下觸發條件，例如產品版本變更或權威資料更新。不要替所有頁面套用相同的每季或每年週期。發布紀錄可以顯示最後更新時間與逾期檢視，但設下日期只建立檢查點，並不保證維護自然發生。

到期時不要只改日期。負責人應確認需求是否仍存在、證據是否仍有效、頁面是否仍位於正確旅程位置，以及其他內容是否已成為較適合的權威來源。檢視結果可能是更新、修正、整併、重新導向或退場；把這些選項納入流程，才能讓所有權真正涵蓋內容生命週期。

完成的九欄頁面目的簡報長什麼樣？

完成品應是一份可供團隊核准的精簡決策紀錄，而不是迷你文稿或關鍵字清單。以下用假想的企業客戶支援頁示範；它只呈現欄位之間如何扣合，不主張任何流量、完成率、轉換率或成本效益，實際團隊必須以自身研究、產品資料及治理要求替換其中假設。

• 預定受眾：準備設定受支援整合功能的客戶管理員。
• 使用者問題：開始設定前，我必須先確認哪些事項？
• 頁面角色：進入設定工具前的先決條件說明。
• 核心訊息：開始前先確認存取權、相容性及必要紀錄。
• 必要證據：現行產品文件、顯示此問題的支援紀錄，以及負責產品專家的查證。
• 期望行動：判斷組織是否已準備妥當，並前往正確工具或支援管道。
• 內容形式：精簡說明搭配先決條件檢查清單。
• 負責人：產品支援內容團隊，另列產品與無障礙審查者。
• 檢視日期：設定下一個檢查點，並連結已記錄的產品版本觸發條件。

核准前，逐項詢問：受眾與問題有什麼證據？為何所選決策及頁面角色不同於既有內容？核心訊息需要哪些證明？讀者會得到什麼有意義的下一步？形式為何適合？誰對準確性與維護負責？下一次檢視由哪個日期與事件觸發？只要關鍵答案仍缺乏支持或彼此矛盾，就先退回研究與修訂，不要把未完成的決策轉嫁給撰稿者。

只有當需求、五種處置選擇、九個欄位及生命週期承諾能彼此成立，才核准撰稿任務。若頁面涉及無障礙、法務、法規、技術、數據或專業領域判斷，應安排合格人員參與；可歸責的內容負責人負責協調與追蹤，但不能代替這些專業職責。