如何测试一篇文章是否解决了读者的问题

从一个读者、一个意图和一个可观察的任务开始

在审查正文之前，写下审核的起始声明：

读者：[特定类型的人]。意图：[他们想要理解或决定的事项]。任务：阅读后，他们可以[可观察的行动]，而无需借助未提及的步骤或来源。

例如：

读者：正在审查实用型网络文章的编辑。意图：确定草稿是否对其目标读者有所帮助。任务：应用完成路径审核，并记录发布、修改或拒绝的决定及理由。

这种区分至关重要。“了解内容质量”是一个信息主题，而不是一个可测试的任务。“识别操作指南文章中缺失的前提条件并修改相关部分”则是可测试的。

将范围保持得足够窄，使完成具有明确的终点。一份指南可以解释如何比较两种产品、准备一份文件、排查某项设置故障，或在多个选项之间做出选择。它不需要回答每一个周边问题来解决其设定的任务。

GOV.UK 的内容与发布指南建议明确用户需求，并围绕这些需求规划内容。Google 自身的自我评估问题也同样询问目标受众是否会觉得内容有用，读者是否能学到足够多的知识以实现其目标，以及他们离开时是否有满意的体验（Google 搜索中心）。这些都是有用的提示，但编辑仍需将它们转化为具体的完成度测试。

在评判文字之前，先梳理出完成路径

按顺序列出读者为完成任务必须采取的行动。包括决策、计算、输入、检查和交接——而不仅仅是文章的小标题。

一个实用的路径图可能如下所示：

然后将每个步骤标记为已涵盖、部分涵盖或缺失。“已涵盖”意味着读者可以根据文章采取行动，而不仅仅是提到了该主题。

例如，一篇关于预算工作表的文章可能会解释如何计算总支出，但却忽略了该使用哪个时间段、税费是否属于总额，或者如何处理不规则账单。其核心计算虽然存在，但完成路径在输入阶段就被打断了。

一个实用的审核表如下：

该表格揭示了草稿作为一个工具是否完整。它还可以防止编辑在忽略缺失的前提条件的同时，对精心雕琢的引言给予过高评价。

检查缺失的输入、假设和停止条件

许多实用型文章在第一条说明之前就失败了，因为它们预设了读者并不具备的知识、权限或条件。通过询问四个问题来审核每个步骤：

明确陈述假设。如果计算使用了百分比，请定义基数。如果设置指南依赖于特定的软件版本，请指明相关版本或功能。如果文章比较了多个选项，请说明使每个选项适用的条件。

将必需的输入与可选的改进区分开来。读者应该能够分辨某一项对于继续操作是必需的，还是仅仅有所帮助。把前提条件放在操作规程之前，这样可以避免徒劳无功。

同时还要寻找隐藏的转换步骤。读者是否需要转换单位、删除空格、选择日期范围或解读错误消息？如果是，请提供规则或简短的说明性示例。不要对缺失的输入私自臆造数值。告诉读者需要获取什么、需要记录什么假设，或者该方法在何时无法完成。

如果一篇文章能坦率地描述失败条件，它会更值得信赖。“如果结果为空，请检查源字段是否已填充”比暗示该方法始终有效更有用。审核应记录读者可能合理受阻的每一个节点。

测试证据的覆盖范围，而非引用的点缀修饰

针对每一个关键论断，思考它需要什么样的支持。一个定义可能需要权威参考。一个操作说明可能需要第一方手册或记录在案的规范。一项建议可能需要明确的标准，以及关于这些标准如何推导出该建议的清晰解释。

创建一个包含四列的论断分类账：论断、受影响的读者决策、使用的证据以及措辞强度。最后一列很重要。证据可能支持“可以”、“通常”或“是必需的”，但并不自然支持“始终”、“最好”或“确保”。请保留来自源材料的条件和限制。

当原始来源或第一方来源记录了事物本身时，应优先选用。例如，W3C 关于 WCAG 2.2 阅读水平的解释指出，当超出指定的阅读难度时，复杂文本应提供更容易理解的版本或补充内容。编辑可以使用该来源来证明进行复杂度检查的合理性，同时避免得出“单一的可读性评分就能让每篇文章都易于理解”这一缺乏依据的结论。

证据应出现在它所支持的论断旁边（如该例所示），而不是放在无关的参考来源列表中。参考来源列表对审查很有用，但它无法补救措辞超出证据支撑范围的段落。检查日期、版本和范围，尤其是与软件、标准或政策相关的说明。

将可用性和可读性作为任务完成度的一部分进行审查

一篇可读性好的文章不仅仅是读起来赏心悦目；它还能减少查找、理解和应用操作说明所需的工作量。在实际应用场景下审查草稿：

W3C 指南解释说，简短常用的词汇和较短的句子通常更容易解读，同时也指出复杂的主题可能适合专业受众。这意味着编辑应该减少可以避免的困难，而不削减必要的准确性。切勿为了简化而删掉会改变结果的条件。

使用表格进行重复对比，使用编号列表呈现顺序，使用简短段落进行推导论证。如果某个步骤需要做决策，请将条件紧置于操作之前。如果某个术语不可避免，请在首次使用时对其进行定义，并在后续始终使用相同的术语。

以泛读者和执行者的双重视角各阅读一遍文章。泛读者应该能够识别出承诺的成果、前提条件和得出答案的路径。执行者应该能够直接执行这些步骤，而无需重新推导作者原本设想的顺序。

在发布前进行读者测试

发布前最有效的检查是与一位类似于目标读者但并未参与起草的人员进行小规模任务测试。给他们任务陈述和文章。要求他们独立操作，只需口述他们正在寻找什么或需要什么——而无需评价他们是否喜欢这篇文章。

观察他们是否：

记录确切的卡点：缺失的字段、模棱两可的标签、跳过的条件、未解释的结果或外部依赖项。不要把读者的成功猜测当成文章清晰明了的证据。问一句：“文章中的什么内容让你决定那样做的？”如果答案是“我本来就知道”，那么草稿可能仍然存在漏洞。

测试后，将每个问题归类为阻碍性、拖慢进度或修饰性问题。优先解决阻碍性问题：缺失的前提条件、存在隐患的歧义、不正确的顺序以及缺失的异常路径。然后对修改后的路径进行重新测试。读者测试并不能证明普适的实用性，但它可以揭示除作者之外的人是否能够实现既定任务。

后期使用分析数据并审慎解读

分析数据可以显示发布后发生的情况——例如访问量、搜索量、退出率或互动——但它们本身并不能证明读者完成了任务。较短的停留时间可能意味着答案很快被找到；较长的停留时间可能意味着读者感到困惑。将行为数据视为调查线索，而不是完成路径审核的替代品。

如果有可用数据，请将其与特定假设联系起来：“读者可能没有找到前提条件”，或者“故障排除分支可能不够明确”。检查相关章节，重复任务测试，并仅在证据支持时才进行修改。避免在没有观察或以其他方式验证读者成果的情况下，将指标直接转化为关于实用性的结论。

Google 的以人为本指南要求创作者评估内容质量、来源、完整性以及读者是否达成了目标。这些问题与本次审核不谋而合，但没有任何搜索系统文档可以证明某篇具体的草稿解决了某个具体的任务。编辑决策的基础始终在于草稿本身、其证据以及可观察的路径。

继续探索这个主题