Cómo comprobar si un artículo resuelve el problema del lector

Empiece con un lector, una intención y una tarea observable

Redacte la declaración inicial de la auditoría antes de revisar el texto:

Lector: [tipo específico de persona]. Intención: [lo que quiere entender o decidir]. Tarea: Tras la lectura, puede [acción observable] sin necesidad de recurrir a pasos o fuentes no mencionados.

Por ejemplo:

Lector: Un editor que revisa un artículo web práctico. Intención: Determinar si el borrador ayuda a su lector previsto. Tarea: Aplicar una auditoría de ruta de finalización y registrar una decisión de publicar, revisar o rechazar con sus respectivos motivos.

Esta distinción es importante. «Aprender sobre la calidad del contenido» es un tema informativo, no una tarea comprobable. «Identificar el prerrequisito faltante en un artículo práctico y revisar la sección correspondiente» sí es comprobable.

Mantenga el alcance lo suficientemente acotado para que la finalización tenga un punto final claro. Una guía puede explicar cómo comparar dos productos, preparar un documento, solucionar un problema de configuración o elegir entre varias opciones. No necesita responder a todas las preguntas adyacentes para resolver la tarea establecida.

La guía de contenido y publicación de GOV.UK recomienda identificar las necesidades de los usuarios y planificar el contenido en torno a ellas. Del mismo modo, las preguntas de autoevaluación de Google indagan si la audiencia prevista consideraría útil el contenido, si los lectores aprenderán lo suficiente para lograr su objetivo y si se marcharán con una experiencia satisfactoria (Google Search Central). Son pautas útiles, pero el editor aún debe convertirlas en una prueba concreta de finalización.

Trace la ruta de finalización antes de juzgar la redacción

Enumere las acciones que un lector debe realizar, en orden, para finalizar la tarea. Incluya decisiones, cálculos, entradas de datos, comprobaciones y transiciones, no solo los encabezados del artículo.

Un mapa práctico podría verse así:

A continuación, marque cada paso como cubierto, parcialmente cubierto o ausente. «Cubierto» significa que el lector puede actuar a partir del artículo, no simplemente que se mencione el tema.

Por ejemplo, un artículo sobre una plantilla de presupuesto podría explicar cómo sumar los gastos, pero omitir qué período de tiempo utilizar, si los impuestos deben incluirse en el total o cómo gestionar una factura irregular. Su cálculo central está presente, pero la ruta de finalización se interrumpe en la fase de entrada de datos.

Una tabla de auditoría útil es:

Esta tabla revela si el borrador es completo como herramienta. También evita que un editor premie una introducción bien redactada mientras pasa por alto un prerrequisito ausente.

Compruebe los datos de entrada ausentes, las suposiciones y las condiciones de parada

Muchos artículos prácticos fallan antes de la primera instrucción porque asumen conocimientos, accesos o condiciones de los que el lector carece. Audite cada paso planteándose cuatro preguntas:

Declare las suposiciones de forma explícita. Si un cálculo utiliza un porcentaje, defina la base. Si una guía de configuración depende de una versión específica de software, identifique la versión o función correspondiente. Si un artículo compara opciones, indique qué condiciones hacen que cada opción sea adecuada.

Separe los datos de entrada requeridos de las mejoras opcionales. El lector debe poder distinguir si un elemento es imprescindible para continuar o si solo es de ayuda. Coloque los prerrequisitos antes del procedimiento, donde pueden evitar esfuerzos innecesarios.

Busque también transformaciones ocultas. ¿Necesita el lector convertir unidades, eliminar espacios, seleccionar un rango de fechas o interpretar un mensaje de error? Si es así, proporcione la regla o un breve ejemplo ilustrativo. No invente silenciosamente un valor para un dato de entrada ausente. Indique al lector qué debe obtener, qué suposición debe documentar o en qué casos no es posible completar el método.

Un artículo resulta más confiable cuando describe las condiciones de error con claridad. «Si el resultado está en blanco, compruebe si el campo de origen contiene datos» es más útil que dar a entender que el método siempre funciona. La auditoría debe registrar cada punto en el que un lector podría quedarse razonablemente atascado.

Evalúe el respaldo de las afirmaciones, no el adorno de las citas

Para cada afirmación de peso, pregunte qué tipo de respaldo necesita. Una definición puede requerir una referencia autorizada. Una instrucción procedimental puede requerir un manual oficial o una especificación documentada. Una recomendación puede requerir criterios declarados y una explicación clara de cómo esos criterios conducen a la recomendación.

Cree un registro de afirmaciones con cuatro columnas: afirmación, decisión del lector afectada, evidencia utilizada y contundencia de la redacción. La última columna es importante. Las evidencias pueden respaldar «puede», «habitualmente» o «se requiere», pero no automáticamente «siempre», «el mejor» o «garantizado». Conserve las condiciones y limitaciones de la fuente original.

