Briefing para una web a medida: qué definir antes de pedir presupuesto

21.08.2026 · Lectura: 7–9 min

Un buen briefing para una web a medida no necesita describir la solución técnica: debe explicar qué problema de negocio hay que resolver, para quién, con qué contenidos, procesos y límites. Si varias agencias reciben la misma información concreta, sus propuestas se pueden comparar. Si cada una interpreta una idea distinta, los presupuestos solo comparten el título y cualquier diferencia de precio resulta engañosa.

Antes de pedir presupuesto, una empresa debería poder resumir el objetivo principal, los usuarios prioritarios, las acciones que espera de ellos, las funciones imprescindibles, los sistemas que deben conectarse, quién aportará los contenidos y cómo se aceptará el resultado. Lo desconocido también debe quedar escrito: una duda visible se puede investigar y estimar; una suposición oculta suele aparecer como coste o retraso durante el desarrollo.

Empieza por la decisión que debe mejorar la web

«Necesitamos una web moderna» describe una preferencia, no un resultado. Es más útil indicar qué debería cambiar: recibir solicitudes mejor calificadas, vender un catálogo concreto, reducir consultas repetitivas, permitir reservas, presentar proyectos a compradores internacionales o sustituir un proceso que hoy depende de hojas de cálculo y correos.

El briefing debería elegir un objetivo principal y varios indicadores observables. No hace falta prometer cifras sin base. Puede definirse, por ejemplo, que un visitante encuentre una determinada información en pocos pasos, que el equipo reciba una solicitud con los datos necesarios o que un pedido llegue al sistema interno sin volver a introducirlo. Así, diseño y desarrollo se evalúan por su utilidad, no solo por una captura atractiva.

Describe usuarios y recorridos, no una lista infinita de páginas

Una arquitectura inicial ayuda, pero el número de páginas no explica por sí solo la complejidad. Una página de contacto sencilla y un configurador con reglas comerciales pueden ocupar una línea cada uno y exigir esfuerzos muy distintos. Para cada grupo de usuarios conviene describir qué sabe al llegar, qué busca, qué dudas puede tener y qué acción debería completar.

• Cliente potencial: compara alternativas, necesita entender el servicio y decidir si contacta.
• Cliente actual: busca documentación, soporte, pedidos o acceso a un área privada.
• Equipo interno: publica contenidos, responde solicitudes, actualiza productos o consulta datos.
• Socios o distribuidores: pueden necesitar materiales, tarifas, solicitudes o flujos distintos.

Esos recorridos permiten decidir qué contenido merece una URL propia, qué información debe estar enlazada y qué funciones necesitan estados, permisos o notificaciones. Google recomienda que el contenido importante sea accesible mediante enlaces rastreables, utilice HTML semántico y tenga títulos y descripciones representativos. Por eso la estructura de navegación y el SEO técnico deben formar parte del alcance, no añadirse cuando la web ya está cerrada.

Separa imprescindible, deseable y futuro

Un briefing útil distingue tres niveles. Lo imprescindible define la primera versión que puede cumplir el objetivo. Lo deseable aporta valor, pero puede aplazarse si compromete presupuesto o fecha. El futuro recoge ideas que afectan a la arquitectura —por ejemplo, nuevos idiomas, un área privada o más países— aunque no se desarrollen ahora.

Esta separación evita dos extremos: presupuestar desde el principio todas las posibilidades imaginables o construir una primera versión tan rígida que cualquier evolución obligue a rehacerla. También permite pedir variantes comparables: una propuesta base y módulos opcionales con dependencias explícitas.

Inventaría contenidos, datos e integraciones

La frase «los textos y las fotos los aportaremos nosotros» necesita una fecha, un responsable y un formato. Conviene inventariar textos, traducciones, fotografías, vídeos, fichas, documentos descargables y datos que deben migrarse. También hay que aclarar quién revisa cada pieza y qué ocurrirá si no está lista durante el desarrollo.

Las integraciones merecen una ficha propia: nombre del sistema, proveedor, documentación disponible, responsable técnico, datos que entran y salen, frecuencia, permisos, entorno de pruebas y comportamiento esperado cuando algo falla. Un CRM, un ERP o una pasarela de pago no se estima con rigor solo por su nombre. Dos cuentas del mismo servicio pueden tener planes, API y reglas distintas.

Si la web tratará datos personales, el briefing debe identificar categorías de datos, finalidades, personas usuarias, destinatarios y necesidades de conservación desde el principio. La guía de privacidad desde el diseño de la AEPD plantea integrar la protección durante el ciclo de vida, no colocarla como revisión final. Las bases jurídicas, los textos definitivos y las decisiones propias de cada negocio deben validarse con su responsable o asesor.

Define requisitos no funcionales que sí cambian el proyecto

