Cómo redactar un brief de propósito de página antes de crear contenido web

Antes de redactar, complete y apruebe un brief de propósito con nueve campos: audiencia prevista, pregunta del usuario, función de la página, mensaje clave, evidencia requerida, acción deseada, formato, responsable y fecha de revisión. Contraste la propuesta con el contenido y el recorrido actuales. El resultado puede ser actualizar, combinar, redirigir, rechazar o crear; recibir un título y un formato solicitado no convierte automáticamente la idea en una página nueva.

¿Por qué definir el propósito de la página antes de redactar?

El propósito debe definirse primero porque el equipo necesita comprobar una necesidad válida, una función distinta, la evidencia exigible, el resultado previsto y la responsabilidad de mantenimiento antes de asignar el texto. La orientación de GOV.UK pide vincular cada contenido con usuarios probables, una tarea, evidencia y criterios de aceptación. Un título propuesto o la petición de producir un video son apenas soluciones iniciales, no demostraciones de que haga falta una página.

Cuando esos vacíos pasan al redactor, este termina infiriendo para quién escribe, qué pregunta debe resolver y cómo encaja la pieza con lo publicado. El brief convierte esas decisiones en condiciones observables para revisar el borrador. Sus nueve campos son una síntesis editorial práctica de principios sobre necesidades, planeación y ciclo de vida; no constituyen un estándar oficial ni sustituyen descubrimiento, investigación con usuarios, accesibilidad, verificación de datos, evaluación técnica o aprobación especializada.

¿Qué debe revisar el equipo antes de aprobar otra página?

El equipo debe buscar primero páginas, herramientas, transacciones y otros canales que ya atiendan la necesidad o cumplan la función propuesta. La orientación de GOV.UK recomienda revisar el contenido existente, localizar respuestas incompletas o repetidas y actualizar lo aprovechable antes de publicar más. Varias páginas similares pueden volver incierta la fuente autorizada y dificultar la localización de información, aunque eso no significa que todo contenido relacionado deba fusionarse mecánicamente.

• Actualizar cuando una página existente ya es responsable de la necesidad y puede resolverla completa.
• Combinar cuando varias piezas fragmentan una respuesta o compiten como versiones autorizadas.
• Redirigir o retirar cuando una página quedó obsoleta y otra pasó a ser la fuente vigente.
• Rechazar cuando no hay evidencia suficiente de la necesidad, la función o la conveniencia del canal web.
• Crear únicamente cuando necesidad, función, evidencia, acción, formato, responsable y revisión forman una propuesta coherente.

La revisión también debe mirar el recorrido completo. Una explicación breve junto a una transacción puede ser repetición intencional en el punto de necesidad, no duplicación perjudicial. Asimismo, una mejora en la herramienta, un ajuste al trámite o un canal de atención pueden resolver mejor el problema que una página adicional. El registro debe dejar visible qué alternativa se evaluó, cuál se escogió y con qué evidencia se justificó.

No encargue una página: pídale a la organización que justifique el trabajo que esa página debe cumplir.

¿Cómo se definen la audiencia prevista y la pregunta del usuario?

La audiencia se define por la tarea, la situación o el nivel de conocimiento que cambia lo que la página debe hacer; la pregunta resume la necesidad central en palabras reconocibles para esas personas. “Todos los usuarios” no permite decidir alcance, lenguaje ni profundidad. Tampoco es obligatorio encerrar la propuesta en un único segmento rígido: pueden coexistir grupos cuando comparten una necesidad coherente y las diferencias entre ellos no exigen recorridos incompatibles.

La orientación sobre necesidades recomienda identificar usuarios probables, lo que intentan hacer y la evidencia disponible. Analítica, registros del centro de atención, investigaciones previas y datos externos pertinentes pueden contribuir, pero su suficiencia depende de la pregunta y las suposiciones deben validarse; muchas visitas no explican por sí solas la intención. La guía de estilo de Canadá también pide organizar, escribir y diseñar para la audiencia prevista y concentrarse en su tarea principal.

Redacte la pregunta como una inquietud o tarea real, no como el nombre del producto que alguien desea publicar. Una pregunta central puede contener subpreguntas estrechamente conectadas si la página puede resolverlas como una sola necesidad. Si las fuentes muestran situaciones, conocimientos previos o acciones finales muy distintos, conviene volver al recorrido antes de imponer una pieza única. La preferencia de un interesado, un título de trabajo o un formato solicitado no reemplazan esa evidencia.

¿Cómo se articulan la función, el mensaje clave y la evidencia requerida?

Estos tres campos deben explicar, respectivamente, qué aporta la página al recorrido, qué conclusión necesita la audiencia y con qué pruebas puede sostenerse. La función no es “informar” de manera genérica: debe aclarar por qué una página existente, una transacción, una herramienta u otro canal no cumple mejor ese trabajo. La orientación de servicios de GOV.UK distingue las funciones de la guía y la transacción, y recomienda entregar información en el punto donde se necesita.

Piense en un administrador de cliente que debe configurar una integración. Una explicación previa puede aclarar requisitos y conducir a la ruta correcta, mientras la herramienta ejecuta la configuración. El mensaje clave podría ser que debe confirmar acceso, compatibilidad y registros requeridos antes de comenzar. La evidencia requerida cubriría dos planos: pruebas de que la pregunta existe y documentación, datos, demostraciones o verificación especializada que respalden las afirmaciones de la página.

