Plantilla de briefing para diseño web: la guía que evita que tu proyecto acabe en malentendidos costosos

Un cliente llegó a mí después de haber pagado casi ocho mil euros por un rediseño web que no le gustaba. El diseñador había entregado exactamente lo que el cliente había pedido. El problema es que el cliente no había sabido pedir lo que quería. No existía ningún briefing. Solo correos con referencias de páginas de la competencia y frases del tipo "algo moderno y limpio".

El briefing de diseño web es el documento que convierte una idea vaga en instrucciones concretas. Cuando está bien hecho, protege tanto al cliente como al diseñador. Cuando no existe, protege a nadie. Esta guía te explica qué debe incluir y cómo redactarlo aunque no tengas formación en diseño.

Qué pasa cuando se empieza un proyecto web sin briefing

Sin briefing, cada parte del proyecto se convierte en una negociación retroactiva. El diseñador interpreta lo que no se especificó. El cliente rechaza lo que no esperaba. Los plazos se alargan porque hay que rehacer trabajo. El presupuesto se agota antes de llegar a la fase de producción.

Los malentendidos más frecuentes por falta de briefing:

• Estilo visual: el cliente quería minimalista y el diseñador entendió corporativo. O al revés
• Estructura de navegación: no se acordó cuántas páginas habría, qué secciones principales y cuál era la jerarquía de información
• Audiencia objetivo: el diseñador creó para usuarios jóvenes y el cliente vende a directores de empresa de más de cincuenta años
• Funcionalidades incluidas: el cliente daba por hecho que el formulario de contacto, el chat en vivo y la tienda online estaban en el precio. No lo estaban
• Propiedad de los entregables: quién es dueño del código, de las imágenes, de las fuentes tipográficas usadas

Cada uno de estos malentendidos genera revisiones no presupuestadas. Y cada revisión no presupuestada genera tensión, plazos incumplidos y, en el peor caso, un resultado que no satisface a nadie aunque técnicamente se haya hecho lo que se acordó verbalmente.

Qué debe incluir un briefing de diseño web completo

Un briefing completo no tiene que ser un documento de cincuenta páginas. Tiene que ser completo en los puntos que más frecuentemente generan conflicto. Estos son los apartados que no pueden faltar:

1. Descripción del proyecto y del negocio: qué hace la empresa, a quién vende, cuál es la propuesta de valor diferenciadora y cuál es el posicionamiento actual en el mercado
2. Objetivo principal de la web: generar leads, vender directamente, informar, posicionar la marca, retener clientes existentes. Un solo objetivo principal, aunque haya objetivos secundarios
3. Público objetivo: descripción detallada de quién va a usar el sitio. Edad, nivel tecnológico, dispositivo habitual, necesidades y objeciones principales
4. Alcance del proyecto: número de páginas o secciones, funcionalidades incluidas y excluidas, idiomas, versiones (web/móvil/app)
5. Identidad visual existente: logo, colores corporativos, tipografías, guía de estilo si existe. Si no existe, indicar si el diseñador tiene libertad o debe proponer dentro de unos límites
6. Referencias y ejemplos: dos o tres webs de referencia con indicación específica de qué aspectos gustan. No solo el enlace
7. Contenidos existentes: qué textos, imágenes y recursos entrega el cliente y qué genera el diseñador o se contrata aparte
8. Requisitos técnicos: plataforma (WordPress, Shopify, custom), hosting, integraciones con CRM, TPV o herramientas existentes
9. Plazos y hitos: fecha de entrega, fechas de revisión y número de rondas de cambios incluidas
10. Presupuesto: rango o límite orientativo. Sin un presupuesto, el diseñador no puede proponer soluciones adecuadas al cliente

"El briefing no es papeleo. Es la conversación que debería haber pasado al principio y que muchos clientes no saben que necesitan tener antes de pedir precio." — Sandra Morales, directora creativa en agencia de diseño web con doce años de experiencia

Cómo describir el estilo visual sin ser diseñador

Una de las partes más difíciles del briefing para los clientes que no tienen formación en diseño es describir el estilo visual que quieren. "Moderno" o "limpio" no dice nada porque casi todo el mundo los usa para describir webs radicalmente distintas. Estas son las categorías que ayudan a ser más preciso:

