Brief para sitio web: modelo listo para copiar

Un brief para sitio web es el documento que define qué necesita resolver el proyecto antes de que exista cualquier pantalla. Cubre negocio, público, objetivo, alcance, marca y plazo. Sin él, el proveedor adivina el presupuesto y el cliente descubre a mitad de camino que acordó otra cosa.

Los modelos que circulan en portugués tienen de cinco a dieciocho años, se escribieron para quien desarrolla y no para quien contrata, y ninguno cubre CMS, integraciones ni qué hacer cuando el texto todavía no existe. Abajo está el guion que usamos en la conversación de descubrimiento, organizado en cuatro bloques, listo para que lo copies y lo completes antes de hablar con cualquier proveedor.

¿Qué es un brief de sitio web?

Es la traducción del problema de negocio en requisitos de proyecto. No es una lista de páginas ni una descripción de layout. Es el documento que responde por qué existe el sitio, a quién le habla, qué tiene que pasar después de la visita y cuáles son las restricciones reales de contenido, plazo y presupuesto.

En Wama esto no nace de un formulario, nace de una conversación de descubrimiento. La diferencia importa: el formulario recoge respuestas hechas, la conversación descubre lo que la empresa todavía no ha formulado. Pero la conversación tiene un guion, y ese guion se convirtió en el modelo publicado aquí. Llegar con él completo acorta el descubrimiento y mejora la propuesta que recibes.

¿Por qué el brief decide el presupuesto?

Porque el precio de un proyecto es el costo de tomar decisiones, y el brief es donde empiezan a tomarse. El proveedor que recibe un alcance claro cotiza lo que existe. El proveedor que recibe "quiero un sitio bonito" cotiza el riesgo, y el riesgo siempre es más caro que el trabajo.

Hay una razón técnica conocida para esto. Según el estudio Software Defect Reduction Top 10 List, de Barry Boehm y Victor Basili, publicado en la revista IEEE Computer en enero de 2001, los proyectos de software gastan entre el 40% y el 50% del esfuerzo en retrabajo que se podría haber evitado. Los autores también registran que corregir un problema después de la entrega cuesta mucho más que corregirlo en la fase de requisitos, con un factor cercano a cinco veces en sistemas pequeños y que llega a cien en los grandes.

Un sitio web no es software crítico, así que el número relevante aquí es el menor. Aun así, cinco veces es la diferencia entre ajustar una frase en el brief y rehacer tres páginas con diseño aprobado. Justamente por eso convertir el brief en un presupuesto que no cambie a mitad de camino empieza antes del primer boceto.

El modelo, bloque por bloque

Copia la tabla de abajo y responde con lo que tengas. Una respuesta incompleta es útil; una inventada, no. Donde no sepas, escribe que no sabes: eso también es información para quien va a cotizar.

Son diecisiete respuestas. Un cliente preparado tarda una hora en completarlas, y esa hora suele ahorrar semanas después. Si vas a pedir presupuesto a más de un proveedor, envía exactamente este mismo documento a todos: el mismo brief enviado a tres proveedores es la única forma de comparar propuestas que significan lo mismo.

¿Qué pregunta cambia más el rumbo del proyecto?

Una, y está en el bloque dos: qué tiene que pasar después de que alguien visita el sitio. Es la pregunta que define toda la estructura, porque cada página pasa a existir para conducir a ese resultado, y lo que no conduce sale del alcance.

Cuando la respuesta es "que la persona se ponga en contacto", el sitio se construye para una conversación. Cuando es "que la persona entienda que somos más grandes de lo que parecemos", se construye como prueba. Cuando es "que la persona se postule a una vacante", todo cambia de nuevo. Son sitios distintos con la misma cantidad de páginas, y esa diferencia nace entera de una frase. Sobre cómo esa decisión se traduce en estructura, vale la pena leer la pregunta sobre qué tiene que lograr el sitio.

La segunda pregunta más reveladora está en el bloque uno: por qué un cliente los elige a ustedes y no a la competencia. Una empresa que no sabe responder eso tiene un problema de posicionamiento, no de sitio web, y ningún layout lo resuelve. Mejor descubrirlo en la primera semana que el día de la entrega.

¿Quién lo completa y en cuánto tiempo?

Quien decide, con una persona más como máximo. Un brief completado por comité se vuelve un promedio de opiniones, y un promedio de opiniones produce un sitio genérico. Si varias áreas tienen interés, reúne todo y deja que una persona escriba la versión final, asumiendo las elecciones.

El tiempo es de una hora para quien conoce el negocio, y de semanas para quien necesita alinearse internamente antes. Ese segundo caso es común y no es un problema, siempre que ocurra antes de que empiece el proyecto y no durante. El cronograma de un sitio depende de eso: el cronograma solo empieza a contar cuando el contenido existe.

