Para contratar el diseño de una web no necesitás llegar con todas las soluciones. Sí conviene poder describir el objetivo, el contenido disponible y las responsabilidades que esperás delegar. Esa base permite comparar propuestas por lo que incluyen, en lugar de comparar solamente una cantidad de páginas o una referencia visual.
El alcance se puede construir junto con quien diseña. Lo importante es que las dudas no desaparezcan dentro de una frase como “web completa”. Esa expresión puede incluir diseño, implementación, redacción y mantenimiento para una persona, y solamente pantallas para otra. Aclararlo temprano evita decisiones tomadas sobre expectativas diferentes.
Qué debería poder hacer quien visita la web
Definí una acción principal: consultar por un servicio, evaluar un producto, comprar o encontrar información. Después explicá qué necesita saber la persona antes de hacerla. Una web que recibe consultas debe aclarar qué se ofrece, a quién le sirve y cómo continúa la conversación; no alcanza con tener un botón de contacto.
También podés registrar problemas de la web actual con ejemplos concretos. “El catálogo no muestra las variantes” es más útil que “se ve vieja”. Si tenés datos, describí qué muestran y sus límites. Si no, presentá la observación como una hipótesis que necesita revisión. No hace falta prometer una mejora medida para definir un problema.
Páginas, recorridos y funciones
Una lista de páginas es un comienzo, no un alcance completo. Dos sitios con cinco páginas pueden tener complejidades muy distintas. Importan los recorridos y sus estados: buscar, filtrar, enviar una consulta, editar un contenido o comprar una variante. Cada función necesita condiciones de uso, errores y una forma de mantenimiento.
Separá lo imprescindible de lo que podría incorporarse más adelante. Si una función se posterga, dejá por escrito qué no se va a diseñar ni implementar en esta etapa. También conviene identificar dependencias: acceso a sistemas, documentación de integraciones, aprobación de contenidos o decisiones comerciales que alguien debe tomar.
Diseño, implementación y contenido
Diseño
Puede incluir arquitectura, flujos, wireframes, interfaz, componentes y prototipo, según el proyecto. La propuesta debería explicar cuáles se entregan y con qué profundidad. Un archivo de pantallas no demuestra por sí solo que se investigó o validó el recorrido. Esas actividades necesitan un alcance específico y participación de personas adecuadas.
Implementación
Es convertir la propuesta en una web funcional dentro de una plataforma o base técnica. Incluye decisiones que no siempre se ven en una captura: edición, recursos, comportamiento responsive y conexiones. Acordá quién configura dominio, formularios y accesos, y quién comprueba que la entrega funciona fuera del entorno de trabajo.
Producción de contenido
Redacción, fotografía, material de proyectos y carga inicial no deberían quedar implícitos. Definí quién produce cada pieza, quién la aprueba y en qué formato llega. Un diseño puede necesitar contenido realista antes de estar terminado. Si se trabaja con ejemplos, deben identificarse y reemplazarse antes de publicar como información del negocio.
Una lista para comparar propuestas
- Objetivo y problemas que se abordan, con exclusiones explícitas.
- Páginas, plantillas y recorridos incluidos en la etapa.
- Versiones responsive, componentes y estados que se entregan.
- Investigación o validación prevista, si corresponde.
- Formato del prototipo y documentación para implementar.
- Plataforma, funciones, integraciones y edición de contenidos.
- Responsables de textos, imágenes y carga inicial.
- Criterios de revisión, correcciones y aceptación de la entrega.
- Accesos, capacitación, soporte y mantenimiento posterior.
La lista no exige que todo esté incluido. Sirve para saber qué estás comparando. Una propuesta de diseño puede ser correcta sin implementar el sitio, siempre que eso esté claro. Lo problemático es interpretar una exclusión como una tarea cubierta y descubrirla cuando ya se necesita publicar.
Ejemplo hipotético: una empresa de capacitación
Una empresa quiere presentar cursos y recibir consultas de organizaciones. Puede pedir “home, cursos y contacto”, pero el recorrido incluye elegir modalidad, revisar destinatarios y consultar por una edición. Si cada curso cambia con frecuencia, también necesita una forma consistente de actualizarlo. Esas necesidades deberían aparecer en el brief.
La empresa podría aportar descripciones y fotografías propias; quien diseña organizaría la oferta y las fichas; la implementación incorporaría una colección editable y un formulario con el curso seleccionado. Un sistema de inscripción y pagos quedaría fuera de esa etapa. Así las responsabilidades y las exclusiones son visibles antes de discutir la composición de la home.
Los tiempos dependerían de contenido, revisión y acceso a la plataforma. En lugar de inventar una fecha ideal, conviene acordar hitos y qué información necesita cada uno. Si la aprobación de cursos se demora, el cronograma tiene una dependencia concreta que se puede conversar, no una falla atribuida automáticamente al diseño.
La entrega no termina en una URL
Definí quién actualiza información, revisa consultas y mantiene dependencias. Una web puede necesitar cambios de texto muy simples y tareas técnicas menos frecuentes. Conviene distinguirlas y no suponer que el equipo hará ambas. También hay que documentar cómo recuperar accesos y a quién consultar si una función deja de responder.
La plataforma debería elegirse con esas responsabilidades en mente. Revisá cómo comparar Framer y WordPress, usá las preguntas del brief inicial y comprobá qué entregables puede incluir UX/UI. Para dar el primer paso, prepará objetivo, contenido y funciones necesarias; con eso podemos conversar sobre un alcance de diseño web sin convertir una lista de deseos en compromisos ambiguos.