• Paleta de color: oscuro/claro, colores primarios/pasteles, monocromático/multicolor, cálido/frío. Si tienes colores corporativos exactos, proporciona los códigos hexadecimales
• Tipografía: serif (clásico, editorial, lujo) vs. sans-serif (moderno, digital, limpio). Monoespaciada para tecnología o código
• Densidad de información: mucho texto o poco texto, muchas imágenes o pocas, diseño con mucho espacio en blanco o aprovechamiento máximo del espacio disponible
• Tono visual general: formal/informal, seria/divertida, técnica/accesible, premium/popular, internacional/local
• Estilo fotográfico: fotos propias o de stock, ilustraciones vectoriales, iconos lineales, animaciones sutiles, sin imágenes

La mejor forma de comunicar el estilo es con referencias específicas. No "quiero algo como Apple" sino "quiero la distribución del hero de la homepage de Apple pero con los colores de Notion y el tono de voz de Mailchimp". Cuanto más específico, menos margen para interpretaciones.

Referencias visuales: cómo usarlas sin confundir al diseñador

Las referencias son útiles si se usan bien. Mal usadas, generan confusión y conflicto. El error más frecuente es enviar referencias sin contexto: "me gusta esta web" sin explicar qué aspecto concreto gusta.

La forma correcta de usar referencias en un briefing:

1. Selecciona entre dos y cinco referencias (no más, o el diseñador no sabrá qué priorizar)
2. Para cada referencia, indica específicamente qué elemento te gusta: la disposición del hero, el uso del color, la tipografía, la forma de presentar el precio, el estilo de los iconos, la microcopia
3. Si hay elementos que definitivamente no quieres, menciónalos también. Es tan útil saber qué no quieres como saber qué sí
4. Distingue entre "me gusta este estilo visual" y "quiero copiar esta estructura de navegación". Son instrucciones muy diferentes para un diseñador

"El problema no es que los clientes no sepan lo que quieren. Es que no tienen el vocabulario para describirlo. Un buen briefing les da ese vocabulario antes de que el presupuesto esté firmado." — Roberto Camps, diseñador UX con más de quince años de proyectos web

Requisitos técnicos que hay que especificar desde el principio

Los requisitos técnicos son la parte del briefing que más se omite y que más complicaciones genera después. Estos son los que debes aclarar antes de que empiece el diseño:

• Plataforma o CMS: WordPress, Shopify, Squarespace, Webflow, desarrollo a medida. Cada plataforma tiene limitaciones y capacidades diferentes que afectan al diseño posible y al mantenimiento futuro
• Hosting y dominio: ¿los gestiona el cliente o el diseñador? ¿Hay que migrar desde otro servidor existente?
• Integraciones existentes: CRM (HubSpot, Salesforce), herramienta de email marketing (Mailchimp, Brevo), Google Analytics, sistemas de pago, plataformas de reservas
• SEO técnico: ¿hay URL existentes que hay que conservar? ¿Hay posicionamiento ya conseguido que no se puede perder con la migración al nuevo diseño?
• Requisitos de accesibilidad: ¿se requiere cumplimiento de WCAG 2.1 nivel AA? ¿Hay usuarios con discapacidad visual o motora en el público objetivo?
• Velocidad de carga: ¿hay objetivos de tiempo de carga o de Core Web Vitals para el posicionamiento?
• Autonomía de edición del cliente: ¿el cliente necesita poder editar contenidos sin ayuda técnica? ¿Qué nivel de autonomía se espera?

Para proyectos en WordPress, herramientas como Elegant Themes (Divi) ofrecen constructores visuales que permiten al cliente hacer cambios menores sin depender del diseñador. Si la autonomía futura del cliente es un requisito, mencionarlo en el briefing ayuda al diseñador a elegir la herramienta adecuada desde el inicio.

Contenidos del proyecto: quién entrega qué y cuándo

Uno de los mayores causantes de retrasos en proyectos web es la entrega tardía de contenidos por parte del cliente. El diseñador puede tener el diseño listo y el proyecto se paraliza semanas porque el cliente no ha preparado los textos o las imágenes.

El briefing debe especificar:

