El menú no convence a nadie. El menú o deja llegar o esconde. Cuando un cliente nos pide “rediseñar la navegación”, casi siempre está pidiendo otra cosa: que dejen de perderse, que dejen de llamar para preguntar lo que ya está en la web, que el tratamiento o el producto estrella deje de vivir en el tercer nivel.
Un hamburguesa más fino no arregla eso. Un icono animado tampoco. La arquitectura de información web es el mapa: qué existe, cómo se llama, en qué orden y qué se sacrifica. El menú es solo la superficie de ese mapa. Si el mapa está mal, cualquier piel nueva repite el mismo laberinto.
Este artículo marca cuándo sí toca rediseñar el menú, cuándo basta relabelar, y cómo auditarlo sin convertir el kickoff en un taller eterno. Es trabajo de diseño UX/UI: criterio, no decoración de header.
Qué es de verdad la arquitectura de información web
Arquitectura de información no es “el menú”. Es el inventario de contenidos, la taxonomía, las etiquetas y los caminos entre páginas. El menú, el footer, los hubs y los cruces internos son manifestaciones. Si rediseñas solo el header, estás pintando el índice de un libro cuyo orden de capítulos sigue mal.
En la práctica, una IA sana responde tres preguntas en menos de cinco segundos: dónde estoy, qué hay aquí, cómo hago lo que vine a hacer. Las leyes UX que toda web debe aplicar (Jakob, Hick, proximidad) se rompen todas a la vez cuando el menú mezcla 14 destinos del mismo peso. No es un tema de “menos es más”. Es un tema de que el cerebro no compara 14 ítems equivalentes.
La memoria de trabajo no sostiene un menú plano de doce ítems del mismo peso. Agrupa o recorta; no “equilibres” añadiendo uno más por cada departamento.
Miller, The Magical Number Seven; aplicación habitual en IA (NN/g)
Cuándo rediseñar el menú — y cuándo no
Rediseñar el menú tiene coste: reaprender, redirects, contenidos huérfanos, guerra interna por “nuestra sección”. No lo hagas por estética. Hazlo cuando el mapa ya no coincide con las tareas.
| Señal | Gravedad | Qué hacer |
|---|---|---|
| Las etiquetas no se entienden en un test de 5 usuarios | Alta | Relabelar o reagrupar; no hace falta un recableado total |
| El 30%+ del tráfico interno entra por Google a URLs profundas | Media-alta | El menú no cubre las tareas; audita hubs, no solo el header |
| Cada departamento exige su ítem en primer nivel | Alta | Eso es organigrama, no IA. Recorta con tareas de usuario |
| El hamburguesa actual es feo pero las rutas funcionan | Baja | No rediseñes el mapa. Cambia el componente, no la estructura |
| Habéis añadido 3 productos y el menú tiene 11 destinos | Media | Toca agrupar. Un ítem más “porque es nuevo” es deuda de IA |
La regla que usamos en Truman: si el usuario encuentra y convierte, y el dolor es visual, no toques la IA. Si el usuario busca en el sitio, llama o abandona, el menú nuevo sin inventario es teatro. Eso se decide en el brief de un proyecto UX/UI, no en una sesión de “vamos a probar otra tipografía en el nav”.
Cómo auditar la IA en una semana, no en un trimestre
No necesitas un card sorting de 40 personas para saber si el menú está roto. Necesitas inventario, tareas y etiquetas dichas en voz alta por alguien que no haya diseñado la web.
En FIHGUV el problema no era “poner el logo más grande”. La Fundación de Investigación del Hospital General de València tiene proyectos, áreas y públicos distintos (profesionales, pacientes, instituciones). Si todo eso se aplasta en “Quiénes somos / Qué hacemos / Actualidad”, el investigador no encuentra la convocatoria y el visitante ocasional no entiende el encargo. La IA es el producto: acceso a información clave, no una home institucional genérica.
Tip técnico: etiquetas que se pueden decir en voz alta
Si no puedes leer el ítem del menú por teléfono y que la otra persona sepa qué hay detrás, la etiqueta está mal. “Soluciones” es un cajón. “Recursos” es un cajón. “Innovación” es un cajón. Sustituye por el objeto: Tratamientos, Restaurantes, Proyectos de investigación, Entradas, Equipo. El sistema de diseño puede unificar el componente del nav; no puede unificar un vocabulario cobarde.
No escondas lo que convierte
Hay una tentación elegante: menú corto, CTA único, el resto “se descubre”. En una web de servicios o de grupo, lo que convierte suele ser concreto. Reserva. Un centro. Un caso. Un formulario. Si eso no está en primer o segundo nivel —o como acción persistente—, estás diseñando para el organigrama.
En Grupo Candela la web tiene que dejar explorar la oferta gastronómica, llegar a cada restaurante y reservar. Si el menú privilegia “el grupo” y esconde los locales, el usuario hace lo que haría sin web: buscar el nombre del restaurante en Maps. El header no es un folleto corporativo. Es un despachador de tareas.
Primero la tarea
Luego el contenido
Al final, la empresa
Eso no significa mentir en el menú. Significa que “Sobre nosotros” rara vez merece el mismo peso que el objeto por el que alguien ha abierto la URL. La empresa se cuenta; no se pone a competir con la reserva.
Si quitas del menú todo lo que no es una tarea del usuario, ¿qué queda? Si queda poco, ese poco es tu IA real.
El menú móvil no es el de escritorio encogido
En escritorio puedes permitirte un mega menú si las columnas tienen títulos honestos. En móvil, cada ítem extra es un gesto. El error clásico es clonar el árbol completo dentro de un hamburguesa de 40 líneas. El segundo error es esconder el CTA de conversión detrás de ese hamburguesa.
Patrón que sostenemos: 4–6 destinos de primer nivel, un CTA persistente fuera del menú, y el resto en hubs, no en un acordeón infinito. Si un destino no aguanta estar fuera del nav, quizá no merecía página. O merecía estar enlazado en contexto (ficha, footer, bloque de cierre), no en el header de todas las URLs.
Cuando un cliente pide un menú nuevo, pregunto qué tarea está fallando. Si no saben decirla, no hay que rediseñar el nav: hay que sentarse a listar qué páginas existen y para quién. El hamburguesa es lo último que se dibuja.
Antes de rediseñar el menú, verifica esto
- ¿Tienes inventario real de URLs, no el mapa que “debería” existir?
- ¿Has listado 5–7 tareas de usuario y las has cronometrado sobre el menú actual?
- ¿Las etiquetas se entienden dichas por teléfono, sin contexto visual?
- ¿El ítem que convierte está en primer o segundo nivel, o como CTA fuera del nav?
- ¿El menú refleja tareas y no el organigrama de departamentos?
- ¿En móvil el CTA principal se ve sin abrir el hamburguesa?
- ¿Hay páginas huérfanas que solo viven porque “siempre han estado”?
- ¿Un tree test de 5 personas ajenas al proyecto acierta las tareas críticas?
Preguntas frecuentes sobre arquitectura de información y menús
¿Cuándo hay que rediseñar el menú de una web?
Cuando las tareas críticas fallan: la gente busca en el sitio, llama para preguntar lo que ya está publicado o no encuentra el objeto que convierte. Si el menú es solo feo y las rutas funcionan, cambia el componente, no el mapa. Rediseñar por estética obliga a reaprender y suele empeorar el SEO de las URLs profundas.
¿Cuántos ítems debe tener un menú de primer nivel?
Los suficientes para cubrir tareas, no departamentos. En la práctica, 4–7 destinos de primer nivel más un CTA. Por encima de eso, estás pidiendo una comparación que nadie hace. Agrupa en hubs con nombres de objeto (“Restaurantes”, “Proyectos”), no en cajones (“Soluciones”).
¿Qué diferencia hay entre arquitectura de información y el diseño del menú?
La IA decide qué existe, cómo se llama y cómo se llega. El menú es una vista de esa decisión. Puedes tener una IA correcta con un nav mediocre, y al revés: un nav precioso sobre un inventario caótico. Se audita primero el mapa; se diseña el componente después.
¿Cómo elijo entre mega menú, hamburguesa y nav plano?
Por densidad y dispositivo. Mega menú si hay grupos reales con títulos honestos y el usuario necesita comparar destinos. Nav plano si caben 5 ítems claros. Hamburguesa en móvil, con CTA fuera. Elegir el patrón antes de tener inventario es diseñar al revés.
