Briefing de diseño web: qué preparar antes de pedir una propuesta

Un briefing de diseño web es un documento que explica qué necesita tu negocio, a quién quiere ayudar y qué debe permitir la página. No tiene que parecer técnico ni resolver de antemano todas las decisiones. Su utilidad está en compartir información suficiente para que la propuesta describa el proyecto que necesitas, con sus dudas y dependencias visibles.

Puedes empezar con una página bien pensada y ampliar lo necesario. Una lista enorme de campos sin respuestas fiables no aporta más claridad. Si todavía no sabes qué tecnología utilizar o cuántas páginas hacen falta, indícalo: precisamente esas decisiones pueden formar parte del trabajo del estudio.

Esta guía recorre la información que conviene preparar, muestra cómo convertir peticiones vagas en necesidades concretas y ofrece un ejemplo completo. Al terminar tendrás una base para pedir presupuesto, comparar propuestas y revisar el resultado con un criterio compartido.

El documento empieza por un problema reconocible

«Necesitamos una web moderna» expresa una intención, pero no explica qué debería mejorar. Añade lo que observas: cuesta presentar los servicios, las consultas llegan sin contexto, la información está desactualizada o el equipo no puede publicar proyectos. Cuanto más concreto sea el problema, más fácil resultará discutir una solución proporcionada.

Separa observaciones de hipótesis. «Los clientes preguntan si instalamos el mobiliario» es una observación. «La explicación está demasiado escondida» es una posible causa. El proveedor puede revisar esa hipótesis; no debería tener que tratarla como una conclusión cerrada. Un buen briefing permite investigar, además de ejecutar.

Incluye lo que ya funciona. Quizá la web presenta bien el equipo, recibe consultas adecuadas o conserva páginas que se comparten con frecuencia. Esas piezas merecen atención antes de plantear una reconstrucción. Describir solo dificultades puede llevar a sustituir recursos útiles sin necesidad.

Si partes de cero, describe cómo explicas hoy el servicio y dónde aparecen las fricciones. Una conversación por correo, un perfil social o una presentación pueden aportar material. La ausencia de web no significa ausencia de experiencia comercial; utiliza lo que ya sabes sobre las preguntas de tus clientes.

Un objetivo principal que pueda orientar decisiones

Una web puede informar, mostrar trabajo y recibir consultas, pero conviene decidir qué acción tiene prioridad. Si todas las funciones se presentan como igualmente urgentes, será difícil reducir alcance o resolver conflictos de diseño. El objetivo principal ayuda a elegir qué debe quedar más claro y qué puede esperar.

Escribe una situación: «Una empresa que busca un taller de mobiliario debe comprender qué encargos aceptamos y enviarnos una descripción inicial». Esa frase define público, información y acción. No promete ventas ni impone una herramienta específica. Permite estudiar si hace falta un formulario, una galería o una explicación del proceso.

Añade objetivos secundarios solo cuando tengan una función concreta. Publicar proyectos puede ayudar al equipo comercial a compartir referencias. Ofrecer una guía puede preparar mejor una consulta. Incorporar otro idioma puede responder a un público que ya atiendes. Cada objetivo debe explicar para qué existe y quién lo mantendrá.

No confundas objetivo con métrica aislada. «Tener más visitas» necesita contexto: de qué personas, con qué necesidad y hacia qué servicio. Una web puede atraer atención poco pertinente. Si buscas encargos, conviene considerar también las consultas recibidas y su encaje, con definiciones que el equipo pueda aplicar de forma consistente.

Describir al cliente sin inventar un personaje decorativo

No necesitas empezar asignando un nombre ficticio y una edad exacta a tu cliente ideal. Es más útil explicar su situación: qué necesita resolver, qué sabe del servicio, qué compara y qué le preocupa antes de contratar. Esa información afecta directamente al contenido y al recorrido.

Por ejemplo, un responsable de una pequeña empresa puede necesitar renovar la web y no disponer de textos actualizados. Una persona que organiza un evento puede desconocer si el espacio admite el formato que imagina. Un profesional que busca identidad visual puede tener logo, pero no materiales coherentes. Cada situación requiere preguntas y explicaciones diferentes.