• Qué textos entrega el cliente (ya escritos o en borrador)
• Qué textos redacta el diseñador o un copywriter contratado para el proyecto
• Qué imágenes aporta el cliente (fotos propias, fotos de producto, fotos de equipo)
• Qué imágenes se obtienen de bancos de imágenes y quién paga las licencias
• Si hay videos, animaciones o elementos interactivos, quién los produce
• Fecha límite para entrega de materiales por parte del cliente, con consecuencias sobre el plazo del proyecto si no se cumple

Cómo gestionar las revisiones sin que destruyan el presupuesto

El número de rondas de cambios incluidas en el presupuesto es uno de los puntos que más conflictos genera si no se especifica desde el principio. Define esto en el briefing:

• Número de rondas de revisión incluidas por fase (wireframes, diseño visual, desarrollo)
• Qué cuenta como una revisión en cada fase: cambios de contenido, cambios de estructura, cambios de estilo
• Coste de las revisiones adicionales fuera del alcance contratado (generalmente entre 60 y 150 euros por hora)
• Procedimiento para solicitar cambios: en qué formato, a quién y en qué plazo
• Quién tiene autoridad para aprobar cada fase (si hay varios interlocutores en el cliente)

Para plantillas adicionales y recursos de diseño para tus proyectos web, Envato Market tiene una biblioteca de temas premium y kits de diseño tanto para WordPress como para otros CMS populares.

Plazos realistas para un proyecto web: lo que nadie dice hasta que ya es tarde

Los plazos de los proyectos web se subestiman sistemáticamente. Estas son las duraciones reales para proyectos estándar en 2026, sin imprevistos:

• Landing page sencilla (una página, sin integraciones): dos a tres semanas desde el briefing hasta entrega
• Web corporativa (cinco a ocho páginas, WordPress): cuatro a seis semanas
• Tienda online básica (Shopify o WooCommerce con hasta veinte productos): seis a diez semanas
• Web con funcionalidades a medida (integraciones complejas, CRM, área de cliente): tres a seis meses

El plazo real casi siempre supera estas estimaciones cuando el cliente tarda en entregar materiales, cuando hay varias rondas de revisión o cuando aparecen requisitos técnicos no detectados en el briefing inicial. Planifica con un margen del 30-40% sobre la estimación del diseñador.

Errores que convierten un buen briefing en un mal proyecto

El briefing es el punto de partida, no la garantía de éxito. Hay errores que se cometen después del briefing y que arruinan lo bien que empezó:

• Cambiar el objetivo a mitad del proyecto: si el objetivo era generar leads y a mitad del proyecto el cliente decide que también quiere una tienda online, ese es un proyecto nuevo, no una variación del original
• Añadir páginas o secciones sin ajustar el presupuesto: "solo añade una sección más" parece pequeño pero puede representar días de trabajo extra
• No aprobar las fases en plazo: cada fase bloqueada por falta de aprobación del cliente bloquea la siguiente. El diseñador no puede avanzar sin el visto bueno y su agenda no esperará indefinidamente
• Cambiar la guía de estilo después de que el diseño está avanzado: si el logo cambia cuando ya hay veinte páginas diseñadas, hay que rehacerlas todas
• Multiplicar los interlocutores del cliente sin un interlocutor único: cuando cinco personas del equipo del cliente pueden pedir cambios directamente al diseñador, el proyecto se convierte en ingobernable

El briefing técnico vs. el briefing creativo: cuándo necesitas los dos

Para proyectos web complejos, puede tener sentido separar el briefing en dos documentos: el briefing creativo, que cubre el estilo visual, el tono de comunicación y la experiencia de usuario, y el briefing técnico, que cubre las integraciones, la arquitectura de la información y los requisitos de rendimiento.

El briefing creativo lo completa el equipo de marketing o comunicación del cliente. El briefing técnico lo completa el equipo de IT o el director técnico. Son perfiles distintos con información distinta, y mezclarlos en un solo documento a menudo resulta en que ninguno de los dos apartados se rellena bien.

Para proyectos pequeños (webs corporativas simples, landing pages), un solo briefing integrado es suficiente. Para proyectos con integraciones complejas o con requisitos técnicos específicos, la separación ayuda a que cada parte del equipo se centre en lo que sabe.

Cómo presupuestar un proyecto web en 2026: rangos por tipo de proyecto

Una de las preguntas más frecuentes es qué debe costar un proyecto web. Los rangos varían mucho según la complejidad y el proveedor, pero estas son las referencias del mercado español en 2026:

