¿Para qué escribir un brief?
No por formalidad ni para cubrirte legalmente. Para que el presupuesto sea una cifra y no una horquilla. Un desarrollador que no ve el alcance incluye el riesgo en el precio, y tú pagas su incertidumbre. No necesitas cuarenta páginas. Un brief largo escrito por alguien que no es del oficio suele empeorar las cosas: fija decisiones que deberían haberse discutido y se salta lo que de verdad determina el coste.
Con ocho puntos basta
- Para qué es la web. Una frase: contactos, ventas, credibilidad, captación de personal. La estructura sale de ahí
- Quién es el cliente y cómo busca. «Dueños de cafeterías que buscan en Google desde el móvil» basta para cambiar la mitad de las decisiones
- Tipos de página, no páginas. Inicio, servicio, proyecto, artículo y contacto son cinco plantillas. Cuarenta páginas sobre seis plantillas cuestan menos que nueve sobre nueve
- Si existe un diseño. Un archivo de Figma listo elimina una fase entera y un 25-40% del coste
- Si existe el contenido. Textos, fotos, datos de productos. Es el motivo número uno por el que los proyectos se retrasan
- Todas las integraciones en una lista: pagos, CRM, reservas, analítica, newsletter, envíos
- Idiomas. Un segundo idioma no es una traducción, sino una estructura duplicada y control de calidad en cada plantilla
- El plazo y qué lo marca. Un lanzamiento, una temporada, una feria: el plan se puede construir en torno a una fecha fija si se conoce desde el principio
Un desarrollador no necesita saber cómo debe verse la web. Necesita saber qué tiene que hacer y para quién. Lo primero es su trabajo; lo segundo, el tuyo.
Qué no escribir
- Tecnologías concretas, salvo que tengas un motivo. «Hazlo en React» sin motivo reduce las opciones y a veces duplica el precio
- Colores y tipografías. Son el resultado del diseño, no un punto de partida
- Palabras como «moderno», «premium», «como Apple». Cámbialas por un enlace a una web que te guste y una frase sobre por qué
- Cuarenta funciones «para más adelante». Todo lo que no hace falta en el lanzamiento lo retrasa y lo encarece
- Instrucciones sobre cómo construirla. Di qué resultado necesitas; el cómo es justo lo que estás pagando
Las tres preguntas que más ahorran
Háztelas antes de enviar nada. Cada una mueve el presupuesto más que cualquier preferencia de diseño. ¿Quién cambiará los textos de la web después del lanzamiento: tú o un desarrollador? ¿Habrá usuarios que inicien sesión y hagan cosas? ¿Y cuántos tipos de página realmente distintos hay, contados con honestidad?
Qué pedir a cambio
- Un presupuesto desglosado por fases, no un total único
- Un calendario con dependencias: «diseño para el día 14, siempre que los textos lleguen antes del 7»
- Una lista de exclusiones. Un presupuesto se define tanto por ellas como por su total
- Quién es dueño del dominio, el hosting y el código después de la entrega
- Qué pasa con los cambios después del lanzamiento y cuánto cuestan
Conclusión
Un buen brief cabe en una página. Responde a para qué, para quién, qué tiene que funcionar y para cuándo, y no dice nada sobre el cómo. Si después de leerlo un desarrollador sigue dándote una horquilla del doble, el problema no es el brief: o no ha entendido el encargo o está metiendo en el precio un riesgo que no ha mencionado. Las dos cosas conviene hablarlas antes de firmar.