Si atiendes varios públicos, señala cuáles son prioritarios y dónde divergen sus necesidades. No todos necesitan una sección propia. Puede bastar con ejemplos distintos, o puede hacer falta separar servicios. El briefing debe aportar información para decidirlo, sin imponer una solución antes de explorar el contenido.

Utiliza evidencias cuando existan: preguntas recibidas, tipos de encargos y objeciones frecuentes, siempre sin datos personales. Si una descripción es una suposición, márcala como tal. La precisión no consiste en completar todas las casillas; consiste en distinguir lo que sabes de lo que necesitas aprender.

La oferta necesita límites y prioridades

Enumera los servicios que quieres presentar y describe cada uno en lenguaje sencillo. Añade qué incluye, qué suele quedar fuera y cómo empieza la relación. Si el alcance depende del caso, explica qué información permite valorarlo. Esa variabilidad es parte de la oferta y debe quedar reflejada.

Señala qué servicios quieres impulsar y cuáles solo necesitan seguir disponibles. El diseño de la portada y el orden de navegación pueden cambiar según esa prioridad. Si el negocio ha evolucionado, evita entregar documentos antiguos sin indicar qué información dejó de ser válida.

También conviene identificar las palabras que utiliza el cliente. Un equipo puede organizarse internamente por disciplinas que el público no reconoce. El briefing puede incluir ambos lenguajes: cómo llamáis al trabajo y cómo suelen pedirlo. Esa diferencia ayuda a preparar textos y categorías más comprensibles.

No hace falta publicar todos los detalles económicos para preparar el proyecto, pero sí aclarar cómo se presupuesta. ¿Hay una tarifa cerrada, un rango orientativo o una propuesta a medida? ¿Qué datos hacen falta? La web debe acompañar ese proceso sin sugerir una contratación inmediata cuando todavía se necesita valoración.

Inventariar los materiales ahorra incertidumbre

Prepara una carpeta con textos, imágenes, recursos de marca y proyectos. Clasifica cada elemento como listo, pendiente de revisión o por crear. Así el proveedor puede distinguir entre colocar contenido existente y ayudar a producirlo. Ambas tareas pueden formar parte del encargo, pero requieren tiempos y responsabilidades diferentes.

Para los textos, indica qué información está vigente y quién puede confirmarla. Un dossier antiguo puede contener una buena explicación junto a servicios retirados. No esperes que el diseñador detecte por su cuenta qué parte corresponde al negocio actual. Añadir una nota de contexto evita interpretaciones equivocadas.

Para imágenes, conserva origen y permisos de uso. Señala qué muestran y en qué páginas podrían servir. Un archivo grande no garantiza calidad adecuada y una fotografía atractiva no necesariamente explica el servicio. Si falta material, conviene valorar una sesión, ilustraciones u otra solución antes de cerrar la composición.

Los proyectos necesitan algo más que capturas. Reúne el encargo, el papel del equipo, las decisiones relevantes y lo que puede afirmarse con respaldo. Si no tienes resultados medidos, no los inventes para completar la ficha. Un caso puede demostrar criterio y alcance sin incluir una cifra comercial.

Asigna una persona responsable de entregar cada grupo de materiales. «Lo mandará el equipo» puede dejar una tarea sin dueño. Es mejor identificar quién reúne las fotografías, quién confirma el servicio y quién aprueba los textos. Esa organización forma parte del calendario, aunque no aparezca en la pantalla final.

Funciones descritas mediante situaciones

En lugar de pedir «un formulario avanzado», explica qué información debe recibir el negocio y qué tiene que ocurrir después. Si necesitas una agenda, describe quién puede reservar, cómo se actualiza la disponibilidad y qué confirma la reserva. El proveedor podrá proponer una solución conociendo el proceso.

Incluye también situaciones no ideales. ¿Qué pasa si una persona deja un campo vacío, si el envío falla o si quiere corregir sus datos? No necesitas diseñar todos los mensajes en el briefing. Basta con reconocer los casos importantes para que entren en el alcance y en las pruebas.

