Antes de encargar una página, completa y aprueba un brief 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. Primero contrasta la solicitud con el contenido y el recorrido existentes. El resultado puede ser actualizar, combinar, redirigir, rechazar o crear; recibir un título tentativo, un formato preferido o el pedido de “hacer una página” todavía no convierte la propuesta en un trabajo de redacción.
Decisiones clave
Una solicitud se convierte en encargo solo cuando existe una necesidad respaldada y una función diferenciada.
El brief puede llevar a actualizar, combinar, redirigir, rechazar o crear.
Los nueve campos conectan propósito, prueba, resultado, formato y ciclo de vida.
La acción deseada puede ser comprender, comparar, decidir, encontrar o continuar una tarea.
El brief ordena decisiones, pero no reemplaza investigación, accesibilidad, verificación ni revisión especializada.
¿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 prueba necesaria, el resultado esperado y la responsabilidad futura antes de aceptar una solución. Si el trabajo comienza desde un título o formato ya escogido, quien redacta termina infiriendo para quién escribe, qué duda resuelve y cómo se relaciona la pieza con el resto del sitio. El borrador puede quedar correcto en estilo y, aun así, carecer de una razón coherente para existir.
La ficha de nueve campos es una síntesis editorial reutilizable, no una norma oficial. Combina principios de necesidad del usuario, planificación previa y gobernanza del ciclo de vida presentes en las fuentes. Su valor está en dejar condiciones contra las cuales revisar el borrador posterior. No sustituye descubrimiento, investigación con usuarios, evaluación de accesibilidad, chequeo de hechos, análisis técnico ni la aprobación de especialistas cuando corresponda.
Plantilla de brief de propósito de página
Campo
Pregunta breve
Criterio para aprobar
Audiencia prevista
¿Quién necesita esto y en qué situación?
La descripción identifica una tarea, contexto o nivel de conocimiento relevante.
Pregunta del usuario
¿Qué pregunta o tarea respaldada debe resolver?
La formulación usa lenguaje reconocible y cuenta con evidencia.
Función de la página
¿Qué trabajo único cumple en el recorrido?
No existe otra página, herramienta o canal que lo cumpla mejor.
Mensaje clave
¿Qué conclusión debe llevarse la audiencia?
La idea principal puede presentarse antes que el detalle de apoyo.
Evidencia requerida
¿Qué demuestra la necesidad y qué sustenta las afirmaciones?
Se identifican fuentes, registros, datos o verificaciones responsables.
Acción deseada
¿Qué podrá decidir, hacer o encontrar la persona?
El resultado es significativo y puede evaluarse después.
Formato
¿Qué forma sirve mejor a la necesidad y al recorrido?
La elección se justifica por la tarea, no por preferencia interna.
Responsable
¿Quién responde por exactitud y mantención?
Hay una persona o equipo accountable y roles de apoyo separados.
Fecha de revisión
¿Cuándo y por qué se revisará?
Constan un próximo hito y, cuando sea posible, su gatillante.
¿Qué debe revisar el equipo antes de aprobar otra página?
El equipo debe revisar el sitio, el recorrido y los canales relacionados para saber si la necesidad ya tiene una respuesta o si otro componente podría resolverla mejor. Busca páginas, documentos, herramientas, formularios, transacciones y rutas de atención que cubran la misma pregunta o desempeñen la función propuesta. La guía de GOV.UK recomienda hacer esta revisión temprano, detectar material actualizable, duplicaciones y vacíos, y eliminar repetición innecesaria antes de sumar contenido.
La revisión no es un concurso para reducir páginas a cualquier costo. Dos piezas similares pueden confundir respecto de cuál es la fuente autorizada, pero una instrucción breve repetida en el punto exacto de una transacción puede ayudar a completar la tarea. La decisión debe considerar propiedad, contexto y recorrido, no solo coincidencias entre palabras. Registra una de estas cinco salidas y la razón que la respalda:
Actualizar una página que ya es dueña de la necesidad y la función.
Combinar fragmentos que compiten por entregar una misma respuesta.
Redirigir o retirar una pieza obsoleta cuando otra se vuelve la fuente autorizada.
Rechazar la solicitud si no hay evidencia de necesidad o una función diferenciada.
Crear solo cuando necesidad, evidencia, resultado, formato, responsable y revisión forman una propuesta coherente.
No encargues al redactor producir una página; pídele a la organización justificar el trabajo que esa página debe cumplir.
¿Cómo se definen la audiencia prevista y la pregunta del usuario?
La audiencia se define mediante la tarea, situación o conocimiento que cambia lo que la página debe hacer; la pregunta expresa la necesidad central en palabras que esas personas reconocerían. “Todos los clientes” es demasiado amplio si administradores, compradores y usuarios finales llegan con decisiones distintas. Tampoco es obligatorio limitarse a un segmento rígido o a una sola frase literal: una pregunta central puede incorporar subpreguntas estrechamente conectadas, siempre que el conjunto siga siendo coherente y abordable.
La evidencia puede venir de analítica, consultas al centro de atención, búsquedas internas, entrevistas, estudios anteriores o datos externos pertinentes. Cada fuente responde algo diferente: un volumen de visitas muestra actividad, pero no demuestra por sí solo la intención ni la calidad de la respuesta. Contrasta señales y valida los supuestos relevantes. Una preferencia del stakeholder, un título de trabajo o una solicitud de video describen una solución imaginada; no prueban que exista la necesidad.
Describe a las personas según la situación que modifica el contenido.
Formula la pregunta como una necesidad reconocible, no como el nombre de una página.
Anota la evidencia disponible, sus vacíos y las suposiciones pendientes de validar.
¿Cómo se conectan función, mensaje clave y evidencia requerida?
Los tres campos se conectan al definir, respectivamente, el trabajo exclusivo de la página, la conclusión que debe quedar clara y la prueba necesaria para sostenerla. Escribe la función como un aporte al recorrido, no como una categoría genérica: “aclarar requisitos antes de configurar” resulta más útil que “informar”. Después explica por qué una página existente, una herramienta, una transacción o un canal de soporte no puede realizar mejor ese mismo trabajo.
El mensaje clave debe condensar la idea que la audiencia necesita para avanzar. La guía de estilo de Canadá recomienda presentar primero la información más importante para la tarea y descartar detalle que no ayude a completarla. La evidencia requerida tiene dos capas: señales que demuestran que la necesidad existe y fuentes que respaldarán las afirmaciones publicadas, como documentación vigente, registros, datos, demostraciones o validación de un especialista responsable.
En un recorrido B2B, una explicación de soporte podría aclarar requisitos antes de que un administrador ingrese a una herramienta de configuración. La página prepara y orienta; la herramienta ejecuta el cambio. Una vez publicada, comprueba que el título, el encabezado principal y la apertura expresen el propósito acordado. WCAG 2.4.2 exige que el título describa el tema o propósito, aunque esa comprobación aislada no acredita la accesibilidad completa de la experiencia.
¿Cómo debe la acción deseada determinar el formato?
La acción deseada debe nombrar lo que la audiencia podrá decidir, hacer, entender, comparar, ubicar o alcanzar a continuación; el formato se selecciona después para facilitar ese resultado. Trátala como una condición práctica de aceptación y no como sinónimo de venta, lead o envío de formulario. Por ejemplo, una persona puede necesitar determinar si cumple los requisitos, comparar alternativas con criterios pertinentes o llegar al punto correcto de una tarea sin ejecutar todavía una conversión comercial.
Con la necesidad, la función y el resultado claros, compara formatos como guía, referencia, explicación, tabla comparativa, video, herramienta o paso transaccional. La planificación de GOV.UK vincula el tipo y la ubicación del contenido con el conocimiento de la audiencia, su tarea y la forma de completarla. Las fuentes respaldan ese principio, pero no entregan una taxonomía universal para sitios empresariales. Si una mejora transaccional o un canal no web resuelve mejor el problema, déjalo registrado.
Elige guía cuando la persona necesita comprender o prepararse.
Usa comparación o referencia cuando debe contrastar o consultar información estable.
Prefiere herramienta o interacción cuando el trabajo requiere calcular, enrutar, configurar o completar una operación.
Justifica el video u otro formato rico por la tarea y sus condiciones de acceso, no por novedad.
¿Quién debe hacerse cargo de la página y cuándo revisarla?
La página debe tener una persona o equipo accountable por su exactitud y mantención, junto con una fecha de revisión definida según cambios previsibles y riesgo. Ser responsable no significa absorber todas las tareas. Registra por separado a quienes aportan contenido, verifican materias especializadas, aprueban, evalúan accesibilidad o implementan aspectos técnicos. Digital.gov trata propiedad, verificación temática y aprobaciones como partes distintas de un ciclo que incluye creación, actualización, mantención y retiro.
Define el próximo control considerando lanzamientos de producto, cambios de proceso, vencimiento de evidencia, volatilidad de los datos, exposición al riesgo y compromisos editoriales. No impongas una revisión trimestral o anual a todas las páginas. Cuando sea práctico, anota tanto la fecha como su gatillante: así el equipo entiende por qué existe el hito. Los registros pueden revelar revisiones vencidas y apoyar decisiones de corregir, actualizar, consolidar, redirigir o retirar, pero el calendario por sí solo no garantiza mantención.
¿Cómo se ve un brief de nueve campos completo y aprobable?
Un brief completo muestra una decisión coherente y permite detectar qué supuesto todavía impide encargar el borrador. Este ejemplo hipotético corresponde a una página de soporte B2B para preparar una integración. No atribuye resultados de tráfico, conversión, término de tareas ni ahorro; un equipo real tendría que reemplazar sus supuestos por evidencia del producto, las personas usuarias y el recorrido correspondiente.
Audiencia prevista: administradores de clientes que se preparan para configurar una integración compatible.
Pregunta del usuario: “¿Qué debo confirmar antes de comenzar la configuración?”.
Función de la página: explicar prerrequisitos antes de ingresar a la herramienta de configuración.
Mensaje clave: confirmar accesos, compatibilidad y registros requeridos antes de empezar.
Evidencia requerida: documentación vigente, registros de soporte y verificación del especialista de producto responsable.
Acción deseada: decidir si la organización está preparada y avanzar a la herramienta o ruta de soporte correcta.
Formato: guía concisa con una lista de prerrequisitos.
Responsable: equipo de contenidos de soporte, con revisores de producto y accesibilidad identificados.
Fecha de revisión: próximo control programado, asociado a un gatillante documentado de lanzamiento de producto.
Antes de aprobar, exige que los stakeholders puedan señalar la evidencia de la audiencia y la pregunta, explicar la decisión elegida y la función diferenciada, formular el mensaje y la prueba necesaria, describir un resultado significativo, justificar el formato, nombrar al responsable y comprometer una fecha con su gatillante. Si una respuesta material sigue sin respaldo o contradice otra parte del brief, devuelve la solicitud a investigación o ajuste. Solo entonces asigna la redacción.
El dueño del contenido coordina el compromiso de ciclo de vida, pero no reemplaza el juicio profesional. Incorpora especialistas de accesibilidad, asuntos legales o regulatorios, tecnología, datos o materia temática cuando las afirmaciones y decisiones de implementación lo requieran. La aprobación final debe mostrar que necesidad, decisión, nueve campos y mantención futura sostienen una misma propuesta; completar casillas sin resolver sus tensiones no constituye una autorización editorial suficiente.
Preguntas frecuentes sobre briefs de contenido web
¿Qué es un brief de propósito de página?
Es un registro interno y conciso que define por qué se propone una página antes de redactarla. Alinea audiencia, pregunta, función, mensaje, evidencia, resultado, formato, responsable y revisión. También deja constancia de si corresponde actualizar, combinar, redirigir, rechazar o crear.
¿Qué debe incluir un brief de contenido para un sitio web?
Puede incluir 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. Esta plantilla es una síntesis editorial práctica, no un estándar universal. Cada campo debe contener una respuesta verificable y coherente con el recorrido.
¿Cómo se prepara un brief de contenido web antes de escribir?
Primero revisa el sitio y los canales existentes, luego valida la necesidad y completa los nueve campos. Con esa información, elige entre actualizar, combinar, redirigir, rechazar o crear. Aprueba el registro solo cuando la evidencia, la función, el resultado, el formato y la responsabilidad no se contradigan.
¿Cada necesidad del usuario requiere una página nueva?
No. Una página existente, una combinación de contenidos, una redirección, una mejora transaccional, una herramienta o un canal no web pueden resolver mejor la necesidad. También corresponde rechazar la solicitud cuando no existe evidencia suficiente o una función diferenciada.
¿Cada cuánto tiempo se debe revisar el contenido de un sitio web?
No existe un intervalo único apropiado para todas las páginas. El próximo control debe considerar cambios conocidos, volatilidad, riesgo, vigencia de la evidencia y compromisos de publicación. Conviene registrar una fecha y su gatillante para que el equipo comprenda cuándo adelantar la revisión.
Referencias y fuentes
Este artículo se investigó utilizando las siguientes fuentes:
Cubrimos las decisiones que moldean un sitio web mucho después del lanzamiento. Partimos de fuentes identificadas, distinguimos lo que encontramos de lo que pensamos y usamos IA como apoyo para investigar y redactar, bajo estándares editoriales documentados. Declaramos toda relación comercial.
Método neutral para comparar CMS con escenarios de publicación propios, fallas previstas, evidencia observable, esfuerzo real y dependencias operativas.