Antes de pedir presupuesto para una web no necesitas decidir la tecnología ni describir cada pantalla. Necesitas dejar claro para qué servirá, quién la utilizará, qué debe poder hacer, qué materiales existen y qué decisiones siguen abiertas.
Ese briefing permite que las propuestas respondan al mismo proyecto. También evita dos extremos: recibir un precio genérico sin alcance o invertir semanas en una especificación que debería resolver el profesional contratado.
El briefing mínimo cabe en una página
Empieza con estas siete respuestas:
| Campo | Pregunta que debes responder |
|---|---|
| Objetivo | ¿Qué debe cambiar cuando la web esté publicada? |
| Público | ¿Quién necesita entender, comparar o actuar? |
| Acción principal | ¿Qué quieres que haga una persona: contactar, reservar, comprar, registrarse o consultar? |
| Contenido | ¿Qué servicios, productos, casos o información deben aparecer? |
| Funciones | ¿Qué debe ocurrir además de mostrar información? |
| Punto de partida | ¿Qué dominio, marca, textos, imágenes, analítica o web anterior existen? |
| Restricciones | ¿Qué fecha, sistema, idioma, permiso o dependencia condiciona el proyecto? |
No conviertas preferencias visuales en objetivos. “Quiero una web moderna” admite demasiadas interpretaciones. “Quiero que una empresa pueda entender los tres servicios, revisar dos proyectos y enviar una consulta con el servicio identificado” permite diseñar y probar un recorrido.
Separa lo decidido, lo preferido y lo pendiente
Una buena petición de presupuesto no finge que todo está resuelto. Clasifica cada punto:
- Decidido: condiciones que el proyecto debe respetar.
- Preferencia: una dirección que puede cambiar si aparece una alternativa mejor.
- Pendiente: una decisión que necesita recomendación, prueba o información adicional.
Ejemplo ilustrativo: el dominio y los servicios pueden estar decididos; la estética puede ser una preferencia; la plataforma de contenidos y el formulario pueden quedar pendientes. Esta separación permite que el proveedor proponga sin sustituir decisiones que pertenecen al cliente.
Describe el público y la acción principal
“Todo el mundo” no ayuda a ordenar una web. Identifica primero a la persona cuya decisión importa y la situación en la que llega.
Puedes escribirlo así:
Una persona responsable de una pequeña empresa llega porque necesita construir una aplicación. Debe entender qué tipo de proyectos realizo, comprobar experiencia relacionada y poder contar su caso sin preparar requisitos técnicos.
Después define una acción principal. Puede haber acciones secundarias, pero la arquitectura necesita una prioridad. Si cada página intenta vender, informar, captar suscripciones, descargar un recurso y reservar una llamada con el mismo peso, la propuesta será difícil de evaluar.
Prepara el mapa de contenidos antes del diseño
Haz una lista de la información que ya existe y quién puede aprobarla:
- servicios o productos;
- descripción de la empresa o del profesional;
- proyectos, casos o muestras verificables;
- preguntas habituales;
- datos de contacto;
- textos legales;
- fotografías, ilustraciones, logotipo y recursos de marca;
- idiomas y responsables de traducción;
- contenido que debe migrarse desde una web anterior.
Indica qué material está listo, qué necesita revisión y qué debe crearse. No atribuyas automáticamente la redacción, las fotografías, el branding o el asesoramiento legal al desarrollo: cada propuesta debe decir quién aporta cada pieza.
Distingue páginas de funciones
Una página organiza información. Una función cambia el estado de algo: envía una solicitud, crea una cuenta, cobra, reserva, consulta datos, publica contenido o conecta otro sistema.
Para cada función responde:
- ¿Quién la utiliza?
- ¿Qué dato introduce o consulta?
- ¿Qué resultado espera?
- ¿Quién recibe o gestiona ese resultado?
- ¿Qué ocurre si falla?
- ¿Necesita una integración o una cuenta externa?
Un formulario de contacto sencillo y una aplicación con usuarios, permisos y pagos son proyectos distintos, aunque ambos funcionen en un navegador. Si las reglas propias dominan el alcance, conviene valorar si necesitas software a medida en lugar de una web principalmente informativa.
Identifica cuentas, accesos y propiedad
Registra quién controla actualmente:
- dominio y DNS;
- alojamiento;
- correo profesional;
- analítica y etiquetas;
- gestor de contenidos;
- repositorio o código anterior;
- servicios de formularios, reservas, pagos o automatización;
- perfiles de empresa que deban conectarse.
No envíes contraseñas dentro del briefing. Basta con indicar la existencia de la cuenta, su titular y cómo se concederá acceso cuando sea necesario.
Aclara también qué ocurrirá al terminar: titularidad del dominio, código y activos específicos; entrega de accesos; licencias de terceros; copias; mantenimiento; y procedimiento para cambiar de proveedor. Estos puntos deben aparecer en la propuesta o el contrato aplicable, no quedar asumidos.
Incluye accesibilidad, buscadores y medición desde el principio
La accesibilidad no es una revisión decorativa al final. Las WCAG del W3C organizan la accesibilidad web alrededor de contenido perceptible, operable, comprensible y robusto (W3C, consultado el 07/09/2026). Define qué nivel o requisitos debe cumplir el proyecto cuando exista una obligación o compromiso concreto.
Para buscadores, aporta los servicios, temas y ubicaciones que una persona debería comprender; no una lista repetitiva de palabras. Google explica que el SEO ayuda al buscador a entender el contenido y al usuario a decidir si debe visitar la página, sin garantizar que una URL vaya a indexarse o posicionarse (Google Search Central, consultado el 07/09/2026).
En medición, separa acciones de negocio y métricas técnicas. Por ejemplo:
- envío correcto de una consulta;
- clic en un canal de contacto;
- reserva confirmada;
- registro completado;
- error de entrega del formulario.
Una visita o un clic no equivalen por sí solos a un cliente. Define quién revisará los datos y qué decisión podrá tomar con ellos.
Escribe dentro, fuera y pendiente
Antes de comparar propuestas, crea tres listas:
Dentro
Páginas, funciones, migraciones, integraciones, materiales y comprobaciones imprescindibles para la primera entrega.
Fuera
Elementos que podrían ser útiles, pero no pertenecen al encargo actual: un área privada futura, una tienda, nuevos idiomas o una producción continua de contenidos.
Pendiente
Cuestiones que condicionan el precio o la solución: acceso a una API, calidad de los contenidos antiguos, responsable legal, catálogo definitivo o proveedor de reservas.
Puedes ampliar este método con la guía para definir alcance y criterios de aceptación.
Qué debería permitirte comparar una propuesta
Dos presupuestos solo son comparables si muestran, como mínimo:
- alcance y exclusiones;
- entregables y funciones;
- responsabilidades de contenido y aprobación;
- hitos y dependencias;
- forma de revisar y aceptar el resultado;
- tratamiento de cambios;
- dominio, alojamiento y servicios externos;
- propiedad, licencias y entrega de accesos;
- estabilización, soporte y mantenimiento;
- precio, impuestos y condiciones de pago.
Una lista de tecnologías no sustituye estas respuestas. La tecnología importa cuando cambia la capacidad, el mantenimiento, la dependencia o el coste del proyecto.
Plantilla breve para pedir presupuesto
- Objetivo de la web:
- Público principal:
- Acción principal:
- Páginas o contenidos necesarios:
- Funciones e integraciones:
- Material disponible:
- Web o sistemas existentes:
- Cuentas y accesos bajo control:
- Requisitos y restricciones:
- Fecha deseada y motivo:
- Decidido / preferido / pendiente:
- Responsable de aprobar:
No hace falta rellenar cada línea con certeza. Lo importante es hacer visibles las incógnitas para que la propuesta explique cómo se resolverán.