Si hay herramientas existentes, enuméralas por su función y responsable. Quizá usas un sistema comercial, una plataforma de reservas o una aplicación de facturación. Evita compartir contraseñas dentro del documento. La información inicial debe permitir estudiar la integración; los accesos se gestionarán de forma adecuada cuando haga falta.

Separa lo imprescindible de lo deseable. Una función imprescindible sostiene el recorrido central. Una deseable puede facilitarlo o ampliar la experiencia, pero admite una fase posterior. Esa distinción ayuda a ajustar presupuesto sin quitar al azar tareas necesarias para que la web funcione.

Autonomía editorial: qué necesitarás cambiar

«Queremos poder editar la web» es una petición demasiado amplia. Describe cambios habituales: actualizar un servicio, sustituir una imagen, publicar un proyecto o añadir un artículo. Explica quién los hará y con qué frecuencia aproximada. La solución de edición debe responder a esas tareas.

Pregunta también qué cambios prefieres solicitar al proveedor. No todos los equipos quieren gestionar todo. Una edición muy flexible puede exigir aprendizaje y aumentar el riesgo de romper la presentación. Una edición acotada puede resultar suficiente si cubre lo que realmente cambia. La decisión depende de la capacidad y las preferencias del negocio.

Incluye una prueba de autonomía en la entrega. Una persona del equipo puede publicar un proyecto de ejemplo utilizando las instrucciones previstas. Esa tarea permite comprobar si los campos, permisos y explicaciones son adecuados. Ver una demostración del proveedor no equivale a poder hacerlo después sin ayuda.

La guía sobre mantenimiento web desarrolla las responsabilidades posteriores. Conviene incorporarlas al briefing desde el principio, porque la publicación inicia una etapa de uso que necesita responsables, renovaciones y un modo claro de pedir cambios.

Referencias que explican una preferencia

Selecciona unas pocas referencias y añade una frase sobre cada una. Puede interesarte cómo ordena los servicios, cómo presenta proyectos o cómo utiliza fotografía. Esa explicación permite extraer un criterio sin convertir el encargo en una copia. Si solo envías enlaces con «me gusta», el equipo tendrá que adivinar qué rasgo te interesa.

Incluye también restricciones de marca que deban conservarse: logo vigente, colores, tipografías o materiales que ya se utilizan. Si alguna decisión se puede revisar, indícalo. Así el proveedor sabrá dónde existe margen y dónde necesita respetar una continuidad.

No utilices la referencia más espectacular como medida universal del proyecto. Una web preparada para una gran biblioteca de contenidos puede resolver necesidades distintas de las tuyas. Observa la función de cada recurso antes de pedirlo. Una animación, un buscador o un catálogo de filtros deberían tener una razón en tu recorrido.

Si varias personas aportan referencias contradictorias, resuelve qué criterio común perseguís. Quizá todas valoran claridad aunque sus ejemplos tengan estilos diferentes. Encontrar ese acuerdo antes de diseñar evita que cada revisión cambie por completo la dirección visual.

Calendario, presupuesto y dudas que cambian el alcance

Explica la fecha deseada y su motivo. Un lanzamiento ligado a un evento real exige decisiones distintas de una preferencia general por terminar pronto. Señala qué materiales pueden estar preparados y qué disponibilidad tendrá el equipo para revisar. El calendario depende de ambas partes.

Si existe un presupuesto orientativo, compartirlo ayuda a estudiar alcance. No necesitas utilizarlo como una cifra que deba agotarse. Puede servir para proponer prioridades, fases o alternativas. Una propuesta ajustada a un límite conocido será más útil que una lista extensa de funciones que luego deban retirarse sin criterio.

Anota las dudas que podrían cambiar el proyecto: otro idioma, venta online, nueva identidad o una integración todavía no elegida. Distingue las que deben resolverse antes de presupuestar de las que pueden explorarse durante el trabajo. Una incertidumbre importante no desaparece por omitirla del documento.

Pide que la propuesta identifique qué incluye, qué depende del cliente y qué se valora aparte. La guía sobre presupuesto de una web te ayuda a comparar esos puntos. El briefing y la propuesta cumplen funciones distintas: el primero describe la necesidad; la segunda concreta una forma de resolverla.

