Respuesta breve
Un buen briefing fija el alcance, no el gusto. Esto es lo que debe contener: las cinco respuestas previas a cualquier presupuesto, por qué la lista de páginas manda en la estimación y quién responde de los textos y las traducciones.
Para qué sirve un briefing y qué no es
Un briefing existe para fijar el alcance. Es el documento que convierte una conversación sobre una web en una lista que un proveedor puede presupuestar, planificar y contra la que después se le puede medir. Todo lo que un briefing hace bien lo hace a través de esas tres cosas.
Ese trabajo es distinto de describir el gusto. Un enlace a una web que admira indica el registro visual que busca, pero no dice cuántas páginas hay, quién escribe los textos ni a qué sistema debe llegar una solicitud del formulario. El gusto cabe en un briefing, pero no puede sostenerlo.
La prueba es sencilla. Entregue el documento a alguien que no le conozca y pídale que nombre el número de páginas, la fecha de lanzamiento y la persona responsable de los textos. Si no puede, todavía tiene una lista de deseos.
Lo que sigue es la forma de un briefing que supera esa prueba, sección por sección, señalando los puntos que los propietarios suelen dejar en blanco. Termina con la manera en que el documento acabado encaja en paquetes que ya llevan precios y plazos fijados.
La versión de una página: cinco respuestas antes de cualquier presupuesto
Antes de cualquier detalle hay cinco respuestas que deciden si un presupuesto es siquiera posible: para qué sirve la web, cuántas páginas tiene, quién aporta el contenido, qué debe conectarse a ella y cuándo tiene que estar en línea. Un proveedor con esas cinco puede poner una cifra.
Todo lo demás del briefing es desarrollo de esos cinco puntos. Si va justo de tiempo, escriba una sola página que contenga únicamente eso y envíela. Una página que responde a las cinco obtiene un presupuesto más firme que veinte páginas que responden a tres.
El orden también cuenta. El propósito selecciona la lista de páginas, la lista de páginas selecciona la carga de contenido, y la carga de contenido suele fijar el plazo real. Empezar por el diseño invierte esa cadena y produce una estimación que se mueve cada semana.
Trate la versión de una página como un borrador que se queda. El briefing largo no la sustituye: son las mismas cinco respuestas con el detalle añadido, y la versión corta sigue siendo el resumen que todos pueden retener en la cabeza.
Propósito: nombre la única acción que la web debe producir
Escriba la acción que quiere que realice un visitante. Una reserva, una llamada, un formulario enviado, un pedido completado, un archivo descargado. Una web puede admitir varias, pero un briefing que nombra una da a cada decisión posterior un criterio de desempate.
Esa es la frase que resuelve las discusiones sobre maquetación. Cuando dos personas discrepan sobre si el precio va encima o debajo de la descripción, la acción nombrada lo decide, y la conversación dura un minuto en lugar de una semana.
También indica qué medir. Si la acción es un formulario enviado, los envíos son la cifra que importa y el tráfico pasa a ser contexto en lugar de resultado. Nombrarla en el briefing da a la analítica algo concreto que registrar.
Escríbalo en lenguaje llano y colóquelo al principio. «Un visitante debe poder ver precios y enviar una solicitud sin llamarnos» es un propósito utilizable. «Aumentar el reconocimiento de marca» no lo es, porque de ahí no se deduce nada para una construcción.
La lista de páginas es la columna vertebral de toda estimación
Enumere las páginas. Inicio, servicios, sobre nosotros, contacto y después las suyas propias: un catálogo, un flujo de reserva, un portafolio, unas páginas legales. Cuéntelas y marque cuáles repiten una plantilla y cuáles son únicas.
La distinción entre plantilla y página única es donde se gana o se pierde una estimación. Cuarenta fichas de catálogo sobre una plantilla es un trabajo menor que cuatro páginas con maquetación propia cada una, y solo la lista lo hace visible.
Añada a cada página una línea sobre lo que debe contener. No el texto, sino los bloques. «Página de servicio: descripción, precio, qué incluye, qué no incluye, formulario de solicitud». Esa línea basta al proveedor para ver el trabajo y a usted para notar un bloque ausente.
Marque las páginas sin las que puede lanzar. Un briefing que separa el conjunto de lanzamiento del posterior le da una palanca que va a necesitar: cuando la fecha peligra, lo que se mueve es la segunda lista y no hay que renegociar nada.
Contenido: quién escribe, quién traduce y para qué fecha
El contenido es la parte de un proyecto web que más se retrasa y la que más a menudo se deja en blanco en el briefing. Escriba quién produce el texto de cada página, quién aporta las fotografías y la fecha de entrega de cada cosa.
Nombre personas, no departamentos. «Marketing enviará los textos» no tiene responsable; «Ana envía las descripciones de servicio antes del día 12» sí lo tiene. No es burocracia: la ausencia de responsable es invisible justo hasta la semana en que hace falta el texto.
Diga explícitamente si hacen falta traducciones y quién las produce. VITON13 no redacta el contenido del cliente ni sus traducciones — eso queda de su lado, y callarlo en la fase de briefing es lo que convierte una construcción de cinco días en una espera de cinco semanas.
Si el contenido aún no existe, dígalo y ponga una fecha. Un proveedor puede construir sobre textos provisionales y sustituirlos después, pero solo si el plan dice que eso es lo que ocurre. Descubrirlo en la entrega es otra conversación, y peor.
Diseño: qué existe ya y qué hay que producir
Separe lo que tiene de lo que necesita. Un logotipo, una paleta, una licencia tipográfica, fotografías, un manual de marca: enumere qué existe y dónde están los archivos. Todo lo que no esté en esa lista habrá que producirlo, y producir lleva tiempo.
Si tiene manual de marca, diga qué partes son vinculantes. Unos son estrictos con el color y la tipografía y flexibles con la maquetación; otros al revés. Un proveedor que sabe qué reglas no se doblan deja de adivinar y deja de preguntar.
Aquí sirven dos o tres referencias con una frase sobre qué quiere de cada una. «Esta por cómo presenta el precio» vale más que un enlace suelto, porque separa la parte que admira de las que no.
Diga también qué no debe ocurrir. Un color que pertenece a un competidor, la maquetación de su web anterior, un estilo fotográfico inadecuado para su mercado. Las restricciones dichas pronto cuestan menos que las correcciones hechas tarde.
Funciones: pase cada una por una sola frase
Para cada función que quiera, escriba una frase: quién hace qué y qué ocurre después. «Un visitante elige fecha y hora, envía el formulario y la solicitud aparece en nuestro correo y en el CRM». Esa frase es la especificación.
La prueba de la frase filtra funciones que suenan simples y no lo son. «Reserva en línea» esconde la pregunta de si el calendario debe conocer las citas ya ocupadas; la versión en frase la saca a la luz antes de que nadie la presupueste.
Ordene la lista entre lo que exige el lanzamiento y lo que puede ir después. Casi todo proyecto tiene funciones que parecen imprescindibles en una reunión y pasan cómodamente a una segunda fase cuando la fecha se vuelve real. Decidirlo en el briefing cuesta menos que decidirlo bajo presión.
Sea concreto con las aplicaciones móviles nativas si está imaginando una. Una web adaptable y una aplicación en una tienda son productos distintos con trabajos distintos; los paquetes de desarrollo de VITON13 cubren la construcción web, y las aplicaciones móviles nativas figuran como no incluidas.
Integraciones: nombre los sistemas y a quién pertenecen las cuentas
Enumere cada sistema externo con el que la web debe hablar: un CRM, una pasarela de pago, una plataforma de analítica, una herramienta de correo, un sistema de reservas, una empresa de reparto. Nombre el producto, no la categoría: dos CRM con la misma función pueden diferir en una semana de trabajo.
De cada uno, diga quién posee la cuenta y quién puede conceder acceso. Una integración no se construye contra un sistema en el que nadie puede entrar, y esperar una contraseña es una de las formas más silenciosas de perder un plazo.
Diga qué tiene que moverse en cada dirección. Un formulario que envía un contacto al CRM es un trabajo; un catálogo que lee existencias reales de un sistema contable y le devuelve pedidos es otro. La dirección de los datos es la mayor parte de la estimación.
El pago merece su propia línea. Qué proveedor, qué país, qué entidad firma el contrato y quién responde de las licencias. El paquete Desarrollo de producto de VITON13 señala las licencias de pago como fuera de su alcance, así que conviene cerrar ese punto en el briefing.
Restricciones: fecha, banda de presupuesto y lo que no puede cambiar
Indique la fecha y diga a qué está atada. Una feria, una temporada, una campaña, un alquiler. Un proveedor que sabe que la fecha es inamovible planifica de otra manera que quien la toma por una preferencia, y la diferencia se nota en lo que propone.
Dé una banda de presupuesto en lugar de una cifra única o de nada. Una banda permite decirle con honestidad cuáles de sus requisitos caben dentro, lo que es una respuesta más útil que un presupuesto ajustado a una cifra que nunca quiso gastar.
Enumere la tecnología que debe conservar. Un CMS existente, un contrato de alojamiento con tiempo por delante, un acuerdo sobre el dominio, un sistema contable que este año no se sustituye. Son hechos neutros y cambian la estimación los mencione o no.
Añada los requisitos legales que ya conozca: un aviso de privacidad, la gestión de cookies, un estándar de accesibilidad que su sector espera. Para lo último, la referencia rápida de WCAG 2.2 del W3C es la lista práctica, y conviene nombrarla en lugar de darla por supuesta.
Aceptación: escriba de antemano cómo sabrá que está terminado
Un briefing que describe el trabajo pero no la línea de meta deja indefinido el final del proyecto. Escriba las condiciones de aceptación mientras está tranquilo: qué abrirá, qué pulsará y qué debe ser cierto antes de firmar.
Manténgalas concretas. Cada página carga en móvil y en escritorio; la solicitud llega al correo y al CRM; el precio mostrado coincide con la lista de precios; la web responde en la dirección correcta por HTTPS. Cada punto es un sí o un no.
Incluya las medibles que de verdad le importan. La velocidad es un buen ejemplo, porque la documentación de rendimiento de MDN da un vocabulario compartido para hablar de ella, y «la portada debe ser rápida» no es una condición que nadie pueda aprobar o suspender.
Nombre a quien firma. Una persona y un plazo declarado para hacer las comprobaciones. Una aceptación con tres revisores y sin fecha límite es el mecanismo por el cual un proyecto terminado sigue abierto un mes más.
Qué no debe contener un briefing
No debe contener decisiones de implementación para las que no tenga un motivo. Nombrar un framework porque leyó algo sobre él restringe la construcción sin mejorarla. Formule el requisito — una página que pueda editar cualquiera en la oficina — y deje que el proveedor lo responda.
No debe contener cifras inventadas. Un dato de tráfico imaginado o un objetivo de conversión especulativo fijan una expectativa contra la que se medirá el trabajo, y esa medición no será justa para nadie.
No debe contener requisitos sin dueño. Cada línea que dice que la web «debería» hacer algo necesita una persona detrás, o sobrevivirá a todas las revisiones y se descubrirá ausente en la aceptación.
Y no debe ser largo por serlo. El documento existe para quienes presupuestan y construyen. Seis páginas claras valen más que treinta que entierran la lista de páginas en medio de un relato de estrategia.
Cómo encaja el briefing terminado en paquetes cerrados
Un briefing merece escribirse, entre otras cosas, porque permite comparar ofertas sobre la misma base. El servicio de desarrollo de VITON13 tiene cinco paquetes con precio, y una vez que existen su lista de páginas y su plan de contenido, el briefing suele elegir uno solo.
Site Fix Pack cuesta $70 y ocupa 1-2 días laborables para un máximo de cinco correcciones acordadas, con revisión en móvil y escritorio y una lista de antes/después en la entrega; lleva una ronda de revisiones y no cubre páginas nuevas, rediseño ni migraciones. Sitio para lanzamiento son $380 en 3-5 días laborables por una construcción adaptable, conexión del CMS o de los datos básicos y configuración del despliegue, con dos rondas de revisiones antes del lanzamiento y con el contenido y las traducciones aportados por usted.
Desarrollo de producto son $880 en 2-3 semanas y cubre la entrega de funcionalidades, la lógica de estados y rutas, las pruebas y el endurecimiento, con dos rondas de revisiones por funcionalidad entregada; las aplicaciones móviles nativas y las licencias de pago quedan fuera. Launch Site Express son $520 y entrega el alcance de Sitio para lanzamiento en cola prioritaria en 2 días laborables con compilaciones diarias, una lista de comprobación de lanzamiento y una llamada de entrega, una ronda de revisiones tras la primera construcción completa, y sin contenido, fotografía ni soporte posterior.
Soporte técnico continuo son $290 al mes en ciclo mensual con 30 días de preaviso para detenerlo, e incluye actualizaciones prioritarias, un ritmo semanal de publicaciones y mantenimiento técnico; el volumen se acuerda al inicio de cada ciclo y una construcción nueva o un rediseño se presupuestan aparte. Lea las condiciones del paquete que realmente está eligiendo: se diferencian entre sí a propósito.
Lista práctica
- Escriba la versión de una página con las cinco respuestas y envíela antes del documento largo.
- Enumere todas las páginas y marque cada una como repetición de plantilla o maquetación única.
- Nombre una persona y una fecha para textos, fotografía y traducciones.
- Pase cada función solicitada por la prueba de la frase: quién hace qué y qué ocurre después.
- Nombre cada sistema externo por producto e indique quién posee su cuenta.
- Escriba las condiciones de aceptación y nombre a la única persona que firma.
Preguntas frecuentes
¿Hace falta un briefing si la web es pequeña?
Sí, pero corto. Para una web pequeña basta una página con cinco respuestas: para qué sirve, cuántas páginas tiene, quién aporta el contenido, con qué debe conectarse y cuándo se publica. Eso convierte una horquilla en un presupuesto firme.
¿Cuánto cuesta el desarrollo y cómo influye el briefing?
VITON13 tiene cinco paquetes con precio: Site Fix Pack por $70 en 1-2 días laborables para un máximo de cinco correcciones acordadas, Sitio para lanzamiento por $380 en 3-5 días laborables, Launch Site Express por $520 en 2 días laborables, Desarrollo de producto por $880 en 2-3 semanas y Soporte técnico continuo por $290 al mes. El briefing no cambia el precio del paquete; muestra a qué paquete pertenece el trabajo.
¿Quién escribe los textos, el cliente o el proveedor?
El contenido y las traducciones quedan del lado del cliente: VITON13 no los redacta ni los traduce. Por eso el briefing necesita una persona con nombre y una fecha para los textos de cada página; si no, el plazo lo acaba fijando la espera del material y no la construcción.
¿Conviene nombrar un framework concreto en el briefing?
Solo si tiene un motivo: un sistema existente que debe conservar o un equipo que mantendrá la web después. Sin ese motivo, formule el requisito — por ejemplo, una página que pueda editar cualquiera en la oficina — y deje que el proveedor lo resuelva.
¿Y si el contenido todavía no existe?
Dígalo en el briefing y ponga una fecha. Se puede construir sobre textos provisionales y sustituirlos después, pero eso debe ser el plan y no un hallazgo en la entrega. Marque también qué páginas pueden quedar fuera del primer día.