Cómo realizar una auditoría de arquitectura de información basada en tareas

Audite tareas representativas y todas sus rutas plausibles antes de evaluar menús aislados o dibujar un sitemap nuevo. Si la evidencia disponible se limita a una navegación abarrotada, páginas con muchas salidas y comentarios de que “nada se encuentra”, todavía no sabe si el problema es estructural. Puede faltar contenido, fallar una etiqueta, desaparecer un enlace contextual, responder mal la búsqueda o resultar inutilizable un control. Una auditoría basada en tareas sigue un resultado importante desde distintos puntos de entrada, registra lo que ocurre en cada decisión y conecta cualquier recomendación con evidencia que luego pueda volver a probarse.

¿Qué decisión debe informar la auditoría?

La auditoría debe diseñarse alrededor de una decisión limitada y explícita: reparar una sección, cambiar etiquetas, preparar una migración o determinar si existe evidencia para un rediseño más amplio. Defina también qué nivel de evidencia aceptarán quienes deciden. La arquitectura de información comprende organización, etiquetas y navegación que ayudan a las personas a encontrar información, reconocer dónde están y qué opciones tienen, y completar tareas. La auditoría examina si ese sistema de rutas respalda los resultados seleccionados en el sitio existente.

Delimite audiencias, metas, puntos de partida, tipos de página, dispositivos, idiomas, permisos y estados del recorrido cuando cambien materialmente las opciones disponibles. Las conclusiones solo deben aplicarse a esos contextos, no a un “usuario promedio” abstracto. Mantenga cuatro categorías separadas en el registro: hechos conocidos, conducta observada, hallazgos de inspección experta e hipótesis sin probar. Así evita presentar una sospecha razonable como si fuera una falla vista en usuarios.

• Incluya el resultado y las rutas del sitio que la decisión realmente puede cambiar.
• Excluya el inventario completo de contenido, la auditoría técnica de SEO y el diseño de una solución nueva.
• Trate la conformidad de accesibilidad como una evaluación distinta, aunque algunos criterios ayuden a inspeccionar rutas.
• Anote quién tomará la decisión, qué evidencia necesita y qué queda expresamente fuera del alcance.

¿Cómo se construye un conjunto representativo de tareas con evidencia?

Construya el conjunto como resultados reconocibles para las personas, sin revelar la etiqueta de destino ni la respuesta de navegación. La guía de GOV.UK recomienda aprender qué intentan hacer, cómo lo hacen actualmente, qué problemas encuentran y qué resultado necesitan. Para cada tarea, documente la audiencia, el desencadenante, los contextos iniciales, la condición de éxito, el destino previsto y la procedencia de la evidencia. Una tarea como “comparar las opciones disponibles para su organización” permite observar decisiones; “vaya a Soluciones” ya sugiere el camino.

Combine investigación previa, entrevistas, observación, analítica, consultas de búsqueda interna, solicitudes de soporte, comentarios y conocimiento del personal que atiende a usuarios. Esas fuentes no tienen el mismo peso: una consulta frecuente señala una pregunta, pero no demuestra intención, causa ni solución. Identifique las afirmaciones de partes interesadas y las suposiciones expertas como hipótesis hasta obtener evidencia de usuarios. Digital.gov documentó un estudio que derivó escenarios realistas de investigación anterior y revisó su cobertura antes de probarlos; sus cantidades no son una receta universal.

• Equilibre tareas frecuentes con tareas consecuentes, difíciles o desatendidas.
• Conserve la fuente y fecha de cada señal para que su procedencia no se pierda.
• Defina el resultado observable sin imponer una sola ruta válida.
• Revise la cobertura por audiencia, contexto y riesgo antes de reclutar o inspeccionar.

¿Qué debe registrar la hoja de tareas y rutas?

La hoja debe conectar cada tarea evidenciada con su resultado, puntos de entrada, rutas plausibles, señales inspeccionadas, conducta observada, diagnóstico, cambio propuesto y nueva prueba. No suponga que el recorrido empieza en el home. Incluya una página externa de llegada, una página de sección, un área autenticada y la búsqueda interna cuando sean contextos realistas. Trace rutas de navegación, enlaces contextuales y búsqueda por separado; una vía exitosa no demuestra que las demás funcionen en los contextos que importan.

En cada decisión, registre la señal visible, la expectativa que crea, el destino alcanzado y la posibilidad de reconocer y corregir una elección improductiva. El criterio 2-4-5 de WCAG 2.2 exige más de una forma de localizar una página dentro de un conjunto, excepto cuando sea resultado o paso de un proceso; entre las técnicas documentadas figuran enlaces relacionados, mapa del sitio, búsqueda y navegación integral. Este chequeo específico ayuda a inspeccionar alternativas, pero no certifica la accesibilidad del sitio.

Una auditoría de IA no pregunta si el sitemap se ve ordenado, sino si las personas alcanzan resultados reales por rutas que producen evidencia accionable.

¿Cómo se inspecciona la ruta completa y no solo los menús?

Inspeccione desde cada entrada material hasta el contenido o la acción que completa la tarea. Revise navegación global y local, hubs, índices, agrupaciones, encabezados, breadcrumbs u otras señales de ubicación, enlaces contextuales, búsqueda interna y destino final. En cada paso pregunte qué promete la señal, qué encuentra la persona y qué opción de recuperación aparece. Microsoft aconseja planificar según tareas y modelos mentales, y describe las etiquetas eficaces como precisas, familiares, concisas, escaneables y distinguibles; aun así, su claridad debe comprobarse en contexto.

