Imagina que el primer documento de tu nueva web dice: «Inicio, servicios, quiénes somos, contacto. Nos gusta la web de este competidor». Parece un buen comienzo hasta que llegan dos presupuestos. Uno incluye redactar y migrar las páginas; el otro da por hecho que se las entregarás terminadas. Ninguno sabe que la mayoría de los clientes entra desde el móvil para comprobar si instaláis en su zona. El documento explica qué páginas quieres, pero no qué problema tiene que resolver la web.
Yo usaría el briefing para poner de acuerdo a la empresa y al equipo que va a construirla. No hace falta diseñar la solución de antemano. Sí hace falta explicar qué debe poder hacer una persona, qué entra en la primera versión y qué sigue sin decidirse. Cuanto mejor se vea esa diferencia, más fácil será comparar propuestas.
Empezaría por la pregunta que hoy acaba en una llamada
Para una empresa de instalaciones, escribiría «quien busca renovar una instalación no sabe si cubrimos su zona ni qué información necesitamos para valorarla». Eso ayuda más que «queremos un configurador». Quizá baste con explicar la cobertura y pedir dos datos en el formulario. Quizá el configurador tenga sentido. La decisión viene después de entender la tarea, como plantea la guía de diseño de servicios de GOV.UK.
Por cada perfil importante, anotaría quién llega, qué intenta hacer y qué le impide avanzar. Una persona de compras puede necesitar requisitos y documentación; un particular quiere saber si puede pedir una visita. Distinguiría lo que sabemos por consultas, analítica o entrevistas de lo que suponemos. Si creemos que «nadie lee los servicios», revisaría qué páginas usa ventas antes de retirarlas. También escribiría si estamos partiendo de cero o de una web con contenidos, formularios y URLs que vale la pena conservar.
Una plantilla corta que sí llevaría a la primera reunión
Para no volver a una lista de páginas sin contexto, copiaría estas preguntas en un documento. No hace falta contestarlas todas con el mismo detalle. Una duda abierta con una persona responsable vale más que una respuesta que nadie ha comprobado.
| Campo | Qué pondría |
|---|---|
| Objetivo y usuarios | Qué está pasando hoy, quién usa la web y qué tarea debe poder completar. |
| Primera versión | Páginas, idiomas y funciones imprescindibles; qué puede esperar y qué queda fuera. |
| Materiales | Textos, fotos, logotipo, casos autorizados y contenidos que se migran. Quién los entrega y aprueba. |
| Funciones y datos | Qué hace el usuario, qué se recoge, qué sistema lo recibe y qué ocurre si no llega. |
| Diseño y requisitos | Contexto de uso, referencias con motivo, accesibilidad, URLs que se conservan, privacidad y medición. |
| Calendario y operación | Fecha objetivo, dependencias, presupuesto orientativo, quién decide y quién mantiene la web después. |
En el ejemplo, pondría como imprescindible explicar los servicios y recibir solicitudes que el equipo pueda atender. Podría dejar un área privada para otra fase. Si hay fotos pendientes o falta el acceso al dominio, lo escribiría con un responsable y una fecha de revisión. Un lanzamiento vinculado a una campaña no se puede planificar bien si nadie sabe cuándo se aprobarán los textos.
También aclararía la diferencia entre redactar, traducir y migrar. «La web va en dos idiomas» no dice quién entregará las traducciones ni si alguien podrá mantener ambas versiones. Una lista de materiales con su estado ayuda a estimar sin adivinar: los textos de servicios están revisados, faltan imágenes autorizadas y el equipo aún tiene que decidir si migra todos los artículos. Si alguna de esas tareas depende del proveedor, debe aparecer en la propuesta.
«Enviar al CRM» todavía no es un requisito completo
Para el formulario, describiría qué campos necesita ventas, qué equipo recibe cada solicitud y qué ve el visitante al enviarla. Si se conecta a un CRM, anotaría qué cuenta o documentación está disponible, cómo se gestionan solicitudes repetidas y a quién se avisa si la integración falla. Una reserva, un pago o un área privada cambian el alcance de la misma manera: hay que describir la tarea, los permisos y lo que debe ocurrir después. No pediría que se cierren todos los detalles técnicos en el briefing, pero sí que la propuesta diga qué asume y qué queda por validar.
Con el diseño haría algo parecido. En vez de «que se parezca a esta web», explicaría que me gusta cómo separa dos servicios o cómo deja visible el contacto en el móvil. Añadiría los materiales de marca que existen y lo que falta producir. Y pondría dos o tres tareas de aceptación: una persona encuentra el servicio adecuado, entiende dónde se presta y envía la consulta desde su dispositivo. Así sabemos qué estamos pidiendo además de un estilo visual.
Lo que querría resuelto antes de lanzar
Si sustituimos una web, identificaría las páginas y URLs que no queremos perder, cómo se comprobará la indexación y qué contenidos necesitan una nueva ubicación. Para accesibilidad acordaría el objetivo y las pruebas —teclado, foco y errores del formulario, por ejemplo— usando las WCAG 2.2 como referencia cuando corresponda. También revisaría qué herramientas medirán las solicitudes y qué requisitos de privacidad y consentimiento aplican. La guía de la AEPD orienta esa revisión según las tecnologías reales, no según el texto de un banner genérico.
Antes de pedir propuestas, dejaría por escrito quién controla dominio, alojamiento, analítica y accesos, quién actualizará los contenidos y qué soporte hará falta. Pediría a todos los proveedores que respondan sobre las mismas páginas, idiomas, integraciones, revisiones y pruebas, con exclusiones y mantenimiento por separado. Si alguien propone otro enfoque, querría que explique qué necesidad resuelve mejor. Eso es lo que espero de un briefing: que podamos discutir una decisión concreta sin tener que adivinar qué entendió cada persona por «hacer una web».
Si ya existe una web, dedicaría un rato a distinguir qué conviene renovar y qué conservar. Esa decisión debe alimentar el briefing, no quedar para cuando la nueva portada ya está aprobada.
Preguntas frecuentes
¿Cuántas páginas debe tener un briefing web?
Las necesarias para explicar la situación, usuarios, alcance, contenidos, dependencias y responsables. Un formulario sencillo y una migración con varios idiomas no requieren el mismo detalle.
¿Tengo que elegir un CMS antes de pedir propuestas?
No necesariamente. Describe primero qué debe hacer la web y quién va a mantenerla. Si existe una restricción real de tecnología o integración, inclúyela y explica el motivo.
¿En qué se distingue del documento técnico?
El briefing aclara el problema, alcance y condiciones conocidas. La especificación técnica describe después cómo se implementan y prueban funciones, datos e integraciones.
¿Hay que tener todos los contenidos redactados?
No, pero sí saber qué materiales existen, qué hay que crear o migrar y quién se encarga de revisarlo. Eso cambia el esfuerzo y el calendario.
¿Incluyo SEO y accesibilidad desde el inicio?
Sí. Identifica páginas prioritarias, URLs que deben mantenerse y pruebas de accesibilidad. Planificarlo temprano no garantiza resultados, pero evita dejarlo para después del lanzamiento.
¿Qué preparo si la web se conecta a un CRM o ERP?
Identifica el sistema, los responsables, los accesos disponibles, los campos y el resultado esperado. Anota qué debe pasar con duplicados, rechazos y fallos.
¿Tienes que pedir presupuestos para tu web y no sabes qué dejar por escrito?
En Soulvi podemos ayudarte a convertir lo que necesita tu equipo y lo que buscan tus clientes en un briefing que permita comparar propuestas.