Priorice las fuentes originales o directas cuando documenten el elemento en sí. La explicación del W3C sobre el nivel de lectura de las WCAG 2.2, por ejemplo, establece que el texto complejo debe contar con una versión más comprensible o contenido complementario cuando se supera la exigencia de lectura especificada. Un editor puede utilizar esa fuente para justificar una comprobación de complejidad, evitando al mismo tiempo la conclusión infundada de que una sola puntuación de legibilidad hace que cualquier artículo sea accesible.

Las evidencias deben figurar junto a la afirmación que respaldan, como en ese ejemplo, en lugar de en una lista inconexa de fuentes. Una lista de fuentes es útil para la revisión, pero no puede subsanar un párrafo cuya redacción va más allá de lo que respaldan sus evidencias. Verifique fechas, versiones y alcance, especialmente en instrucciones vinculadas a software, normas o políticas.

Revise la usabilidad y la legibilidad como parte de la finalización de la tarea

Un artículo legible no es simplemente agradable; reduce el esfuerzo necesario para localizar, comprender y aplicar una instrucción. Revise el borrador en el punto de uso:

La guía del W3C explica que las palabras breves y de uso común, así como las oraciones más cortas, son generalmente más fáciles de decodificar, al tiempo que señala que los temas complejos pueden ser adecuados para una audiencia especializada. Esto significa que la edición debe reducir las dificultades evitables sin restar la precisión necesaria. No simplifique hasta el punto de omitir una condición que altere el resultado.

Utilice tablas para comparaciones recurrentes, listas numeradas para secuencias y párrafos breves para el razonamiento. Si un paso requiere tomar una decisión, sitúe la condición inmediatamente antes de la acción. Si un término es inevitable, defínalo en su primera aparición y emplee el mismo término a partir de entonces.

Lea el artículo una vez por encima y otra vez como ejecutor de las instrucciones. La lectura rápida debe permitir identificar el resultado prometido, los prerrequisitos y la vía hacia la respuesta. La persona ejecutora debe poder realizar los pasos sin tener que reconstruir el orden previsto por el autor.

Realice una prueba con lectores antes de la publicación

La comprobación previa a la publicación más sólida es una pequeña prueba de tareas con una persona que se asemeje al lector previsto pero que no haya redactado el borrador. Entréguele el enunciado de la tarea y el artículo. Pídale que trabaje de forma autónoma, narrando únicamente lo que busca o lo que necesita, sin opinar sobre si le agrada el artículo.

Observe si:

Registre los puntos exactos de fricción: un campo omitido, una etiqueta ambigua, una condición ignorada, un resultado sin explicar o una dependencia externa. No considere que el acierto por deducción del lector es una prueba de que el artículo sea claro. Pregunte: «¿Qué parte del artículo le indicó que hiciera eso?». Si la respuesta es «Ya lo sabía», es posible que el borrador aún contenga lagunas.

Tras la prueba, clasifique cada problema como bloqueante, ralentizador o de formato. Corrija primero los problemas bloqueantes: prerrequisitos faltantes, ambigüedades de riesgo, secuencias incorrectas y ausencia de vías para excepciones. Luego, vuelva a evaluar la ruta modificada. Una prueba con lectores no garantiza una utilidad universal, pero puede poner de manifiesto si la tarea establecida es realizable por alguien que no sea el autor.

Utilice las analíticas más adelante e interprételas con cautela

Las analíticas pueden mostrar lo ocurrido tras la publicación —como visitas, búsquedas, abandonos o interacciones—, pero no demuestran por sí solas que un lector haya completado la tarea. Una visita corta puede significar que la respuesta se encontró con rapidez; una visita larga puede indicar que el lector estaba confundido. Considere los datos de comportamiento como un motivo de indagación, no como un sustituto de la auditoría de la ruta de finalización.

Si dispone de datos, vincúlelos a una hipótesis específica: «Es posible que los lectores no encuentren el prerrequisito» o «La sección de resolución de problemas puede no estar clara». Inspeccione la sección pertinente, repita la prueba de tareas y revise únicamente cuando las evidencias respalden el cambio. Evite transformar una métrica en una conclusión sobre la utilidad sin observar o verificar de otro modo el resultado del lector.

La orientación de Google centrada en las personas pide a los creadores que evalúen la calidad del contenido, las fuentes, la exhaustividad y si los lectores alcanzan su objetivo. Esas preguntas coinciden con esta auditoría, pero ningún documento de sistemas de búsqueda puede certificar que un borrador específico resuelva una tarea concreta. La decisión editorial sigue fundamentándose en el borrador, sus evidencias y la ruta observada.

Sigue explorando este tema