La mayoría de proyectos web que se complican no lo hacen por problemas técnicos, sino porque nadie dejó claro desde el principio qué había que construir y para qué. Un briefing bien preparado es el documento más rentable de todo el proyecto: cuesta unas horas y puede ahorrar semanas.
Qué es un briefing (y qué no es)
Un briefing es un documento breve que explica qué necesita tu negocio, no cómo debe hacerse técnicamente. No hace falta saber de programación para escribirlo. De hecho, cuanto más se centre en objetivos y menos en soluciones concretas, más útil será para quien tenga que construirlo.
Lo que no es: una lista de funcionalidades copiadas de la web de la competencia, ni una descripción visual del tipo “quiero algo moderno y limpio”.
Las 6 preguntas que debe responder
- ¿Qué quieres conseguir con la web? Más reservas, más contactos, vender online, reducir llamadas repetitivas… Un objetivo principal, medible si es posible.
- ¿Quién va a usarla? Clientes locales, turistas, empresas, personal interno. Idioma, dispositivo habitual y nivel técnico cambian muchas decisiones.
- ¿Qué tiene que poder hacer un usuario? Consultar información, reservar, pagar, registrarse, descargar documentos. Enuméralo en forma de acciones.
- ¿Qué tiene que poder hacer tu equipo? Editar textos, gestionar reservas, ver pedidos, exportar datos. Esto suele olvidarse y define gran parte del backend.
- ¿Con qué sistemas debe conectarse? Pasarela de pago, CRM, programa de facturación, calendario, herramientas de email marketing.
- ¿Qué plazos y presupuesto manejas? Aunque sea un rango orientativo. Sin esa referencia, cualquier propuesta será un tiro al aire.
Lo que ayuda mucho (y casi nadie incluye)
- Ejemplos de webs que te gustan, y por qué. No para copiarlas, sino para entender tus preferencias. “Me gusta lo rápido que se reserva en esta” dice mucho más que “me gusta esta”.
- Qué no funciona de tu web actual. Si ya tienes una, sus problemas son la mejor pista de lo que hay que priorizar.
- Contenido disponible. ¿Tienes textos, fotos profesionales, logotipo en buena calidad? ¿O hay que crearlos? Esto afecta directamente a plazos.
- Quién decide. Si hay varias personas implicadas, conviene saber quién aprueba cada fase para evitar bloqueos.
Errores habituales al preparar un briefing
Definir la solución en lugar del problema. “Necesito una app” es una solución. “Mis clientes me llaman diez veces al día para preguntar disponibilidad” es un problema, y puede que la mejor solución sea otra más sencilla.
Pedir todo para la primera versión. Es mejor lanzar lo esencial bien hecho y ampliar después que intentar cubrir todos los casos desde el primer día. Separa lo imprescindible de lo deseable.
Omitir el crecimiento previsto. Si en un año prevés abrir otro local, vender online o trabajar en otro idioma, dilo ahora. Condiciona la arquitectura, y cambiarla después cuesta mucho más.
Un briefing es una conversación, no un contrato
No hace falta que el documento sea perfecto. Su función es arrancar la conversación con una base común. Un buen desarrollador hará preguntas, detectará huecos y propondrá alternativas. Lo importante es que ambas partes empiecen hablando del mismo proyecto.