Compruebe si la persona puede reconocer dónde está, qué nivel alcanzó, qué puede hacer después y cómo volver de una elección sin salida. El criterio 2-4-6 de WCAG 2.2 exige que los encabezados y etiquetas proporcionados describan tema o propósito. El criterio 3-2-3 aborda el orden relativo consistente de mecanismos de navegación repetidos, salvo que la persona inicie el cambio; no prohíbe navegación local. Repita tareas importantes en dispositivos, idiomas, permisos y estados solo cuando esos contextos alteren rutas o señales.

• Compare la promesa de cada etiqueta con el contenido real del destino.
• Busque cruces ausentes en el momento en que surge la necesidad, no solo enlaces desde niveles superiores.
• Examine consultas, relevancia de resultados, reformulaciones, confianza y finalización antes de declarar una falla de búsqueda.
• No interprete el uso de búsqueda como fracaso automático: puede ser la ruta preferida de algunas personas.

¿Qué método debe validar cada ruta incierta?

Elija el método según la pregunta de evidencia, no según la herramienta disponible. La inspección experta y los datos existentes localizan defectos probables, pero no permiten afirmar que usuarios observaron una falla. Use clasificación de tarjetas cuando dude de la agrupación esperada o del lenguaje de categorías. Digital.gov distingue la modalidad abierta, donde participantes crean y nombran grupos, de la cerrada, donde asignan contenido a categorías predefinidas. Ninguna de las dos valida por sí sola una ruta completa del sitio renderizado.

Use una prueba de árbol para aislar si la jerarquía y sus etiquetas permiten encontrar un destino sin la influencia del diseño visual. Puede descubrir categorías confusas, pero omite señales de página, controles, enlaces contextuales y resultados de búsqueda. Cuando la incertidumbre abarque esos elementos, la recuperación o la finalización, observe tareas en el sitio renderizado. NIST describe pruebas con usuarios y tareas representativos y evidencia posible como finalización, errores, tiempo, comentarios cualitativos y satisfacción; seleccione solo lo que responda a la decisión.

• Agrupación o vocabulario: clasificación de tarjetas.
• Encontrabilidad dentro de una jerarquía: prueba de árbol.
• Navegación, señales visuales, controles, enlaces, búsqueda y finalización: prueba de usabilidad basada en tareas.
• Problema probable aún no observado: inspección experta seguida de la validación apropiada.
• Diagnóstico de ambigüedad: rutas, retrocesos y explicaciones de participantes, no únicamente un porcentaje final.

No establezca de antemano una cantidad universal de tareas, participantes o clics. Dimensione el estudio según la decisión, la diversidad de audiencias y contextos, las consecuencias de equivocarse, la incertidumbre y la solidez de evidencia necesaria. Si varias personas alcanzan el destino por trayectorias diferentes, escuche sus razones: Digital.gov documenta cómo las rutas convergentes y divergentes ayudaron a localizar ambigüedades. Una ruta alterna puede ser válida; una finalización aparente también puede esconder una etiqueta mal entendida o baja confianza.

¿Cómo se convierten los hallazgos en cambios acotados o en un caso de rediseño?

Convierta cada hallazgo en un diagnóstico específico y recomiende la intervención más pequeña que la evidencia respalde. Clasifique primero la falla: cobertura si falta el contenido o la acción; entrada si un inicio probable no ofrece ruta; etiqueta si la señal promete otra cosa; agrupación si el destino aparece donde no se espera; orientación si no queda claro dónde se está; enlace contextual, búsqueda, consistencia o interacción cuando esos componentes explican el bloqueo. Así evita convertir todos los síntomas en una propuesta de navegación nueva.

Priorice con insumos visibles: importancia de la tarea, audiencias afectadas, frecuencia observada de la falla, consecuencia, solidez de evidencia y dependencias de remediación. No esconda esas decisiones detrás de una puntuación universal. La finalización, la ayuda, los errores, el tiempo, los retrocesos, las reformulaciones, la confianza y el razonamiento pueden informar el análisis, pero ninguna medida aislada decide un rediseño. Registre además el responsable, la hipótesis de cambio y la tarea exacta que servirá para volver a probarlo.

1. Corrija primero el contenido cuando la arquitectura conduce a un destino incompleto.
2. Repare una etiqueta o un enlace si la falla es local y la agrupación general sigue funcionando.
3. Reagrupe o reestructure una sección cuando el patrón se repita dentro de un ámbito definido.
4. Ajuste la búsqueda cuando las consultas relevantes devuelvan resultados ausentes, engañosos o difíciles de interpretar.
5. Considere un rediseño amplio solo ante fallas importantes, repetidas, observadas, estructurales y no reparables mediante cambios acotados.

Termine con una decisión de nueva prueba, no con un sitemap nuevo por defecto. Repita las tareas y rutas afectadas en los contextos pertinentes antes de declarar éxito. Involucre a un profesional experimentado en arquitectura de información o investigación UX cuando el conjunto de tareas, el diseño del estudio o las compensaciones estructurales superen la capacidad del equipo. Si aparecen dudas de accesibilidad, solicite una evaluación apropiada a un especialista calificado: esta auditoría y sus chequeos WCAG seleccionados no establecen la conformidad del sitio completo.