Cómo planificar un sitio web: la guía completa
La mayoría de los proyectos de desarrollo web no se retrasan porque el código fuera difícil. Se retrasan porque el plan era flojo: nadie acordó qué debía lograr el sitio, quién escribiría los textos ni qué significaba «terminado».
Esta guía cubre el trabajo de planificación previo al diseño y la construcción, en el orden en que realmente sirve, y las decisiones que salen caras si se cambian después.
Empiece por una tarea que el sitio deba cumplir#
Un sitio que debe hacerlo todo no suele lograr nada medible. Antes que nada, escriba la única acción que más importa: enviar un formulario, una llamada, una compra, una reserva, una descarga.
Todo lo demás —estructura de páginas, navegación, qué va en la parte visible, cuánto conviene gastar— se deduce de esa respuesta. Un sitio cuyo trabajo principal es generar consultas es un proyecto distinto de uno cuyo trabajo principal es vender 4.000 productos.
- Objetivo principal: la única acción que conservaría si solo pudiera conservar una.
- Objetivos secundarios: útiles, pero no como para sacrificar el principal.
- Cómo lo medirá: una cifra que pueda revisar el próximo trimestre, no «más tráfico».
- Lo que el sitio no necesita hacer: por escrito, para que quede fuera del alcance.
Si dos personas de su organización nombrarían objetivos principales distintos, ese desacuerdo aparecerá en la semana seis de la construcción. Resuélvalo en la semana cero, cuando cuesta una reunión en vez de una reconstrucción.
Sepa quién llega y a qué viene#
La investigación de público no tiene que ser un ejercicio formal. Lo que necesita es una descripción breve y honesta de los dos o tres grupos que de verdad visitan, con qué pregunta llega cada uno y qué les haría marcharse.
| Visitante | Llega preguntando | Se va porque |
|---|---|---|
| Comprador primerizo | ¿Esta gente puede hacer lo que necesito? | No hay pruebas, ni precios, ni claridad |
| Cliente recurrente | ¿Dónde está lo que necesito ahora? | La tarea está enterrada a tres clics |
| Alguien que compara | ¿En qué se diferencia de los demás? | Textos genéricos que valdrían para cualquier competidor |
| Un candidato a un puesto | ¿Cómo es trabajar aquí? | No hay página de empleo, o está desactualizada |
Decida las páginas antes que el diseño#
La estructura de páginas es lo más barato de cambiar sobre el papel y una de las cosas más caras de cambiar tras aprobar un diseño. Liste cada página, agrúpelas en secciones y marque cuáles hacen falta para el lanzamiento y cuáles pueden esperar.
El fallo habitual es una estructura que refleja su organigrama en vez de la tarea del visitante. Nadie llega buscando su «División de Soluciones»; llegan buscando lo que necesitan.
- Liste cada página que crea necesitar, una por línea, sin agrupar.
- Marque cada una como crítica para el lanzamiento o posterior. Sea estricto: casi todos los sitios se lanzan con menos páginas de las previstas.
- Agrupe las críticas en no más de cinco o seis secciones de primer nivel.
- Escriba la única frase que cada página debe transmitir. Si no puede, probablemente esa página no debería existir.
- Compruebe que el objetivo principal se alcanza en un clic desde cualquier página de primer nivel.
El contenido es la ruta crítica: planifíquelo primero#
Los textos, las fotografías y los datos de producto frenan más lanzamientos que cualquier problema técnico. La construcción termina y el sitio se queda seis semanas en preproducción esperando una página «Quiénes somos».
Decida ahora quién escribe cada página, quién la aprueba y cuándo vence, y trate esas fechas con la misma seriedad que los hitos de desarrollo. Si nadie tiene tiempo internamente, presupueste un redactor; sale más barato que un equipo de desarrollo parado.
- Asigne un responsable y una fecha a cada página de texto, no «marketing».
- Decida qué pasa con el contenido existente: migrar, reescribir o descartar. La mayor parte debería descartarse.
- Reserve la fotografía pronto: tiene el plazo más largo de toda la lista.
- Para una tienda, exporte y limpie los datos de producto antes de empezar, no durante.
- Acuerde quién da la aprobación final. Dos personas con la misma autoridad son un riesgo para el calendario.
Una prueba útil: si el sitio estuviera terminado mañana, ¿podría llenarlo? Si la respuesta es no, el contenido es su verdadera fecha límite.
Fije un rango de presupuesto y decida el enfoque de construcción#
La planificación termina con dos cifras y una elección: cuánto puede gastar, cuándo lo necesita en línea y si esto es una plantilla, un CMS o un desarrollo a medida. Esos tres puntos deciden con quién debería siquiera hablar.
| Enfoque | Encaja cuando | Riesgo principal |
|---|---|---|
| Creador de sitios | Sitio pequeño de presentación, sin requisitos inusuales | Choca con un techo y hay que empezar de nuevo |
| CMS (p. ej. WordPress) | Sitio de contenido, actualizaciones frecuentes por no desarrolladores | Proliferación de plugins y mantenimiento continuo |
| Plataforma de comercio | Venta de productos, necesidades de pago estándar | Comisiones de plataforma y personalización limitada |
| Desarrollo a medida | El sitio es el producto, o las integraciones descartan lo demás | Coste más alto, y el mantenimiento es suyo |
Preguntas frecuentes
¿Cuánto debería durar la planificación?
Para un sitio de empresa pequeña, una o dos semanas de trabajo real, no de tiempo transcurrido. Para una tienda o una aplicación, de tres a seis semanas, la mayor parte dedicada al inventario de contenido y a los datos de producto más que a documentos. Si la planificación se alarga meses, suele significar que el objetivo principal no está acordado y la conversación da vueltas.
¿Necesito un documento formal de requisitos?
Necesita algo escrito a lo que ambas partes puedan señalar, pero no tiene que ser largo. Una estructura de páginas, una lista de funciones dentro del alcance, una lista de cosas explícitamente fuera y un responsable de contenido por página evitarán más disputas que una especificación de cincuenta páginas que nadie lee. La lista de exclusiones es la parte que la gente se salta y la que salva el proyecto.
¿Debo planificar el diseño en esta fase?
Planifique la estructura, no el aspecto. Decidir qué páginas existen y qué debe lograr cada una es planificar; elegir colores y tipografías es diseñar, y hacerlo antes de que exista la estructura significa que el diseño se rehará en cuanto llegue el contenido real. Los wireframes son el término medio útil.
¿Y si los requisitos cambian a mitad del proyecto?
Cambiarán. Lo importante es haber acordado de antemano cómo se gestionan los cambios: quién puede pedirlos, quién los valora y si mueven la fecha de lanzamiento. Un proyecto con proceso de cambios se retrasa de forma controlada; uno sin él se retrasa en una discusión.
planificar sitio webplanificación webplan de proyecto webrequisitos sitio webestructura webplanificación desarrollo web