SEO desde el diseño: lo que hay que especificar en el briefing para no perder posicionamiento

El SEO no se añade después de que la web está hecha. Se diseña desde el principio. Si no especificas los requisitos de SEO en el briefing, te arriesgas a recibir una web técnicamente correcta pero que posiciona mal o que destruye el posicionamiento que ya tenías.

Los requisitos de SEO que hay que incluir en el briefing:

• Estructura de URLs: si tienes URLs actuales que posicionan bien, hay que conservarlas o hacer redirecciones 301. Cambiar las URLs sin redirecciones borra el posicionamiento acumulado
• Velocidad de carga: establecer un objetivo concreto, por ejemplo Core Web Vitals en verde para todos los dispositivos. El diseñador tiene que optimizar imágenes y código para cumplirlo
• Estructura de encabezados: H1 único por página, jerarquía correcta de H2 y H3, sin saltarse niveles
• Metadatos editables: el cliente tiene que poder editar title y meta description de cada página sin tocar código
• Schema markup: para negocios locales, tiendas online o sitios de contenido, el schema markup mejora la visibilidad en los resultados de Google. Hay que especificarlo en el briefing técnico
• Sitemap y robots.txt: el sitemap XML tiene que generarse automáticamente y actualizarse con cada cambio de contenido

Accesibilidad web: lo que la ley exige en España en 2026

La accesibilidad web ha pasado de ser una buena práctica a ser una obligación legal para ciertos tipos de webs. El Real Decreto 1112/2018 obliga a cumplir WCAG 2.1 nivel AA a todas las webs del sector público y a un número creciente de organizaciones privadas que prestan servicios de interés general.

Para webs de empresas privadas sin obligación legal explícita, incluir requisitos de accesibilidad en el briefing tiene sentido por tres razones: llega a más usuarios (más del 15% de la población tiene alguna discapacidad), mejora el SEO (los textos alternativos en imágenes, la estructura de encabezados y la semántica correcta del HTML benefician también al posicionamiento), y reduce el riesgo legal ante futuras regulaciones.

Los requisitos mínimos de accesibilidad que deberían estar en cualquier briefing web en 2026:

• Contraste de color mínimo de 4.5:1 para texto normal y 3:1 para texto grande
• Textos alternativos descriptivos para todas las imágenes con contenido
• Navegación posible con teclado sin ratón
• Formularios con etiquetas claras y mensajes de error comprensibles
• Videos con subtítulos o transcripción

El mantenimiento web: lo que hay que acordar en el briefing para después de la entrega

La web entregada no es un producto terminado. Es un producto que necesita mantenimiento continuo: actualizaciones de seguridad, corrección de errores, actualizaciones de plugins y CMS, copias de seguridad, renovación de certificado SSL.

El briefing debe abordar quién se hace cargo del mantenimiento después de la entrega:

• ¿Incluye el diseñador un período de mantenimiento post-lanzamiento? ¿Cuánto dura?
• ¿Hay un contrato de mantenimiento mensual disponible y a qué precio?
• Si el cliente gestiona el mantenimiento por su cuenta, ¿qué formación incluye el proyecto para que el equipo del cliente pueda hacerlo?
• ¿Cómo se gestionan los errores críticos de seguridad fuera del contrato de mantenimiento?

Cómo evaluar propuestas de diseño web: lo que hay que mirar más allá del precio

Cuando tienes el briefing completo y has recibido varias propuestas, comparar solo el precio es un error. El precio más bajo raramente es la mejor opción en un proyecto web, igual que en una reforma de cocina o en una consultoría jurídica.

Lo que hay que evaluar en cada propuesta:

• Comprensión del proyecto: ¿la propuesta refleja que el diseñador leyó el briefing o es una respuesta genérica? Un diseñador que leyó bien el briefing menciona aspectos específicos del negocio y propone soluciones concretas
• Portfolio relevante: proyectos similares en tipo, tamaño o sector. Un diseñador que ha hecho diez tiendas online está mejor preparado para hacer la tuya que uno que ha hecho principalmente webs corporativas
• Claridad del alcance: ¿está claro qué incluye el precio y qué no? Las propuestas vagas en el alcance generan facturas finales muy por encima del presupuesto inicial
• Proceso de trabajo: ¿cómo va a ser la comunicación durante el proyecto? ¿Con qué frecuencia se reporta avance? ¿Qué pasa si algo no va bien?
• Quién hace el trabajo realmente: ¿el diseñador que hizo el briefing va a ser quien trabaje en el proyecto o lo va a subcontratar?

