Volver al blog

Cómo preparar un brief para desarrollar un sitio web

Definí objetivos, páginas, contenidos, funciones y criterios de aceptación para explicar qué necesita tu sitio web antes de iniciar el desarrollo.

5 min de lectura
Equipo de trabajo organizando los requisitos para desarrollar un sitio web

“Necesitamos una web moderna” expresa una intención, pero no define qué habrá que construir. ¿El sitio debe explicar servicios, recibir consultas, permitir reservas o facilitar que el equipo actualice contenidos? Si esas preguntas quedan abiertas, cada persona puede imaginar un proyecto distinto.

Un brief no necesita ser un documento técnico ni extenso. Es una guía compartida para describir el problema, las personas a quienes se dirige el sitio y las condiciones que permitirán revisar el resultado. MDN recomienda definir qué se quiere lograr y cómo ayudará el sitio antes de elegir herramientas o entrar en la parte técnica. La guía de planificación de MDN ofrece una base útil para ordenar esas decisiones.

1. Empezá por el resultado que necesitás

Escribí en una frase qué debería poder hacer mejor una persona gracias al sitio. Por ejemplo: “Una persona que busca asesoramiento podrá entender qué ofrecemos y pedir una reunión”. Esto aporta más dirección que pedir una página “atractiva” o “actual”.

Después identificá la acción principal: enviar una consulta, llamar, solicitar una cotización, encontrar una dirección o consultar información. Puede haber otras acciones secundarias, pero conviene distinguirlas. Si todo se marca como prioridad máxima, el equipo no tendrá una regla clara para resolver decisiones de alcance.

También anotá cómo reconocerán que el sitio cumple su propósito. Elegí señales que puedan observarse, como que el formulario llegue al correo correcto o que la información de contacto sea fácil de encontrar. No prometas resultados comerciales que el sitio, por sí solo, no puede garantizar.

2. Delimitá a quién debe servir y qué páginas hacen falta

Describí a los usuarios por sus necesidades, no solo por categorías demográficas. ¿Qué quieren saber? ¿Qué dudas suelen tener? ¿Qué necesitan hacer después de llegar al sitio? Una descripción concreta ayuda a ordenar los mensajes y las rutas de navegación.

Luego prepará una lista inicial de páginas. Para cada una, anotá su propósito y la información necesaria. Un mapa pequeño podría incluir Inicio, Servicios, Sobre nosotros y Contacto, pero no copies una estructura genérica sin revisar si responde al caso real.

La organización lógica de páginas y enlaces puede ayudar a que las personas comprendan cómo se relaciona el contenido. Google explica este principio en su guía de SEO para principiantes. Esto no significa que exista un mapa universal ni que una estructura determinada garantice posiciones en buscadores: es un criterio de claridad y descubrimiento.

3. Aclará contenidos, funciones y límites

El brief debe identificar qué materiales existen y quién se hará cargo de los que faltan. Incluí textos, fotografías, logotipos, documentos, datos de contacto y cualquier material que deba revisarse o actualizarse. Si una sección todavía no tiene contenido, anotalo como pendiente en lugar de asumir que aparecerá automáticamente.

Separá el contenido de las funcionalidades. Una página que describe un servicio es distinta de un formulario que envía datos, un calendario que permite reservar o un área privada para usuarios. Para cada función, describí qué persona la usa, qué información ingresa y qué debería pasar después.

Podés ordenar el alcance con esta lista:

  • Incluido: páginas y funciones necesarias para la primera versión.
  • Fuera de alcance: ideas que no se construirán en esta etapa.
  • Pendiente de confirmar: decisiones que necesitan información, aprobación o una estimación.
  • Responsable: quién entrega cada contenido y quién lo aprueba.

Esta separación reduce malentendidos y permite conversar sobre cambios sin tratar cada idea nueva como si ya estuviera incluida.

4. Definí condiciones prácticas y criterios de aceptación

Agregá restricciones que puedan afectar el proyecto: fecha objetivo, idiomas, sistemas con los que debe conectarse, quién administrará la web y qué conocimientos tendrá esa persona. Si el sitio debe permitir editar textos sin asistencia técnica, indicalo como requisito y preguntá cómo se probará esa tarea.

Los criterios de aceptación convierten expresiones vagas en comprobaciones. En vez de “el formulario debe funcionar bien”, podés indicar: “Al enviar el formulario con los campos requeridos completos, aparece una confirmación y el mensaje llega al buzón acordado”. En vez de “debe verse bien en todos lados”, especificá las páginas y dispositivos que el equipo revisará, sin prometer compatibilidad ilimitada.

Incluí también quién revisa cada entrega y en qué momento. Si varias personas tienen que aprobar textos o diseño, designá una voz final para consolidar comentarios. Una cita editorial resume el criterio:

“Un requisito útil no describe una preferencia: permite tomar una decisión o comprobar un resultado.”

Esquema visual de un brief web con objetivos, páginas, contenidos y funcionalidades
Un brief útil conecta las necesidades del negocio con decisiones concretas de diseño y desarrollo.

5. Convertí el brief en una herramienta de trabajo

Compartí el documento con quienes deciden y con quienes aportarán contenidos. Pediles que señalen contradicciones y preguntas sin respuesta antes de cerrar el alcance. No hace falta resolver cada detalle técnico por adelantado: sí conviene separar lo confirmado de lo que requiere evaluación profesional.

Antes de pedir una propuesta o iniciar el desarrollo, verificá estos puntos:

  • El objetivo principal puede explicarse en una frase.
  • Está claro quién usará el sitio y qué necesita encontrar o hacer.
  • La lista de páginas tiene un propósito para cada sección.
  • Las funciones están descritas por su comportamiento, no solo por su nombre.
  • Se sabe quién prepara y aprueba cada contenido.
  • El alcance distingue lo incluido, lo excluido y lo pendiente.
  • Hay comprobaciones concretas para aceptar las entregas.

Un brief claro no garantiza que el proyecto no cambie; permite reconocer qué cambió y conversar sobre el impacto antes de avanzar. Google también aclara que enviar un sitemap puede ayudar a descubrir URLs, pero no garantiza que se indexen. Por eso, evitá convertir el SEO en una promesa automática dentro de los requisitos: priorizá una estructura comprensible, páginas accesibles y contenido útil.

Una próxima decisión concreta

Reservá una reunión breve con las personas involucradas y completá una página con objetivo, usuarios, páginas, funciones, responsables y criterios de aceptación. Si aparecen dudas técnicas, registralas para evaluarlas en la propuesta, no las tapes con una lista de tecnologías elegidas sin contexto.

Cuando necesites comparar alternativas de desarrollo, podés conocer el servicio de sitios web y planes web de Ideasweb. Llevá el brief a esa conversación: ayudará a evaluar el alcance y las preguntas pendientes antes de decidir.