¿Cómo planificar un proyecto web?

El plan de un sitio nace antes de diseñar las pantallas

Para planificar bien un sitio web hay que establecer el objetivo de negocio, las tareas de la audiencia, el alcance de contenidos y funciones, la responsabilidad del equipo, las limitaciones técnicas y criterios de aceptación medibles. El resultado debería ser un brief de proyecto breve y un backlog ordenado, no una colección de inspiraciones visuales.

El plan no debe anticipar cada decisión. Debe eliminar las incógnitas más costosas antes de crear wireframes y código. Así el equipo sabe qué construye en la primera versión, quién aporta los datos y contenidos, y cómo sabrá que el sitio funciona mejor que el anterior.

1. Nombra el problema y el objetivo de negocio

«Necesitamos una web moderna» no es un objetivo. Empieza por un problema observable: la audiencia no entiende la oferta, las consultas valiosas llegan por teléfono en vez de por el formulario, el equipo no puede actualizar el contenido por sí mismo o la tienda exige transcribir manualmente los pedidos.

Después, anota el cambio esperado y cómo lo medirás. Algunos objetivos de ejemplo son:

• aumentar el número de consultas que cumplen los criterios comerciales;
• reducir el tiempo para encontrar documentación o contacto;
• trasladar una atención repetitiva al autoservicio;
• poner en marcha ventas para un nuevo grupo o mercado;
• reducir la publicación de una oferta nueva de varios días a una hora.

Cada objetivo necesita un valor de partida. Conserva los datos de la analítica actual, CRM, buscador interno y conversaciones con clientes. No elijas un indicador solo porque sea fácil de leer. El número de visitas por sí solo no mostrará si el sitio atrae a las empresas adecuadas y las ayuda a decidir.

2. Describe a la audiencia y sus tareas más importantes

No hace falta crear una persona ficticia con nombre, coche y café favorito. Necesitas información que afecte al diseño: situación de la persona, sus conocimientos, limitaciones, criterios de elección y la tarea que quiere realizar.

Para cada tipo clave de usuario, anota:

• de dónde llega al sitio y qué sabe ya;
• con qué lenguaje describe el problema;
• qué información necesita antes de actuar;
• qué genera riesgo o desconfianza;
• qué dispositivo y condiciones de uso son habituales;
• qué debería ocurrir tras la visita.

Las fuentes son las conversaciones comerciales, solicitudes de soporte, términos de búsqueda, estudios de usabilidad y el comportamiento en el sitio existente. Separa las necesidades del cliente de los deseos de los interesados internos. Una nueva sección sobre la estructura de la empresa puede importar a dirección, pero no necesariamente ayuda a la audiencia a elegir un servicio.

3. Haz un inventario del sitio actual

En una renovación, no empieces con una hoja en blanco. Reúne URL, tráfico, consultas, enlaces externos, contenidos, archivos, formularios, integraciones y elementos que usa el equipo. Marca qué debe conservarse, mejorarse, combinarse o eliminarse.

El inventario protege de perder materiales valiosos y tráfico orgánico. También revela deuda técnica: varias versiones del mismo logotipo, un propietario desconocido del dominio, un formulario que envía datos a una bandeja inactiva o una integración que nadie sabe probar.

Antes de transferir accesos, ordena la propiedad de las cuentas. El dominio, hosting, analítica, repositorio, sistema de contenidos y licencias deben pertenecer a la empresa, y los proveedores recibir permisos individuales que puedan revocarse. No escribas contraseñas en el brief ni en una hoja compartida.

4. Fija el alcance y las prioridades de la primera versión

Divide los requisitos en tareas de usuario, funciones y contenidos. «Integración con CRM» es demasiado amplio: hay que indicar qué datos fluyen, en qué dirección, cuándo, quién gestiona un error y qué pasa sin conexión.

Ayuda una clasificación sencilla:

Prioridad	Significado	Pregunta de control
Imprescindible	Sin ello el sitio no cumple el objetivo principal o un requisito.	¿Se puede lanzar el sitio con seguridad sin esto?
Importante	Mejora claramente el resultado, pero tiene un atajo en la primera versión.	¿Cuál es el coste de aplazarlo una etapa?
Más adelante	Idea que se validará después de recoger datos.	¿Qué señal justificará la inversión?
Fuera de alcance	No pertenece al proyecto de forma consciente.	¿Quién y cuándo puede reabrir la decisión?

Anotar los elementos fuera de alcance es tan importante como la lista de funciones. Protege el calendario de los «pequeños añadidos» que juntos se convierten en un proyecto nuevo.

5. Asigna roles y derechos de decisión

Incluso un proyecto pequeño necesita una persona responsable del resultado por parte de la empresa. Reúne la información, resuelve comentarios contradictorios y aprueba las etapas siguientes. No tiene que hacer todo el trabajo, pero no puede ser un comité sin propietario.

En un proyecto suelen aparecer estas responsabilidades:

• propietario de negocio: objetivo, presupuesto y decisiones de alcance;
• dirección de proyecto: calendario, dependencias y flujo de información;
• experto de dominio y editor: hechos, contenido y coherencia lingüística;
• UX/UI: arquitectura de información, recorridos y sistema visual;
• desarrollo: tecnología, integraciones, rendimiento y despliegue;
• SEO/analítica: visibilidad, migración de direcciones y plan de medición;
• QA: escenarios de prueba, accesibilidad y criterios de aceptación;
• mantenimiento: monitorización, actualizaciones, copias y respuesta a fallos.

Una persona puede desempeñar varios roles, pero una decisión no debería tener varios propietarios equivalentes. Acordad también los plazos para el feedback y cómo se resuelven las observaciones. Un feedback consolidado es más rápido que comentarios separados y contradictorios de cada departamento.