¿Qué no poner en el brief?

Tres cosas estorban más de lo que ayudan, y todas parecen útiles a primera vista.

1. Descripción de layout. "Menú arriba con cinco ítems y un banner grande" resuelve la pantalla y no el problema. Describe el objetivo y deja la solución a quien contrataste.

2. Lista de funcionalidades copiada de un competidor. Sin saber por qué el competidor lo hizo de esa forma, la lista importa sus errores junto con ella.

3. Presupuesto escondido. Omitir el rango no mejora la propuesta, la atrasa. El proveedor cotiza el alcance que quepa y descubres dos semanas después que no cierra.

Hay un caso especial que vale la pena registrar. A veces el brief revela que lo que se pide no es un sitio web: área con inicio de sesión, panel de datos, reglas de negocio. Ahí, cuando el brief revela que lo que se pide no es un sitio web, cambia toda la conversación: alcance, plazo y rango de precio. Descubrirlo en el documento es barato; descubrirlo a mitad del proyecto, no.

Errores comunes de brief

1. Responder qué debe tener el sitio, no qué debe resolver. Es la confusión más frecuente y la que más produce sitios bonitos e inútiles.

2. Dejar en blanco el bloque de contenido. Quién escribe los textos es la decisión que más mueve precio y plazo, y la que más se deja para después.

3. Referencias sin motivo. Tres enlaces sueltos no dicen nada. Lo que informa es la frase que explica qué te gustó de cada uno.

4. No decir quién aprueba. Un proyecto sin dueño definido acumula rondas y revienta el cronograma sin que nadie note dónde.

5. Confundir plazo con fecha de campaña. La fecha existe, pero tiene que venir con lo que depende de ella; si no, se vuelve presión sin criterio.

El bloque de marca merece atención especial porque es el más subestimado. Un material inconsistente obliga a un retrabajo visual que nadie cotizó, y la discusión sobre qué espera la empresa que cambie después del sitio nuevo suele empezar justo ahí.

Qué pasa después de que entregas el brief

Un proveedor serio devuelve preguntas antes de devolver un precio. Si la primera respuesta a tu brief es un presupuesto cerrado, sin ninguna duda de por medio, desconfía: o el alcance estaba perfecto, lo que es raro, o nadie lo leyó con atención.

Después de las preguntas viene la propuesta, y debería reflejar el brief punto por punto, incluido lo que quedó fuera. Según el informe Pulse of the Profession 2026, del Project Management Institute, el 31% de los proyectos complejos no entrega el alcance de beneficios previsto originalmente. Un alcance escrito por ambas partes es la defensa más barata contra eso.

Ten en cuenta que el brief cambia según el momento de la empresa. Una compañía establecida y una que acaba de levantar inversión responden el bloque dos de formas muy distintas, y cómo cambia el brief según la etapa de la empresa es una lectura útil antes de completarlo.

Preguntas frecuentes

¿Existe un modelo de brief listo para sitio web?

El modelo de este artículo cubre cuatro bloques y diecisiete preguntas, y sirve para sitio institucional, landing page y sitio de producto. Copia la tabla y responde con lo que tengas. Lo importante no es completarlo todo, es registrar lo que todavía no sabes.

¿Quién debe escribir el brief, el cliente o la agencia?

El cliente escribe la primera versión y la agencia la completa con preguntas. Un brief escrito solo por el proveedor se vuelve una suposición sobre un negocio ajeno, porque nadie de afuera conoce la operación. Escrito solo por el cliente, suele faltarle la parte técnica de alcance, integraciones y contenido, que es justamente donde se define el presupuesto.

¿Necesito saber cuánto quiero gastar antes de pedir presupuesto?

Un rango aproximado basta y ayuda mucho. Sin él, el proveedor cotiza el alcance que imagine y la conversación vuelve a empezar de cero cuando aparece el número. Decir el rango no hace subir el precio; hace que la propuesta llegue más cerca de lo que puedes contratar.

¿El brief cambia para una landing page?

Cambia de tamaño, no de estructura. Una landing tiene un objetivo único, así que el bloque dos queda más corto y más preciso. Los bloques de negocio, marca y plazo siguen iguales, porque deciden lo mismo en una página que en veinte.

¿Y si no tengo los textos listos?

Regístralo en el brief en lugar de dejarlo en blanco. Quién escribe el contenido es el punto que más mueve el precio y el plazo de un proyecto de sitio web. Declarar que el texto lo hará el proveedor cambia el presupuesto, pero evita el retraso más común de todos.

Si completaste el modelo y quieres una lectura de lo que revela sobre el proyecto, vale la pena llevar tu brief a una conversación con Wama. El descubrimiento empieza justamente por estas preguntas.