Un briefing para diseño web debe explicar qué problema necesita resolver la empresa, para quién se crea la web y qué debe incluir la primera versión. No es solo una lista de páginas, un conjunto de referencias visuales o una petición de presupuesto.
Si el documento aclara objetivos, usuarios, alcance, contenidos, integraciones y responsables, será más fácil recibir propuestas comparables y tomar decisiones antes de que el proyecto acumule cambios. La estructura de este artículo es una recomendación práctica: no sustituye el análisis del proyecto ni es una plantilla universal.
Plantilla rellenable de briefing para diseño web
Puedes copiar estos campos en un documento compartido y completarlos antes de solicitar propuestas. No hace falta conocer todavía la solución técnica: el objetivo es reunir la información necesaria para analizar alternativas con criterio.
| Campo | Qué conviene completar |
|---|---|
| Situación actual | Indica si se trata de una web nueva, un rediseño, una migración o una ampliación, y describe brevemente el punto de partida. |
| Problema a resolver | Explica qué está ocurriendo ahora y por qué requiere un cambio. |
| Objetivo de la web | Define qué debe facilitar, explicar o mejorar la primera versión. |
| Usuarios principales | Para cada perfil, describe quién es, qué necesita hacer y qué resultado busca. |
| Propuesta de valor | Resume qué debe entender una persona al visitar la web y qué acción debería poder completar. |
| Alcance y prioridad | Separa páginas, contenidos y funciones imprescindibles, deseables y fuera de alcance. |
| Contenidos y materiales | Relaciona textos, imágenes, vídeos, productos, documentos, recursos de marca y contenidos que haya que migrar. |
| Funcionalidades e integraciones | Describe qué debe hacer la web y qué sistemas externos intervienen, si los hay. |
| Diseño y experiencia | Aporta identidad visual, referencias, dispositivos habituales y acciones que deben resultar sencillas. |
| SEO, accesibilidad, privacidad y analítica | Recoge requisitos de migración, rastreo, control de indexación, medición, consentimiento y accesibilidad conocidos. |
| Operación posterior | Indica quién actualizará contenidos, gestionará accesos y atenderá incidencias tras el lanzamiento. |
| Calendario, responsables y presupuesto | Incluye fechas relevantes, personas que deciden y aprueban, dependencias y un rango disponible si existe. |
Qué decisiones debe facilitar un briefing web
El briefing es una base común entre la empresa y quien diseñará o desarrollará la web. Debe conectar una necesidad de negocio con las tareas que tendrán que completar los usuarios, los contenidos necesarios y las condiciones del proyecto.
Conviene describir primero la necesidad y no imponer de entrada una solución. Por ejemplo, «las personas interesadas no encuentran con facilidad qué servicio necesitan» explica un problema; «necesitamos un configurador» propone una posible solución. Puede ser adecuada, pero primero debe justificarse.
Las guías de diseño de servicios de GOV.UK recomiendan comprender el problema de los usuarios y comprobar las suposiciones antes de decidir una solución. Por ello, el briefing debería diferenciar los hechos conocidos, las opiniones internas y las hipótesis que aún deben validarse.
1. Contexto del negocio, problema y objetivos
Empieza por situar el proyecto: qué hace la empresa, qué ofrece, a qué mercado se dirige y en qué punto se encuentra. No es lo mismo crear una web desde cero que rediseñar una existente, migrar contenidos o ampliar una plataforma ya operativa.
Después, formula el problema que se quiere resolver. Algunos ejemplos hipotéticos:
- La oferta actual es difícil de entender y las personas interesadas piden aclaraciones básicas antes de contactar.
- Los contenidos de la web anterior están desactualizados y el equipo no puede modificarlos con facilidad.
- La empresa necesita presentar un servicio nuevo y facilitar solicitudes relacionadas con ese servicio.
Los objetivos deben ser observables y realistas: explicar mejor una oferta, facilitar una solicitud, centralizar información o reducir una consulta repetitiva. No es necesario prometer posiciones, tráfico o ventas para tener un objetivo útil.
Relaciona cada funcionalidad con un objetivo o una necesidad. Si no existe una justificación clara, déjala como una hipótesis o como una posible mejora para una fase posterior.
2. Usuarios, necesidades y propuesta de valor
Una web no se diseña solo para lo que la empresa quiere mostrar. Debe ayudar a perfiles concretos a comprender algo, encontrar información o completar una acción.
Una fórmula práctica para documentarlo es: quién es la persona, qué necesita hacer y para qué resultado. Por ejemplo: «Una responsable de operaciones que evalúa proveedores necesita entender cómo se integraría el servicio con sus sistemas para decidir si solicita una reunión».
La guía de la Office for National Statistics sobre necesidades de usuario propone una estructura equivalente: quién es la persona, qué necesita y qué quiere conseguir. En el briefing, indica además si cada necesidad procede de entrevistas, consultas, analítica, conocimiento interno o una hipótesis pendiente de validar.
Para cada perfil principal, responde:
- ¿Qué debe entender al visitar la web?
- ¿Qué tarea necesita completar?
- ¿Qué dudas, riesgos u objeciones pueden impedir esa acción?
- ¿Qué información necesita antes de contactar, comprar, solicitar una demostración o acceder a un área privada?
3. Alcance, contenidos y prioridades
El alcance evita que una web aparentemente sencilla crezca sin control durante el proyecto. Incluye un mapa inicial de contenidos, aunque no sea definitivo: inicio, servicios, productos, empresa, recursos, contacto, área privada u otras secciones justificadas.
Clasifica cada elemento en una de estas categorías:
- Imprescindible: debe estar publicado en la primera versión porque responde a un objetivo prioritario.
- Deseable: aporta valor, pero puede evaluarse para una segunda fase sin bloquear el lanzamiento.
- Fuera de alcance: no forma parte de la propuesta inicial, aunque pueda estudiarse más adelante.
Indica si hay que migrar páginas, URL, imágenes, documentos, fichas de producto o entradas de una web anterior. Aclara también los idiomas, el volumen aproximado de contenido y la frecuencia con la que se actualizará.
El briefing debe identificar quién aporta textos, fotografías, vídeos, datos de producto, casos autorizados y materiales de marca; quién revisa cada pieza; y quién da la aprobación final. Estas decisiones afectan tanto al calendario como al alcance.
4. Funcionalidades e integraciones que cambian el alcance
Una web corporativa puede necesitar formularios sencillos, pero el alcance cambia cuando incorpora catálogos complejos, reservas, pagos, registro de usuarios, áreas privadas, buscadores, calculadoras o configuradores.
No basta con enumerar una funcionalidad. Describe qué debe hacer el usuario, qué información se recoge, qué ocurre después y quién será responsable de gestionarla. Una petición como «enviar los formularios al CRM» puede implicar decisiones sobre los campos enviados, la corrección de errores, el tratamiento de duplicados y el comportamiento previsto si falla la conexión.
Si existen integraciones, reúne la información disponible sobre accesos, responsables técnicos, datos intercambiados, documentación de API y restricciones conocidas. Cuando el proyecto incluye procesos internos, permisos, sincronización con sistemas empresariales o lógica operativa compleja, conviene tratarlo como una señal de que el alcance puede exceder una web corporativa convencional.
5. Diseño, marca y experiencia de uso
Las referencias visuales son útiles, pero no deberían ser el núcleo del briefing. Junto a ejemplos de webs que gusten o no gusten, explica qué debe transmitir la marca y qué acciones debe resultar fácil realizar.
Incluye el logotipo, la identidad visual, los colores, las tipografías, las fotografías, los vídeos y las normas de uso de marca disponibles. Si faltan materiales, indícalo: será una decisión de alcance, no un detalle que deba aparecer al final.
También conviene describir los contextos de uso: dispositivos habituales, usuarios que trabajan desde movilidad, páginas prioritarias, navegación, formularios y llamadas a la acción. El diseño debe facilitar las tareas relevantes, no limitarse a adaptarse visualmente a distintos tamaños de pantalla.
Evita convertir «queremos una web como la de este competidor» en un requisito cerrado. Una referencia puede servir para comentar jerarquía, tono, navegación o claridad, pero las decisiones deben responder a los usuarios y objetivos propios.
6. SEO, accesibilidad, privacidad y analítica desde el inicio
Estos requisitos son más fáciles de planificar antes del diseño y de la migración que de corregir después.
SEO y arquitectura
Define las páginas prioritarias, los temas de búsqueda relevantes, la arquitectura inicial, las URL que deben conservarse y los contenidos que habrá que migrar o revisar. La documentación de Google sobre SEO recomienda organizar el contenido de forma comprensible para usuarios y buscadores, con enlaces rastreables y URL descriptivas cuando proceda.
También puede ser necesario concretar sitemap, requisitos de rastreo y control de indexación, redirecciones, datos estructurados, versiones multidioma y necesidades técnicas de migración. Incluir estos aspectos en el briefing no garantiza indexación, posiciones, tráfico ni conversiones; permite tenerlos en cuenta desde el comienzo. Para ampliar los elementos de una página orientados al posicionamiento, consulta SEO On-Page: qué debe incluir tu web para posicionar mejor.
Accesibilidad
Indica el nivel objetivo de accesibilidad y los elementos que requieren especial atención: navegación por teclado, foco visible, formularios, objetivos táctiles, componentes que usan arrastre, ayuda consistente y autenticación. WCAG 2.2 recoge criterios verificables organizados en los principios perceptible, operable, comprensible y robusta, con niveles A, AA y AAA.
Fijar un objetivo no demuestra por sí solo conformidad. El alcance, las tecnologías empleadas y las pruebas necesarias dependen de cada proyecto; en contextos regulados puede ser necesaria una revisión especializada.
Cookies, privacidad y medición
El briefing debe identificar las herramientas de analítica y medición previstas, sus finalidades, las personas responsables de configurarlas y las necesidades de consentimiento. La guía de la AEPD sobre cookies ofrece orientación que debe aplicarse según las tecnologías y los proveedores realmente utilizados.
Los requisitos sobre formularios, privacidad, cookies, accesibilidad o comercio electrónico dependen de los datos tratados, el tipo de web y la normativa aplicable. Deben revisarse para el caso concreto: una configuración genérica no basta para afirmar cumplimiento.
7. Operación después del lanzamiento
La publicación no es el final de la web. El briefing debe indicar quién actualizará contenidos, productos, formularios, usuarios e integraciones; qué formación puede necesitar el equipo; y cómo se gestionarán copias de seguridad, actualizaciones, soporte e incidencias.
Antes de iniciar el cambio, confirma quién controla el dominio, el hosting, el código, los contenidos, las cuentas de analítica y los accesos a servicios externos. Esta comprobación ayuda a evitar dependencias o pérdidas de acceso durante una migración.
Separa lo que debe estar operativo en el lanzamiento de lo que puede organizarse después. La gestión continua necesita responsables claros, no solo una entrega técnica.
8. Calendario, presupuesto orientativo y responsables
Incluye fechas relevantes, campañas, temporadas, dependencias internas y una fecha objetivo si existe. No conviertas una fecha deseada en un compromiso técnico si los contenidos, accesos o decisiones todavía no están disponibles.
Identifica al menos a una persona responsable de coordinación, otra de contenidos, otra de validación de negocio y, cuando proceda, un contacto técnico para integraciones. Si una misma persona cubre varias funciones, también conviene dejarlo escrito.
Un presupuesto orientativo o rango disponible puede servir para planificar alternativas, pero no existe un precio, plazo ni número de páginas estándar. El alcance real depende de contenidos, migración, personalización, integraciones y requisitos de operación.
Cómo comparar propuestas sin fijarte solo en la cifra
Para que varias propuestas sean comparables, pide a cada proveedor que responda sobre los mismos puntos. Esta matriz es una herramienta editorial de revisión, no una norma universal.
| Aspecto | Qué comprobar en cada propuesta |
|---|---|
| Alcance | Páginas, idiomas, funcionalidades y fases incluidas. |
| Contenidos y migración | Qué materiales debe aportar la empresa, qué se migra y qué queda excluido. |
| Integraciones | Sistemas incluidos, supuestos técnicos, responsabilidades y límites conocidos. |
| SEO y accesibilidad | Qué requisitos se contemplan en arquitectura, migración, rastreo, contenido y pruebas. |
| Diseño y revisiones | Entregables previstos, número de revisiones y proceso de aprobación. |
| Mantenimiento y soporte | Qué ocurre tras la publicación, qué incluye el soporte y qué tiene coste adicional. |
| Propiedad y accesos | Quién tendrá acceso y control sobre dominio, hosting, cuentas, contenidos y activos del proyecto. |
| Supuestos y exclusiones | Dependencias, tareas no incluidas y condiciones que podrían modificar alcance, coste o plazo. |
Si una propuesta no aclara varios de estos puntos, no es necesariamente incorrecta, pero será difícil compararla con otra que sí detalle sus límites y responsabilidades.
Errores frecuentes al preparar un briefing web
- Pedir una web sin explicar el problema. Una lista de páginas no sustituye al objetivo que deben cumplir.
- Describir a la empresa, pero no a los usuarios. Sin sus tareas y dudas, es difícil decidir estructura y prioridades.
- Confundir hipótesis con necesidades verificadas. Una preferencia interna puede ser válida, pero debe identificarse como una suposición si todavía no hay evidencia que la respalde.
- Imponer tecnología o copiar a un competidor. Puede limitar opciones antes de conocer las necesidades reales.
- Dejar los contenidos para el final. Textos, imágenes, aprobaciones y migración afectan tanto al alcance como al calendario.
- Olvidar accesos e integraciones. Un CRM, un ERP o una cuenta de analítica pueden cambiar el trabajo necesario.
- Suponer que todas las funcionalidades caben en el presupuesto inicial. Las prioridades y exclusiones deben quedar claras antes de comparar propuestas.
- Ignorar mantenimiento y propiedad. La empresa debe saber quién podrá actualizar la web y controlar sus cuentas tras el lanzamiento.
Comprueba si tu briefing está listo para pedir propuestas
- El problema, el punto de partida y los objetivos están descritos.
- Los perfiles de usuario, sus necesidades y las acciones prioritarias son claros.
- Se distingue qué afirmaciones proceden de datos o investigación, cuáles son opiniones internas y cuáles siguen pendientes de validar.
- El mapa de páginas separa imprescindibles, deseables y fuera de alcance.
- Los contenidos disponibles, los idiomas, la migración y los responsables están identificados.
- Las funcionalidades e integraciones incluyen una finalidad y la información disponible para evaluarlas.
- Se han considerado SEO, accesibilidad, cookies, privacidad y analítica.
- Hay responsables de decisión y aprobación, además de fechas y dependencias relevantes.
- Se ha confirmado la propiedad de dominio, hosting, cuentas y servicios externos.
- La propuesta solicitada deberá detallar alcance, supuestos, exclusiones, mantenimiento y soporte.
Con estas respuestas no necesitas una especificación técnica cerrada. Sí tendrás un documento inicial suficientemente claro para decidir qué preguntar, qué priorizar y cómo valorar las propuestas que recibas.
Preguntas frecuentes
¿Cuántas páginas debe tener un briefing web?
No hay una extensión estándar. Debe contener la información necesaria para entender el problema, los usuarios, el alcance, los contenidos, las funcionalidades, los responsables y las dependencias. Un proyecto sencillo puede requerir pocas páginas; uno con migración o integraciones necesitará más detalle.
¿Debe incluir el briefing una tecnología o un CMS concreto?
No necesariamente. Es preferible describir primero las necesidades, los contenidos, la operación y las integraciones. Si la empresa tiene una restricción técnica real o un sistema existente que condiciona el proyecto, debe indicarlo junto con el motivo.
¿Qué diferencia hay entre un briefing y una especificación técnica?
El briefing define el contexto, los objetivos, los usuarios, el alcance y los requisitos conocidos para orientar el proyecto. La especificación técnica concreta después cómo se implementarán funciones, datos, integraciones, seguridad y otros detalles de desarrollo.
¿Hay que tener redactados todos los contenidos antes de pedir propuestas?
No siempre, pero sí conviene saber qué contenidos existen, cuáles deben crearse, quién los preparará y quién los aprobará. Esta información permite estimar el alcance y evitar que la falta de materiales retrase el proyecto.
¿Debe incluir SEO y accesibilidad desde el principio?
Sí. El briefing debería recoger las páginas prioritarias, las necesidades de migración, la arquitectura inicial, los requisitos de rastreo y control de indexación, y el nivel objetivo de accesibilidad. Planificarlos desde el inicio facilita incorporarlos al diseño y desarrollo, aunque no garantiza por sí mismo resultados de posicionamiento ni conformidad.
¿Qué información hay que preparar si la web se integra con un CRM o ERP?
Conviene identificar el sistema implicado, las personas responsables, los accesos o la documentación disponibles, los datos que se intercambiarán, qué sistema será el origen de cada dato y qué debe ocurrir si la integración falla. Estos aspectos pueden cambiar de forma relevante el alcance del proyecto.