Un briefing puede contener incertidumbres sin perder utilidad. La clave es formularlas de manera concreta y explicar qué decisión afectan. «No sabemos qué web queremos» deja demasiado trabajo por interpretar. «Dudamos si separar asesoría y ejecución porque comparten proyectos, pero se contratan de forma distinta» permite estudiar arquitectura y contenido.

Clasifica las dudas por dependencia. Algunas afectan al alcance: vender online o recibir solicitudes requiere recorridos diferentes. Otras afectan a contenido: todavía falta seleccionar fotografías. Otras son preferencias que pueden explorarse durante el diseño. Resolver primero las que cambian el funcionamiento evita presupuestar una solución que después tendrá que replantearse.

Asigna una forma de resolver cada duda. Puede ser una conversación con el equipo comercial, revisar un documento, probar una herramienta o preparar una ficha de servicio. Añade quién puede aportar la información. Así el documento deja de ser una lista de incógnitas y se convierte en una secuencia manejable de decisiones.

En el taller ficticio del ejemplo, la duda sobre permitir archivos adjuntos puede resolverse observando las primeras consultas. Si las imágenes solo se necesitan después de confirmar el tipo de encargo, quizá no hagan falta en el contacto inicial. Si son imprescindibles para valorar, habrá que estudiar recepción y gestión. La función se decide por el proceso, no porque otro formulario la incluya.

Un ejemplo completo, con una empresa ficticia

Imaginemos un taller llamado Roble Claro, inventado para este ejercicio. Diseña mobiliario a medida y recibe consultas principalmente por recomendaciones y redes. Su problema no es la falta absoluta de interés: dedica muchas conversaciones a explicar qué encargos acepta y qué información necesita antes de valorar el trabajo.

Su objetivo principal podría escribirse así: «Queremos que una persona que necesita mobiliario para una vivienda comprenda nuestro proceso, vea trabajos pertinentes y nos envíe una descripción inicial». El público prioritario son particulares con una necesidad definida, aunque no tengan planos. El taller también trabaja con profesionales, pero esa línea no será el foco inicial.

La oferta se organiza en mobiliario a medida y colaboración con interioristas. El taller quiere aclarar cómo se estudian medidas, materiales e instalación, dejando las condiciones concretas para la propuesta. Tiene fotografías de varios trabajos y un logo vigente. Necesita ayuda para seleccionar casos y redactar explicaciones, porque los archivos actuales solo contienen imágenes.

La primera versión podría incluir presentación, servicios, proyectos, proceso y contacto. El número final de páginas se decidirá al ordenar el contenido. El formulario recogerá nombre, canal de respuesta, tipo de encargo y una descripción. No se pedirá un plano obligatorio, porque muchas personas no disponen de él al inicio. Las fotografías podrán solicitarse después si el equipo las necesita.

Una persona del taller será responsable de reunir materiales y aprobar contenido. Otra actualizará los proyectos, por lo que necesitará una forma de publicación acotada y una sesión de práctica. Las consultas deben llegar a un destino que el taller revise habitualmente. La recepción y el mensaje al visitante se comprobarán antes de publicar.

La fecha deseada dependerá de tener las fotografías seleccionadas y los textos revisados. Como fase posterior se estudiará una versión para profesionales si aparecen suficientes necesidades diferenciadas. La entrega se considerará preparada cuando una persona ajena al taller pueda identificar el servicio, encontrar un caso y enviar una consulta que el equipo reciba.

Este ejemplo permite al estudio hacer preguntas concretas. Puede investigar si las dos líneas necesitan páginas separadas, cuánto contenido falta y cómo organizar la edición. No presupone una tecnología ni promete resultados. Define un recorrido que se puede diseñar, presupuestar y comprobar.

Del documento inicial a una interpretación compartida

Léelo desde fuera del negocio. ¿Se entiende qué vendes sin conocer tus siglas? ¿Queda claro qué quieres mejorar? ¿Has indicado qué materiales existen y quién los confirma? Si el documento solo tiene aspiraciones, añade ejemplos. Si contiene una especificación técnica extensa que no sabes justificar, vuelve a describir las tareas que necesitas resolver.