Hay condiciones que el visitante no ve como una función independiente, pero determinan la calidad y el coste. Deben figurar en el briefing con un criterio comprobable:

• dispositivos, navegadores y resoluciones prioritarios;
• idiomas, países y responsables de traducción;
• nivel de accesibilidad previsto y método de evaluación;
• objetivos de rendimiento y páginas críticas;
• roles, permisos, registro de cambios y recuperación de acceso;
• copias de seguridad, restauración y continuidad;
• analítica, consentimiento y eventos que se medirán;
• entornos de desarrollo, pruebas y producción.

W3C recomienda fijar objetivos, responsabilidades, recursos y controles de accesibilidad desde la planificación, además de evaluar pronto y de forma periódica. Incluirlo en la aceptación evita que «accesible» signifique cosas diferentes para dirección, diseño, desarrollo y proveedor.

Convierte la entrega en criterios de aceptación

«La tienda funciona» es difícil de aceptar o rechazar. Es mejor describir escenarios verificables: un usuario puede comprar desde móvil, recibe una confirmación, el pedido aparece una sola vez en el sistema, un pago rechazado no crea una venta completada y el equipo puede localizar la incidencia sin consultar datos sensibles en varios servicios.

Los criterios deben cubrir el recorrido normal, errores previsibles y permisos. También conviene acordar quién aporta cuentas de prueba, quién valida los contenidos, cuánto dura la revisión, cómo se registran incidencias y qué se considera una corrección frente a una ampliación. Una demostración no sustituye una aceptación documentada.

Qué pedir en cada propuesta

1. Alcance y exclusiones. Qué se entrega y qué no está incluido.
2. Fases y responsables. Qué necesita la agencia y qué debe aportar la empresa en cada momento.
3. Supuestos. Qué parte del precio depende de información aún no confirmada.
4. Entregables. Diseño, código, contenidos, configuraciones, documentación, formación y accesos.
5. Pruebas y aceptación. Qué se comprobará, en qué entorno y con qué evidencias.
6. Publicación y continuidad. Migración, monitorización inicial, garantía de correcciones y soporte posterior.

Comparar propuestas exige revisar estas seis capas, no dividir el precio entre el número de páginas. Una oferta más breve puede esconder tareas a cargo del cliente; otra puede incluir análisis, migración, pruebas e integraciones que la primera ni menciona.

En un proyecto de creación de sitios web, el briefing permite delimitar la solución antes de diseñarla. Los requisitos de visibilidad pueden revisarse con el servicio de SEO, mientras que el soporte técnico ayuda cuando el punto de partida es una web existente. Para una primera valoración, se puede enviar el contexto esencial desde contacto sin incluir contraseñas ni datos sensibles.

Preguntas frecuentes sobre el briefing web y VOWE

¿Puede VOWE ayudar a convertir una idea inicial en un alcance web concreto?

Sí. VOWE puede revisar los objetivos, usuarios, contenidos, funciones, integraciones y condicionantes técnicos para delimitar una primera fase. El resultado depende de la información disponible y puede requerir una sesión de análisis antes de preparar una propuesta.

¿Qué información conviene enviar para una primera valoración?

Basta con indicar la actividad, el objetivo principal, los usuarios, las funciones imprescindibles, los idiomas, las integraciones conocidas, el estado de los contenidos y una fecha objetivo si existe. No hace falta enviar contraseñas, datos personales de clientes ni documentación confidencial mediante el formulario de contacto.

¿El desarrollo web puede incluir SEO, accesibilidad y soporte posterior?

VOWE ofrece creación de sitios web, SEO y soporte técnico. El alcance concreto debe acordarse en la propuesta: conviene especificar desde el briefing qué requisitos se incluirán, cómo se comprobarán antes de publicar y qué tareas quedarán para el mantenimiento posterior.

Una plantilla breve para empezar

El documento inicial puede ocupar dos o tres páginas si responde con claridad a estas preguntas: qué debe mejorar, quién utilizará la web, qué acciones son críticas, qué contenido existe, qué sistemas se conectan, qué restricciones hay, quién decide, qué fecha tiene sentido y cómo se comprobará la entrega. Añade enlaces o anexos para inventarios y procesos complejos.

No es necesario cerrar todas las decisiones antes de hablar con un equipo técnico. El briefing sirve precisamente para separar hechos, prioridades y preguntas. La propuesta será más fiable cuando indique qué puede estimarse ahora, qué necesita descubrimiento y qué decisión corresponde a la empresa.

Fuentes y límites

Esta guía sintetiza la planificación de accesibilidad de W3C WAI, la guía de Google Search Central para desarrolladores web y buscadores y la guía de la AEPD sobre privacidad desde el diseño. Las necesidades concretas dependen del negocio, los usuarios, la tecnología y las obligaciones aplicables. Este contenido es orientación general y no sustituye asesoramiento jurídico individual.