6. Diseña la arquitectura y el contenido juntos

El mapa del sitio nace de las preguntas de la audiencia y del modelo de oferta, no del organigrama interno. Esboza primero los recorridos principales: de dónde viene el usuario, cómo reconoce el servicio correcto, qué necesita para comparar y qué paso realiza.

Para cada dirección prevista, define:

• la audiencia e intención principales;
• un único trabajo que debe realizar la página;
• el mensaje clave y las pruebas necesarias;
• la persona propietaria del contenido y la fecha de entrega;
• el siguiente enlace o acción lógica;
• el modo de evaluarla después de publicar.

Escribe contenido de trabajo antes de pulir los wireframes. Los nombres, números, tablas y reservas reales revelan problemas que no se ven con texto de relleno. El diseño debe acomodar de forma flexible una versión corta y otra larga, y la edición debe mantener la jerarquía, no adaptar el significado a un espacio casual.

7. Acordad la dirección visual y la accesibilidad

Reúne el logotipo actual, fuentes, paleta, fotos, licencias y reglas de marca. Si la empresa no tiene sistema, establece los roles mínimos de tipografía, colores, iconos e imágenes. Un moodboard puede ayudar a nombrar la dirección, pero no sustituye un diseño con contenido real.

Incluye los requisitos de accesibilidad en el brief, no en la lista final de correcciones. Define el nivel de conformidad objetivo, manejo por teclado, estructura de encabezados, contraste, mensajes de error, alternativas a los medios y comportamiento al ampliar. El estándar actual del W3C es WCAG 2.2; el alcance legal de una organización concreta conviene establecerlo con un especialista.

8. Describe la tecnología mediante requisitos

No elijas un sistema solo porque el equipo conozca el nombre de una herramienta. La tecnología debe encajar con la frecuencia de publicación, permisos, integraciones, requisitos de rendimiento, competencias de mantenimiento y evolución prevista.

En el brief anota, entre otras cosas:

• quién editará el contenido y con qué frecuencia;
• qué roles y aprobaciones de publicación se necesitan;
• con qué sistemas intercambia datos el sitio;
• cuáles son los requisitos de localización e idiomas;
• cómo son la copia de seguridad, la restauración y el plan de contingencia;
• quién supervisa seguridad, errores y disponibilidad del servicio;
• cómo se pueden exportar los datos y cambiar de proveedor.

Evalúa el hosting en el contexto de la arquitectura elegida y la carga. Más importantes que el número comercial de «gigabytes» son la estabilidad, región de datos, posibilidad de escalar, monitorización, soporte y un proceso de restauración comprobado.

9. Construye un calendario a partir de dependencias, no de deseos

Descompón la fecha de lanzamiento en decisiones, contenidos, diseño, implementación, integraciones, migración, pruebas y correcciones. Señala dependencias: no se puede aprobar una calculadora sin reglas de negocio ni probar un envío sin configurar el dominio y el buzón.

El presupuesto debe incluir algo más que la creación del sitio. Considera investigación, edición, fotos, licencias, migración de datos, integraciones, hosting, herramientas, pruebas, formación y los primeros meses de mantenimiento. Añade una reserva para riesgos que se han nombrado, pero aún no pueden presupuestarse con precisión.

En lugar de aprobar todo el proyecto solo al final, fija puntos de control: brief, arquitectura, dirección visual, prototipo clave, versión de prueba y preparación para publicar. Cada etapa debe tener una persona que aprueba y una lista cerrada de criterios.

10. Anota los criterios de aceptación y el plan de lanzamiento

«El sitio funciona» no es un criterio suficiente. Para las funciones importantes, prepara escenarios: el usuario envía un formulario correcto, recibe confirmación, el registro llega al sistema adecuado y el equipo sabe gestionar un error. Comprueba distintos dispositivos, teclado, conexión lenta, datos vacíos y contenido extremadamente largo.

El plan de lanzamiento debe incluir la persona propietaria del dominio y DNS, una copia de la versión actual, el mapa de redirecciones, configuración de analítica, monitorización, personas disponibles el día de publicación y condiciones para revertir el cambio. En una migración conserva las direcciones valiosas o redirígelas a los equivalentes más cercanos; no envíes todo a la página de inicio.

La publicación no termina el proyecto. Acordad un periodo de estabilización, cómo informar de errores, la responsabilidad de actualizar contenidos y la primera revisión de resultados. Algunas hipótesis solo se pueden verificar con tráfico real.

¿Qué debe contener el brief de un sitio web?

Antes de enviar una consulta a un proveedor, comprueba que el documento contiene:

1. problema, objetivo, métrica y valor de partida;
2. grupos de audiencia y tareas más importantes;
3. alcance de la primera versión y elementos excluidos conscientemente;
4. mapa de contenidos, funciones, datos e integraciones;
5. materiales de marca disponibles y requisitos de accesibilidad;
6. roles, propietarios de decisiones y forma de reunir feedback;
7. limitaciones tecnológicas, legales y organizativas;
8. presupuesto, fecha esperada y dependencias críticas;
9. criterios de aceptación, migración y preparación para el lanzamiento;
10. modelo de mantenimiento tras la publicación.

Un buen proveedor seguirá haciendo preguntas. La diferencia es que la conversación empezará por el objetivo y el riesgo, no por adivinar el número de subpáginas. Si necesitas recorrer esta etapa junto con un equipo de proyecto, consulta cómo es nuestro diseño y planificación de producto digital. Las decisiones siguientes se describen en la guía cómo crear un sitio web paso a paso.