Revisa las contradicciones. Puedes pedir una web fácil de mantener y, al mismo tiempo, proponer una actualización diaria que nadie asumirá. Puedes querer consultas muy preparadas y exigir un formulario tan corto que no recoge contexto. El briefing debe permitir conversar sobre esas tensiones, no esconderlas detrás de palabras generales.

Marca las respuestas pendientes de confirmación. Una nota clara es mejor que una afirmación inventada para completar el documento. Si no sabes cuántas revisiones necesitará el equipo, explica cómo se toman decisiones. Si no conoces el tráfico actual, indica que no dispones de medición. Eso cambia el tipo de diagnóstico que puede hacerse.

Entrega una versión identificada con fecha y conserva los cambios relevantes. Cuando el alcance evolucione, será más fácil reconocer qué se ha añadido. El objetivo no es burocratizar el proyecto, sino evitar que cada persona trabaje con un documento diferente y recuerde acuerdos incompatibles.

Cuando el estudio responda al briefing, pide que señale lo que ha entendido y lo que necesita confirmar. Esa devolución permite detectar diferencias antes de revisar una propuesta cerrada. Si interpreta que necesitas reservas cuando tú buscas solicitudes, conviene resolverlo en ese momento, aunque las pantallas imaginadas se parezcan.

Revisa también las recomendaciones que no estaban en tu documento. Una propuesta puede detectar una necesidad que no habías considerado. Pregunta qué problema resuelve, qué material exige y qué ocurriría si se pospone. Esa conversación permite valorar el consejo sin aceptar automáticamente todas las ampliaciones ni descartarlas por no haberlas pedido al principio.

Conserva las decisiones en una versión revisada o en un resumen vinculado al briefing. No necesitas reescribir cada párrafo si el cambio es pequeño, pero sí evitar acuerdos que solo existen en una llamada. La información compartida debe permitir que quien redacta, diseña y revisa trabaje con la misma interpretación.

Termina la reunión con los próximos materiales y responsables. Una propuesta puede depender de confirmar una integración o recibir un inventario de páginas. Si esas tareas quedan claras, el proyecto podrá avanzar con menos intercambios repetidos y con una base más precisa para calcular alcance, calendario y pruebas.

Usarlo durante el proyecto, no solo al principio

El briefing puede acompañar las revisiones. Si alguien propone una función nueva, pregunta qué objetivo ayuda a cumplir y qué dependencia introduce. Si una pantalla resulta atractiva pero no responde a una pregunta esencial, el documento permite señalarlo con criterio. Así las conversaciones no dependen únicamente de gustos.

También puede orientar las pruebas de entrega. Recorre las situaciones descritas y verifica si se completan. Comprueba el contenido, el contacto y las tareas de edición acordadas. Una web puede parecer terminada y todavía no resolver una función central; las situaciones concretas ayudan a detectarlo.

Después de publicar, guarda las observaciones del equipo junto a los objetivos iniciales. Puede que aparezca una necesidad no prevista o que una función resulte menos importante de lo esperado. Ese aprendizaje sirve para decidir la siguiente mejora. No necesitas rehacer el briefing entero cada semana, pero sí conservar una relación entre cambios y motivos.

Si ya tienes una web, añade su inventario y lo que deseas conservar. La guía de rediseño web ayuda a preparar esa parte. Si empiezas de cero, el documento puede ser más breve, siempre que deje claras oferta, público, acción y responsabilidades.

Una base suficiente para empezar una conversación

No esperes a tener todas las respuestas perfectas. Reúne la información fiable, señala las dudas y aporta ejemplos del problema. Un briefing útil permite que el estudio entienda tu situación y formule preguntas mejores. Su calidad se mide por la claridad que aporta al trabajo, no por su extensión.

Puedes consultar los servicios de diseño web de TRAMA y compartir el contexto de tu proyecto. Empieza por qué haces, qué te gustaría facilitar y qué materiales tienes. Con esa base será posible definir un alcance que puedas reconocer en la propuesta y comprobar cuando la web esté preparada.