如何測試一篇文章是否解決了讀者的問題

從一位讀者、一個意圖和一項可觀察的任務開始

在審查文字內容之前，先寫下審查的起始陳述：

讀者：[特定類型的群體]。意圖：[他們想要理解或決定的事情]。任務：閱讀後，他們可以完成[可觀察的行動]，而不需要未提及的步驟或來源。

例如：

讀者：審查實用網頁文章的編輯。意圖：確定初稿是否有助於目標讀者。任務：應用完成路徑審查，並記錄發布、修改或拒絕的決定及原因。

這種區分非常重要。「了解內容品質」是一個資訊主題，而不是可測試的任務。「找出操作指南文章中缺失的前提條件並修改相關章節」則是可測試的。

保持範圍足夠狹窄，以便任務的完成具有明確的終點。指南可以解釋如何比較兩種產品、準備一份文件、排查某項設定的故障，或在多個選項之間做出選擇。它不需要回答每個相鄰的問題來解決其陳述的任務。

GOV.UK 內容與發布指南建議識別使用者需求並圍繞這些需求規劃內容。Google 自身的自我評估問題同樣詢問目標受眾是否會覺得內容實用、讀者是否能學到足夠的知識以達成目標，以及他們離開時是否獲得滿意的體驗（Google 搜尋中心）。這些都是很有用的提示，但編輯仍需將它們轉化為具體的完成度測試。

在評斷寫作之前先繪製完成路徑

按順序列出讀者為完成任務必須採取的行動。包括決策、計算、輸入、檢查和交接——而不僅僅是文章的標題。

實際的路徑圖可能長這樣：

然後將每個步驟標記為已涵蓋、部分涵蓋或缺失。「已涵蓋」意味著讀者可以根據文章採取行動，而不僅僅是提及了該主題。

例如，一篇關於預算工作表文章可能會解釋如何計算總支出，但忽略了應使用哪個時間段、稅費是否包含在總額中，或者如何處理非經常性帳單。其核心計算步驟雖然存在，但完成路徑在輸入階段就中斷了。

一個實用的審查表如下：

此表揭示了初稿作為工具是否完整。它還可以防止編輯因過於青睞文筆優美的引言，而忽視了缺失的前提條件。

檢查缺失的輸入、假設與停止條件

許多實用文章在第一條指引之前就失敗了，因為它們預設了讀者並不具備的知識、存取權限或條件。透過提出四個問題來審查每個步驟：

明確說明各項假設。如果計算涉及百分比，請定義基準。如果設定指南依賴於特定的軟體版本，請指出相關版本或功能。如果文章對多種選項進行比較，請說明各選項在什麼條件下適用。

將必要輸入與選用改善項目區分開來。讀者應該能夠判斷某個項目是繼續操作所必需的，還是僅有輔助性質。請將前提條件放在操作步驟之前，以避免徒勞無功。

此外，尋找隱藏的轉換。讀者是否需要轉換單位、刪除空格、選擇日期範圍或解讀錯誤訊息？如果是，請提供規則或簡短的說明範例。不要為缺失的輸入暗自捏造數值。告訴讀者該獲取什麼、記錄何種假設，或者何時該方法無法完成。

當文章直截了當地描述失敗條件時，會更值得信賴。「如果結果為空白，請檢查來源欄位是否有資料」比暗示該方法永遠有效更實用。審查應記錄讀者可能遇到障礙的每一個關鍵點。

測試證據覆蓋範圍，而非僅是引用點綴

對於每個重要的論點，詢問它需要何種支援依據。定義可能需要權威參考。操作指南可能需要原廠手冊或正式的文件規範。建議可能需要明確的標準，以及這些標準如何導出該建議的清晰解釋。

建立一個包含四欄的論點清單：論點、受影響的讀者決策、所用證據和措辭強度。最後一欄至關重要。證據可能支持「可以」、「通常」或「需要」，但不能自動支持「總是」、「最好」或「保證」。請保留來源中的條件與限制。

當原創或第一手來源記錄事物本身時，應優先採用。例如，W3C 對 WCAG 2.2 閱讀難易度等級的說明指出，當超出指定的閱讀要求時，複雜文字應具有更易理解的版本或補充內容。編輯可以使用該來源作為複雜度檢查的合理依據，同時避免得出「單一易讀性分數就能使所有文章具備無障礙性」這種缺乏依據的結論。

證據應出現在其支持的論點旁邊（如該範例所示），而不是放在不相關的來源列表中。來源列表便於審查，但無法彌補措辭超出證據支持範圍的段落。請檢查日期、版本和適用範圍，特別是與軟體、標準或政策相關的指示。

將易讀性和可讀性作為任務完成度的一部分進行審查

一篇易讀的文章不僅令人賞心悅目，還能減少尋找、理解和應用指引所需的工作量。在使用的具體情境下審查初稿：

W3C 指南說明，簡短、常見的詞彙和較短的句子通常更容易解讀，同時也指出複雜主題可能適合專業受眾。這意味著編輯應該減少可以避免的難度，同時不消除必要的精確度。不要為了簡化而去掉會改變結果的條件。

重複比較時使用表格，排序時使用編號列表，論證說明時使用短段落。如果某個步驟需要做出決定，請將條件置於操作之前。如果某個術語不可避免，請在首次使用時進行定義，並在此後始終使用同一術語。

以快速瀏覽者和實際操作者的身分各讀一次文章。快速瀏覽者應該能夠識別承諾的成果、必備條件以及找到答案的路徑。實際操作者應該能夠執行步驟，而無需自行重構作者原本設想的順序。

執行發布前的讀者測試

發布前最有效的檢查是找一位與目標讀者相似但未參與初稿撰寫的人進行小型任務測試。向他們提供任務陳述和文章。要求他們獨立操作，只口頭敘述他們在尋找什麼或需要什麼，而不是評價是否喜歡這篇文章。

觀察他們是否：

記錄確切的阻力點：遺漏的欄位、模糊的標籤、被忽略的條件、無法解釋的結果或外部依賴項。不要將讀者猜對視為文章清晰的證明。問：「文章中是什麼告訴你要這樣做的？」如果答案是「我本來就知道」，那麼初稿可能仍有缺漏。

測試完成後，將每個問題分類為阻礙型、拖延型或外觀型。首先解決阻礙型問題：缺失的前提條件、危險的模稜兩可、不正確的順序和缺失的例外路徑。然後重新測試變更後的路徑。讀者測試並不能建立普遍的實用性，但它可以揭示除作者之外的人是否能夠達成所陳述的任務。

後續使用分析數據時應謹慎解讀

分析數據可以顯示發布後發生的情況（例如造訪次數、搜尋、跳出或互動），但僅憑數據本身並不能證明讀者完成了任務。短暫的造訪可能意味著迅速找到了答案；長時間的停留可能意味著讀者感到困惑。應將行為數據視為深入調查的契機，而不是取代完成路徑審查的工具。

如果有可用數據，請將其與具體假設連結起來：「讀者可能沒有找到前提條件」，或「故障排除分支可能不夠清晰」。檢查相關章節，重複任務測試，並且僅在證據支持該變更時才進行修改。避免在未觀察或未驗證讀者實際結果的情況下，將指標直接轉化為對實用性的斷言。

Google 的以人為本指南要求創作者評估內容品質、來源、完整性以及讀者是否實現了目標。這些問題與本審查一致，但沒有任何搜尋系統文件能夠保證某個特定初稿一定解決了某個特定任務。編輯決策的基礎始終是初稿本身、其證據以及觀察到的路徑。

繼續探索這個主題