Propiedad intelectual en proyectos de diseño web: qué hay que acordar antes de empezar

La propiedad intelectual del diseño web es una zona gris que genera conflictos con frecuencia. Si no está en el contrato, la interpretación legal por defecto en España es que el diseñador retiene los derechos sobre las obras que crea, aunque las haya encargado el cliente.

Los puntos que hay que definir en el contrato:

• Propiedad del código fuente: ¿el cliente recibe el código fuente completo o solo el acceso a la web? Son cosas distintas
• Licencias de tipografías: muchas tipografías de diseño tienen licencias por uso web que no son transferibles automáticamente al cliente
• Licencias de imágenes de stock: si el diseñador usa imágenes de bancos de imágenes, hay que especificar si la licencia es perpetua o de uso limitado
• Propiedad de los elementos de diseño originales: iconos, ilustraciones, animaciones creadas específicamente para el proyecto
• Derecho a mostrar el proyecto en el portfolio del diseñador: es habitual pero debe acordarse expresamente

El mantenimiento después del lanzamiento: un presupuesto que nadie planifica

El presupuesto de un proyecto web raramente incluye el coste del mantenimiento posterior. Pero ese coste existe y hay que anticiparlo en el briefing para no llevarse sorpresas cuando la web lleva un mes online y hay que actualizar el CMS, renovar el SSL o corregir un error de compatibilidad con el navegador.

Los costes recurrentes habituales de una web WordPress en 2026:

• Hosting de calidad: entre 10 y 80 euros al mes según las necesidades
• Renovación de dominio: entre 10 y 20 euros al año
• Contrato de mantenimiento con el diseñador: entre 50 y 300 euros al mes según las horas incluidas
• Licencias de plugins premium: entre 50 y 300 euros al año según cuántos uses
• Certificado SSL: incluido en la mayoría de hostings de calidad, pero hay que verificarlo

Mobile first: por qué el briefing debe especificarlo como requisito no negociable

En 2026, más del 65% del tráfico web a nivel global proviene de dispositivos móviles. Para muchos sectores, esa cifra supera el 75%. Esto hace que diseñar primero para móvil y adaptar para escritorio sea la única aproximación razonable para la mayoría de proyectos.

El briefing debe especificar explícitamente que el diseño es mobile-first y que el rendimiento en dispositivos móviles es un criterio de aceptación tan importante como el diseño en escritorio. Sin esta especificación, algunos diseñadores siguen diseñando para escritorio y adaptando al móvil como segunda fase, con resultados que a menudo son subóptimos en el dispositivo que usa la mayoría de los usuarios.

Los puntos concretos sobre mobile que deben estar en el briefing técnico:

• Tamaños de pantalla objetivo (mínimo 320px, habitualmente 375px para iPhone estándar)
• Comportamiento de los menús de navegación en móvil
• Formularios optimizados para teclado táctil (campos grandes, tipo de teclado correcto para cada campo)
• Pruebas de usabilidad en dispositivos reales, no solo en simuladores del navegador

La entrega del proyecto web: qué documentación debe incluir el diseñador

Cuando un proyecto web termina, el diseñador debe entregar más que la web funcionando. La documentación de entrega es lo que permite al cliente o a otro profesional hacerse cargo del proyecto sin depender del diseñador original.

La documentación mínima que debe incluir la entrega de un proyecto web:

• Accesos: credenciales del servidor, del panel de administración del CMS, del dominio, del certificado SSL, de Google Analytics y de cualquier herramienta conectada al sitio
• Guía de estilo: colores, tipografías, estilos de botones, espaciados. Idealmente en un archivo de diseño (Figma, Adobe XD) además del documento escrito
• Manual de usuario básico: cómo crear y editar páginas, cómo añadir productos (si es tienda), cómo gestionar el blog, cómo revisar los formularios recibidos
• Documentación de las integraciones: qué servicios externos están conectados, cómo están configurados y cómo actualizarlos si cambian las credenciales
• Plan de backups: cómo y con qué frecuencia se hace copia de seguridad del sitio y cómo restaurarla en caso de necesidad