En corto: Diseñar la navegación no consiste en dibujar un menú ni en copiar la estructura interna de una organización. Primero se necesita comprender qué contenidos y funciones se relacionan; después se definen las rutas y los mecanismos que permitirán encontrarlos.
Esta etapa utilizará inventarios, card sorting, tree testing y análisis de tareas cuando correspondan. Su resultado será un modelo de organización y navegación con rutas justificadas. Todavía no determinará la distribución final de la pantalla, pero sí responderá tres preguntas esenciales: ¿dónde estoy?, ¿de dónde vengo? y ¿adónde puedo ir?
Organización, navegación y flujo no son lo mismo
Los tres conceptos se relacionan, pero resuelven problemas diferentes:
| Concepto | Qué define | Ejemplo |
|---|---|---|
| Organización | Qué elementos pertenecen juntos y qué relación mantienen | Solicitudes agrupadas por estado |
| Navegación | Cómo se accede y se cambia entre espacios de información | Menú, enlace contextual o breadcrumb |
| Flujo de tarea | Qué acciones y respuestas permiten alcanzar un resultado | Revisar, solicitar corrección y confirmar el nuevo estado |
Una clasificación no se convierte automáticamente en menú. Tampoco todo paso de un proceso necesita una página. Esta distinción evitará que el sitemap intente representar al mismo tiempo la taxonomía, la interfaz y el comportamiento del sistema.
La etapa anterior aportó actores, tareas y escenarios. Ahora se utilizarán para decidir qué debe poder encontrarse y qué rutas necesita cada tarea.
Método para construir y evaluar la navegación
1. Preparar un inventario
Antes de elegir una técnica se necesita saber qué se organizará. El inventario puede incluir:
- Contenidos y documentos.
- Funciones y acciones.
- Objetos del dominio.
- Estados relevantes.
- Categorías existentes.
- Metadatos y relaciones.
- Elementos duplicados, ausentes u obsoletos.
No todo elemento del inventario terminará visible en la navegación. Algunos serán datos dentro de una pantalla, acciones contextuales o procesos ejecutados por el sistema.
Cada elemento deberá describirse con suficiente claridad para evitar clasificaciones basadas únicamente en palabras parecidas.
2. Formular una hipótesis de organización
La información puede organizarse mediante distintos criterios: tema, tarea, audiencia, estado, tiempo, ubicación o una combinación. La elección dependerá de los escenarios y del modo en que las personas reconocen el dominio.
La estructura interna del negocio puede aportar reglas y responsabilidades, pero no debe imponerse automáticamente al usuario. Un organigrama explica quién administra la información; no necesariamente cómo se espera encontrarla.
La hipótesis inicial deberá indicar:
- Grupos y elementos relacionados.
- Relación entre niveles.
- Criterio utilizado para agrupar.
- Contenido que podría pertenecer a más de un lugar.
- Términos todavía ambiguos.
3. Utilizar card sorting cuando exista incertidumbre de agrupación
En card sorting, las personas organizan tarjetas que representan contenidos o funciones. Puede aplicarse de tres maneras:
- Abierta: cada participante forma y nombra sus grupos.
- Cerrada: los grupos ya existen y se evalúa dónde se colocan los elementos.
- Híbrida: existen grupos iniciales, pero pueden proponerse otros.
La prueba abierta ayuda a descubrir posibles agrupaciones y vocabulario; la cerrada comprueba una clasificación propuesta. Como explica Nielsen Norman Group, el resultado genera ideas para una arquitectura, pero no entrega por sí solo la navegación definitiva. Es necesario interpretar diferencias, comentarios, necesidades del negocio y contenidos que admiten varias rutas.
Tampoco existe una cantidad universal de participantes. La recomendación histórica de 15 personas se relaciona con un estudio y un nivel de correlación determinados. El tamaño deberá considerar diversidad de perfiles, segmentos, análisis cualitativo o cuantitativo, riesgo y recursos. Cuando participen pocos usuarios únicos, se documentará el alcance de la evidencia en lugar de simular representatividad.
4. Construir una jerarquía candidata
Los patrones encontrados se combinan con las necesidades del proyecto para proponer una estructura. Se documentarán:
- Categorías y subcategorías.
- Contenidos que pueden encontrarse desde varias rutas.
- Niveles y relaciones laterales.
- Accesos globales, locales y contextuales.
- Elementos que necesitan búsqueda u otro mecanismo.
Una jerarquía profunda no es incorrecta por contar con más de tres niveles. El problema aparece cuando cada elección ofrece poca información, las categorías se solapan o la ruta no permite anticipar el destino.
5. Evaluar la jerarquía mediante tree testing
Tree testing presenta una estructura textual sin diseño visual y pide localizar contenidos o funciones mediante tareas. Sirve para evaluar una arquitectura nueva, comparar alternativas o detectar problemas en una estructura existente.
Las tareas deben describir una intención sin repetir el rótulo correcto. Por ejemplo:
Una solicitud fue devuelta porque falta información. ¿Dónde se consultaría qué datos deben corregirse?
Conviene observar:
- Éxito directo o después de retrocesos.
- Primera categoría elegida.
- Ruta seguida.
- Destinos incorrectos frecuentes.
- Tiempo, cuando aporte información.
- Explicación de la elección en sesiones moderadas.
Tree testing evalúa categorías, rótulos y encontrabilidad dentro de un árbol. No demuestra que una persona encuentre el mismo destino dentro de la interfaz final, porque no incluye posición, jerarquía visual, iconos ni información contextual. Esas decisiones deberán comprobarse con un prototipo.
6. Diseñar las rutas necesarias para las tareas
Con la jerarquía evaluada se construirá una matriz por tarea:
| Campo | Pregunta |
|---|---|
| Entrada | ¿Desde dónde puede comenzar la tarea? |
| Ubicación | ¿Cómo se reconoce el espacio actual? |
| Destinos | ¿Qué opciones pertinentes están disponibles? |
| Continuidad | ¿Cómo se avanza hacia el objetivo? |
| Retorno | ¿Cómo se regresa sin perder contexto o trabajo? |
| Alternativa | ¿Qué otra ruta puede resolver la necesidad? |
| Salida | ¿Cómo termina o se abandona la tarea? |
Estas rutas podrán materializarse después mediante navegación global, local, contextual o suplementaria. Títulos, estados activos, breadcrumbs, enlaces relacionados y buscadores son mecanismos posibles, no respuestas obligatorias.
Las pautas de navegabilidad de WCAG 2.2 también recuerdan la importancia de encontrar contenido, conocer la ubicación y disponer de destinos comprensibles, especialmente cuando la percepción del espacio visual es limitada.
Ejemplo: sistema interno de solicitudes
El escenario prioritario indica que una analista necesita revisar una solicitud y decidir si solicita una corrección o la envía a formalización.
El inventario identifica: lista de solicitudes, solicitud, datos, documentos, bloqueos, comentarios, historial, responsables, estados y acciones. El card sorting puede ayudar a descubrir qué información se percibe como parte de la solicitud y qué elementos se consideran seguimiento. El tree testing puede comprobar dónde se buscarían los bloqueos o un contrato ya formalizado.
Una ruta candidata sería:
- Entrar desde “Solicitudes pendientes”.
- Abrir una solicitud por identificador.
- Consultar su estado, bloqueos y datos relacionados.
- Abrir información secundaria sin perder la solicitud actual.
- Elegir una acción permitida.
- Recibir confirmación y regresar a la lista o continuar con la siguiente solicitud.
La ruta todavía no indica si la información aparecerá en pestañas, paneles, acordeones o una sola página. Esa traducción espacial corresponderá a la etapa 6.
Entregable
La etapa concluye con:
- Inventario depurado.
- Modelo de organización y jerarquía.
- Resultados e interpretación de las pruebas.
- Matriz de rutas por tarea.
- Decisiones, alternativas y preguntas pendientes.
El sitemap puede formar parte del entregable, pero no debe sustituir la explicación de cómo una persona completa una tarea.
Qué deja resuelto para la interacción
La navegación establece qué espacios existen, cómo se relacionan y qué rutas deben estar disponibles. También identifica dónde se necesitan señales de ubicación, retorno o acceso alternativo.
No decide todavía la prominencia visual de cada mecanismo ni su comportamiento completo. Tampoco resuelve el lenguaje definitivo: las categorías y acciones deberán comprobarse como rótulos comprensibles.
Ejercicio
Seleccionar ocho elementos de un producto y elaborar:
- Una hipótesis de agrupación.
- Dos tareas de tree testing que no revelen el rótulo esperado.
- Una matriz de ruta para la tarea principal.
- Tres decisiones que todavía requieran validación contextual.
Conclusión
Una navegación útil no nace del menú, sino de comprender contenidos, relaciones y tareas. Card sorting puede descubrir modelos posibles; tree testing permite evaluar una jerarquía; el diseño debe integrar esos resultados con el contexto y las restricciones del sistema.
La siguiente etapa trabajará el lenguaje de esa arquitectura. No bastará con colocar nombres breves: cada rótulo deberá permitir anticipar qué información, acción o estado representa.
Leave a Comment