如何從真實使用者需求中挑選文章主題
對於獨立網站編輯來說，一個有價值的文章主題始於讀者試圖完成的具體任務——而不是廣泛的關鍵字或模糊的題材。這個方法將觀察到的問題轉化為一個明確的使用者、一個核心意圖，以及一個頁面決策：建立新文章、更新現有文章或捨棄該主題。它利用證據清單將反覆出現的大眾需求與特定帳號的客服支援請求及重複的想法區分開來。
從讀者的任務出發，而非主題標籤
將擬定的需求分為三個部分撰寫：
身為 [特定讀者]，我需要 [執行或決定某事]，以便我能 [達成有用的成果]。
此結構改編自 GOV.UK 的使用者需求方法，該方法建議明確識別使用者、行動以及採取該行動的原因。其指引亦告誡編輯，除非理解對於完成某項明確任務是必要的，否則應對「理解」等模糊動詞保持謹慎（GOV.UK：識別使用者需求）。
例如，「初學者攝影」是一個主題，尚不能作為文章任務。更好的候選表達可能是：
第二個版本範圍更具體，因為它指明了受眾、行動和一項決策。它還為你提供了一個範圍檢驗標準：無法協助讀者做出該決策的資訊，很可能屬於其他地方。
每篇文章保持一個核心意圖。詢問如何選擇工具的問題、詢問如何使用該工具的問題，以及詢問該工具是否合適的問題可能彼此相關，但它們可能需要不同的先決條件和成果。過早將它們合併，會產生標題寬泛但對各項任務而言皆不完整的頁面。
在證據清單中收集證據
一個問題只是一條線索，並不會自動成為一個主題。請記錄足夠的背景資訊，以判斷它是否代表了大眾的資訊需求。簡單的試算表就已足夠；GOV.UK 特別建議在記錄使用者需求和驗收標準的同時，一併記錄佐證證據（GOV.UK：識別使用者需求）。
每個觀察到的問題或高度相關的問題群組使用一列：
不要透過計算在多個管道重複複製的相同問題來虛增頻率。記錄底層需求一次，並註記其出現的管道。相反地，如果每個例子都顯示出相同的未解決任務，且答案可以服務更廣泛的大眾受眾，切勿僅僅因為某個需求只出現過幾次就將其忽略。
有用的清單能將證據與詮釋區分開來。「四位讀者詢問第一次練習是否需要特殊器材」是證據。「讀者想要低成本的初學者指南」是詮釋。兩者都要保留，但要分開標記。
將大眾需求與純支援問題分開
關鍵的編輯問題不僅僅是「有人問過這個問題嗎？」而是「一般性的頁面能否幫助相當數量的讀者完成相同的任務？」Digital.gov 的簡易語言指引始於一項觀察：人們造訪網站是為了做不同的事情；該指引建議圍繞受眾及其需要完成的目標來組織內容（Digital.gov：簡易語言原則）。
在清單中對每個候選項目進行分類：
反覆出現的大眾需求：
當問題有穩定、通用的一般答案，且相同的任務出現在不同人員、管道或情境中時，即可建立或更新文章。範例包括在描述清楚的選項中進行選擇、為常見流程做準備，或診斷廣泛可觀察到的問題。文章應說明其受眾和範疇界限，以便讀者能夠辨別該內容是否適用於自己。
純支援需求：
純支援問題取決於私人帳號資料、個別訂單、個人設定或僅能由人員操作執行的動作。它可能有理由製作支援指引或提供聯絡管道，但未必需要一篇通用的大眾編輯文章。當答案取決於其他讀者無法獲取的資訊時，請勿將「為什麼我的帳號會收到這條訊息？」變成通用性說明。
如果存在可重複的通用任務（例如解釋該訊息類別的含義，以及讀者在聯繫客服支援前應收集哪些資訊），你仍然可以發布配套的大眾公開頁面。但請將涉及私人隱私的解決方案留在文章之外。
重複的需求：
重複是指現有頁面已經在適當的詳細程度下，為相同的受眾回答了真實的問題。正確的做法可能是改進現有頁面的開頭、範例、導覽或缺失的條件。新增一個 URL 只會分散注意力，而不會增加獨特的任務價值。
如果沒有完整的網站內容盤點，編輯就無法如實宣稱不存在重複內容。務實的做法是檢查已知的相關頁面，必要時將內容盤點檢查標記為未完成，並避免將新文章呈現為唯一的解答。
在確定標題之前使用決策關卡
讓候選項目通過五道關卡。回答「否」並不總是意味著否決這個想法；它告訴你還需要做哪種類型的工作。
將評估結果作為編輯把關的決策依據：
此決策關卡是根據資料來源中的兩項原則建構的編輯推論：內容應服務於明確的受眾和任務，且發布者應保留支持該需求的證據。它是一種決策輔助工具，而非搜尋引擎公式。
將獲選的需求轉化為實用的文章簡報
一旦主題通過關卡，請在雕琢文字措辭之前先撰寫簡報。內容包括：
以範例主題為例，驗收檢核表可以是：讀者能夠將原始問題轉化為使用者陳述；識別核心任務；將證據分類為大眾、純支援或重複；並選擇建立、更新、保留或捨棄。這遵循了 GOV.UK 驗收標準的邏輯，即描述滿足使用者需求時必須具備的條件（GOV.UK：識別使用者需求）。
利用簡報來把控標題。「如何從真實使用者需求中挑選文章主題」適合需要可重複選題方法的編輯。「如何找到最佳內容主題」則範圍過寬，且隱含了缺乏根據的排名或品質評判。Google 自己的指引詢問網站是否有預期受眾、內容是否有助於讀者實現目標，以及內容是否為人而寫，而非主要為了吸引搜尋點擊（Google 搜尋中心：建立實用、可靠、以人為本的內容）。這些問題強化了明確編輯任務的價值，但它們並不能保證流量或排名。
使文章具備可解答性、易讀性與可維護性
如果草稿讓讀者必須自行拼湊出答案，真實的需求仍然可能產出一篇拙劣的頁面。請將直接答案放在開頭附近，然後解釋會改變該答案的條件。在語意清楚之處，採用清單中讀者使用的術語，但要對內部編輯術語進行定義，例如「純支援」和「重複」。
圍繞決策和行動來組織文章，而不是列出一堆鬆散相關的關鍵字。Digital.gov 建議為受眾撰寫內容、組織資訊、使用簡短簡單的語言，並避免不必要的行話（Digital.gov：簡易語言原則）。對於編輯方法而言，這意味著要展示清單欄位、決策關卡以及至少一個實用範例——而不僅僅是建議編輯「了解他們的受眾」。
在驗收之前，請檢查每個具關鍵影響的陳述：
如果由於盤點不完整導致最後一個問題的答案為「否」，請記錄該局限性。坦承「需要審查網站內容盤點」比宣稱該主題完全原創卻缺乏依據更具實用價值。
常見問題
在一個主題確立前需要多少個問題？
沒有統一的數字。重複出現是實用的證據，但任務相似性與大眾適用性比任意設定的門檻更重要。一個記錄詳實的反覆出現任務，可能比幾個互不相關的問題更有說服力。
是否每個支援問題都應該變成常見問題（FAQ）？
不是。如果答案取決於私人帳號或交易細節，請將解決方案引導至客服支援。只有在能夠解釋可重複的大眾任務，且不會洩露或猜測個人資訊時，才發布通用文章。
如果關鍵字範圍很廣，但需求很窄，該怎麼辦？
保持文章聚焦於狹窄範圍。廣泛的標籤可作為內部發現詞彙，但標題、開頭和驗收標準應描述具體的讀者任務。
編輯何時應該捨棄某個主題？
當證據顯示沒有反覆出現的大眾任務、答案無法查證、相關頁面已涵蓋該意圖，或者擬定的文章需要編造編輯無法確立的條件時，請捨棄或保留該主題。當捨棄能防止產生不準確或冗餘的頁面時，它是一項合理的編輯決策。