La guía canadiense recomienda presentar primero la idea, el paso o la información más importante y retirar detalles que no ayudan con la tarea principal. Por eso, el futuro título, el encabezado principal y la apertura deben contrastarse con el mensaje del brief. Además, el criterio WCAG 2.4.2 exige títulos que describan tema o propósito; W3C señala que estos ayudan a identificar páginas, valorar su pertinencia y distinguirlas. Esa revisión puntual no demuestra accesibilidad completa.

¿Cómo debe la acción deseada determinar el formato?

La acción deseada debe nombrar lo que la persona podrá decidir, hacer, localizar, comparar, comprender o alcanzar después de usar la página; el formato se elige para facilitar ese resultado. La acción funciona como condición práctica de aceptación en esta síntesis, pero no equivale necesariamente a diligenciar un formulario, producir un contacto comercial o cerrar una venta. Una página puede cumplir su cometido cuando reduce una incertidumbre relevante y permite continuar correctamente el recorrido.

Solo entonces tiene sentido escoger orientación, comparación, referencia, explicación, paso transaccional, herramienta, video u otra forma justificada. La planeación de GOV.UK relaciona tipo y ubicación con el conocimiento de la audiencia, la tarea y la manera de completarla; también distingue el trabajo de la orientación frente al de una interacción. Las fuentes respaldan ese principio de decisión, no una taxonomía universal de formatos para sitios empresariales.

Compruebe la elección con preguntas concretas: ¿la persona necesita consultar datos, evaluar opciones, seguir una secuencia o realizar una operación? ¿El formato es usable en el momento y canal previstos? ¿La información debe vivir junto a una herramienta? Si una mejora transaccional o un canal no web desempeña mejor el trabajo, regístrelo en vez de deformar la necesidad para justificar contenido. La preferencia interna por un formato no debe anteceder al análisis.

¿Quién responde por la página y cuándo debe revisarse?

Una persona o un equipo identificable debe responder por la exactitud y el mantenimiento de la página, mientras las contribuciones, verificaciones y aprobaciones se registran por separado. Digital.gov describe la gobernanza como un ciclo de creación, mantenimiento, actualización y retiro, en el que propiedad, verificación temática y aprobación son funciones diferenciadas. El responsable coordina el trabajo, pero no absorbe por ello los juicios de accesibilidad, legales, regulatorios, técnicos o especializados.

La fecha de revisión debe convertirse en un compromiso trazable, definido según cambios conocidos, volatilidad, riesgo, evidencia y compromisos de publicación. Cuando resulte práctico, registre también el desencadenante: una versión del producto, una modificación operativa o la renovación de una fuente. Esta priorización es una recomendación operativa; las fuentes respaldan el seguimiento del ciclo de vida y de revisiones programadas, pero no ordenan una periodicidad trimestral, anual ni universal.

Los registros de publicación pueden mostrar la última actualización y advertir que una revisión está vencida. En ese punto, el equipo puede actualizar, corregir, consolidar, redirigir o retirar el contenido según lo encontrado. La fecha crea un punto de control, no una garantía de mantenimiento. Por eso, la aprobación inicial debe confirmar que el responsable tiene autoridad para coordinar la revisión y que los especialistas necesarios pueden intervenir cuando llegue el desencadenante.

¿Cómo se ve un brief de nueve campos completo?

Un brief completo se lee como una decisión coherente, no como nueve respuestas aisladas. El siguiente ejemplo hipotético propone una página de soporte empresarial sin atribuirle resultados de tráfico, conversión, terminación de tareas o ahorro. En un caso real, el equipo tendría que sustituir cada supuesto por evidencia de su propio contexto y documentar quién verificó las afirmaciones antes de aprobar la redacción.

• Audiencia prevista: administradores de clientes que se preparan para configurar una integración compatible.
• Pregunta del usuario: ¿qué debo confirmar antes de iniciar la configuración?
• Función de la página: explicar requisitos antes de enviar al administrador a la herramienta de configuración.
• Mensaje clave: confirme acceso, compatibilidad y registros requeridos antes de comenzar.
• Evidencia requerida: documentación vigente del producto, registros de soporte que muestren la pregunta y verificación del especialista responsable.
• Acción deseada: decidir si la organización está lista y continuar hacia la herramienta o la ruta de soporte correcta.
• Formato: orientación concisa acompañada de una lista de requisitos previos.
• Responsable: equipo de contenido de soporte, con revisores identificados de producto y accesibilidad.
• Fecha de revisión: próximo control programado, vinculado a un desencadenante documentado de lanzamiento del producto.

Antes de asignar el borrador, los interesados deben poder mostrar evidencia de la audiencia y la pregunta, explicar por qué la decisión y la función son distintas, expresar el mensaje y las pruebas requeridas, describir un resultado significativo, justificar el formato, nombrar un responsable y comprometer fecha y desencadenante de revisión. Esta prueba conserva las diferencias entre necesidad, tarea, formato, propiedad, verificación, aprobación y mantenimiento que sustentan las fuentes.

Si una respuesta material sigue sin respaldo o contradice otra parte del brief, devuelva la solicitud a investigación o revisión. Apruebe el encargo únicamente cuando la necesidad, la decisión, los nueve campos y el compromiso de ciclo de vida se sostengan en conjunto. Vincule profesionales calificados cuando las afirmaciones o la implementación requieran criterio de accesibilidad, legal, regulatorio, técnico, de datos o temático; el responsable editorial coordina esas intervenciones, pero no las reemplaza.