Arquitectura primero: por qué diseñamos la estructura antes que la estética en cada proyecto

Qué significa arquitectura en el contexto de un sitio web

Cuando hablamos de arquitectura en el desarrollo web, nos referimos a la estructura subyacente que determina cómo se organiza un sitio, cómo se agrupa el contenido y cómo se mueven los usuarios por él. Es distinta de - y anterior a - el diseño visual de las páginas individuales.

La arquitectura incluye: el conjunto de tipos de página (¿qué clases de páginas necesita existir este sitio?), la estructura de navegación (¿cómo se relacionan esas páginas entre sí, y cómo se mueven los usuarios entre ellas?), el modelo de contenido (¿qué información necesita contener cada tipo de página?) y la estructura de URLs (¿cómo se direccionan las páginas, y qué comunica esa dirección?).

Ninguna de estas preguntas es visual. No tienen nada que ver con si la imagen principal debería ser de ancho completo o contenida, ni con si la paleta de colores debería ser cálida o fría. Son preguntas estructurales, y tienen consecuencias que duran toda la vida del sitio.

Qué pasa cuando la estética va primero

El enfoque alternativo más común - empezar con un diseño visual en Figma o similar - produce maquetas hermosas rápidamente. Esta es una razón por la que es popular. Un diseño visual pulido se siente como progreso y da a los clientes algo concreto a lo que reaccionar pronto en el proceso.

El problema es que las maquetas visuales toman decisiones estructurales implícitas que a menudo no sobreviven al contacto con el contenido real. El diseño de una página de inicio podría asumir un solo titular y un subtítulo de dos frases. Cuando el cliente envía su texto real, son cuatro párrafos. El diseño se rompe.

El diseño de una página de servicios podría asumir cinco servicios en una cuadrícula de tres columnas. El cliente tiene once servicios en cuatro categorías. La cuadrícula no funciona. Hay que diseñar una nueva maquetación, que puede entrar en conflicto con el lenguaje visual del resto del sitio.

Estos conflictos no son casos límite poco frecuentes. Son el resultado predecible de diseñar maquetaciones visuales antes de entender qué contenido necesitan acomodar. Cada revisión de diseño que ocurre porque el contenido real no encaja en la estructura asumida es un coste que la arquitectura primero evita.

Arquitectura de la información: el primer entregable

En Linekern, el primer entregable de cada proyecto es un documento de arquitectura de la información. Enumera cada página que el sitio necesita, describe lo que contiene cada página, define la jerarquía de navegación y especifica la estructura de URLs.

Esto suena a sobrecarga burocrática. En la práctica, lleva de dos a cuatro horas producirlo y ahorra mucho más que eso en ciclos de revisión. Obliga a que dos cosas ocurran simultáneamente: el cliente tiene que articular qué necesita decir realmente su sitio, y nosotros tenemos que entender el negocio lo suficientemente bien como para saber si la estructura propuesta lo servirá.

Descubrimientos comunes en esta etapa: el cliente cree que necesita una página por cada servicio, pero en realidad tiene tres líneas de servicio que deberían ser cada una una página, no quince servicios individuales como páginas separadas. O el sitio necesita una sección de recursos que no estaba en el briefing original. O la estructura de navegación que propuso el cliente enterraría las páginas comercialmente más importantes dos niveles más abajo.

Estos son problemas estructurales. Encontrarlos en un documento es barato. Encontrarlos en un diseño terminado - o peor, después del lanzamiento - es caro.

Zonas de contenido y tipos de página

Una vez definida la lista de páginas, diseñamos el modelo de contenido: ¿qué información necesita cada tipo de página, y en qué forma? Una página de servicio podría necesitar un titular, una descripción breve, una lista de características, una referencia a un caso de estudio y un CTA. Una página "sobre nosotros" necesita una sección narrativa, una sección de equipo con perfiles individuales y una declaración de valores. Una página de contacto necesita un formulario, información de ubicación y una sección de preguntas frecuentes.

Estas son las zonas de contenido - las regiones nombradas que cada página de un tipo dado contendrá. Definen cuáles serán los campos del CMS Kernset. También limitan el diseño visual: el diseño tiene que funcionar para cualquier contenido que vaya a contener una página de ese tipo, no solo para el ejemplo específico usado en la maqueta.

Esta es la conexión directa entre la arquitectura de la información y la estructura del CMS. Si definimos correctamente las zonas de contenido en la etapa de arquitectura, los campos del CMS que surgen de ellas serán coherentes y usables. Si nos saltamos la etapa de arquitectura y diseñamos los campos del CMS a partir de la maqueta visual, a menudo acabamos con campos que son demasiado restrictivos o demasiado flexibles para lo que los editores realmente necesitan hacer.

Jerarquía de navegación y recorridos del usuario

La estructura de navegación es una decisión arquitectónica separada de la lista de páginas. Un sitio puede tener cincuenta páginas organizadas en una clara jerarquía de tres niveles, o puede tener quince páginas con una navegación que obliga a los usuarios a hacer cuatro clics para llegar a cualquier destino. El número de páginas importa menos que la lógica estructural que las conecta.

Mapeamos los recorridos del usuario de forma explícita en la etapa de arquitectura: ¿cómo se mueve un cliente potencial desde la página de aterrizaje hasta el punto de conversión? ¿Dónde están los momentos de decisión? ¿Qué páginas ven la mayoría de los usuarios, y a cuáles solo acceden los usuarios que ya están comprometidos? Esto determina qué páginas deberían estar en la navegación principal, cuáles deberían ser accesibles a través de enlaces contextuales desde otras páginas y cuáles deberían encontrarse solo a través de la búsqueda.

La estructura de URLs se deriva de esta jerarquía. Las URLs limpias y descriptivas - /services/website-design/ en lugar de /?p=234 - sirven tanto a la claridad de navegación como al SEO. Deberían diseñarse deliberadamente, con el entendimiento de que cambiar las URLs después de que un sitio se lance requiere redirecciones 301 y conlleva riesgo de SEO.

Por qué esto conduce a mejores resultados

El enfoque de arquitectura primero produce mejores resultados por dos razones convergentes. La primera es la evitación de costes posteriores: los problemas estructurales encontrados pronto son baratos de arreglar; los problemas estructurales encontrados después del diseño visual o del desarrollo son caros. La segunda es que entender en profundidad la estructura de un sitio antes de diseñarlo produce diseños visuales que realmente funcionan con el contenido que contendrán.

Un diseño para una página de servicio que se concibió sabiendo que necesita acomodar entre tres y doce características, en categorías con nombres definidos por el usuario, se ve diferente de un diseño que asumió un número específico de características con nombres específicos. Es más robusto. Acomoda el rango real de contenido en lugar de solo el ejemplo usado en la maqueta.

La fase de arquitectura suele añadir una semana al inicio de un proyecto. Elimina mucho más de una semana de tiempo de revisión del medio y el final. Más importante aún, significa que el sitio que se construye es el sitio adecuado para el negocio, en lugar de un sitio que se veía bien en la maqueta y resultó tener problemas estructurales una vez que se añadió el contenido real.