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

Antes de redibujar el mapa del sitio, audita tareas representativas y todas las rutas plausibles que llevan a su resultado. Un menú saturado, una página con muchas salidas o varias quejas de que algo no se encuentra apenas señalan dónde investigar: no demuestran que toda la estructura esté rota. El recorrido puede fallar porque falta contenido, una etiqueta promete otro destino, no existe un vínculo en el momento oportuno, la búsqueda entrega resultados pobres o un control impide continuar. Seguir la tarea de principio a fin permite distinguir esas causas y reservar el presupuesto de migración o rediseño para cambios que la evidencia realmente sostiene.

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

La auditoría debe diseñarse para resolver una decisión acotada: reparar una sección, cambiar etiquetas, preparar una migración o determinar si existe evidencia para un rediseño más amplio. La arquitectura de información comprende organización, etiquetas y navegación que ayudan a encontrar información, entender la ubicación y las opciones disponibles, y completar tareas. Por ello, la unidad de análisis no es una página aislada ni la apariencia ordenada del mapa del sitio, sino la capacidad del sistema de rutas para apoyar resultados seleccionados.

Documenta el alcance antes de inspeccionar la interfaz. Especifica audiencias, metas, contextos de entrada, tipos de página, dispositivos, idiomas, permisos y estados de la jornada incluidos. Una conclusión obtenida en la versión pública de escritorio no puede extenderse automáticamente al portal autenticado, al sitio móvil o a otra edición regional. Conserva por separado los hechos conocidos, el comportamiento observado, los hallazgos de inspección experta y las hipótesis pendientes de prueba.

• Decisión: qué aprobación, corrección o inversión deberá orientar el resultado.
• Cobertura: qué tareas, públicos, canales, estados y versiones se examinarán.
• Evidencia mínima: qué observaciones permitirán aceptar, rechazar o acotar una recomendación.
• Límites: qué preguntas corresponden a otra evaluación especializada.

Una auditoría de tareas no sustituye un inventario de contenido, una auditoría técnica de SEO, una evaluación integral de accesibilidad ni el trabajo de diseño. Puede descubrir preguntas que deban enviarse a esas disciplinas, pero su encargo es diagnosticar si las rutas existentes apoyan las tareas elegidas. Esta separación evita convertir una observación local en una conclusión sobre todo el sitio y aclara qué equipo debe investigar el siguiente paso.

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

El conjunto se construye describiendo resultados que las personas reconocerían, sin revelar la sección, la etiqueta o la ruta que el equipo supone correcta. En vez de pedir “ve a Recursos”, plantea el resultado que necesita conseguirse y define cómo se reconocerá su finalización. La guía de GOV.UK recomienda comprender qué intentan hacer las personas, cómo lo hacen ahora, qué problemas enfrentan y qué resultado necesitan; esa procedencia debe quedar asociada con cada tarea.

Combina investigación previa, analítica, consultas de búsqueda interna, solicitudes de soporte, retroalimentación, entrevistas, observación y conocimiento del personal que trabaja directamente con usuarios. Estos insumos no tienen el mismo peso. Una secuencia de clics o una salida señala un punto para investigar, pero no revela por sí sola la intención, la causa o la corrección apropiada. Registra las afirmaciones de áreas internas y las inferencias expertas como hipótesis mientras no exista evidencia de usuarios que las respalde.

• Incluye tareas frecuentes, pero también tareas consecuenciales, difíciles o desatendidas.
• Anota audiencia, detonante, contexto inicial, resultado exitoso y destino esperado.
• Vincula cada tarea con su fuente y fecha para conservar la procedencia.
• Revisa que el conjunto cubra necesidades distintas, no variaciones de una sola jornada.

Digital.gov documentó un estudio que derivó escenarios realistas de investigación anterior y revisó su cobertura antes de probarlos. La lección transferible es el proceso, no las cantidades de aquel caso. Tu muestra de tareas debe responder a la decisión y a la diversidad relevante del sitio. Si una tarea sólo proviene de una petición ejecutiva, puede permanecer en el registro, siempre que aparezca claramente como supuesto por validar y no como necesidad demostrada.

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

La hoja debe conectar, en un solo registro, la evidencia de la tarea, el resultado esperado, las rutas plausibles, las pistas inspeccionadas, el comportamiento observado, el diagnóstico y la prueba posterior. Empieza por contextos realistas: una página encontrada en un buscador externo, una portada de sección, un área autenticada, un vínculo contextual o una consulta interna. No supongas que todas las personas llegan por la página de inicio ni que una ruta exitosa funciona igual en cualquier contexto.

En cada punto de decisión anota la pista visible, la expectativa que crea, el destino alcanzado y la posibilidad de reconocer y corregir una elección equivocada. Mapea navegación global y local, hubs, agrupaciones, enlaces contextuales y búsqueda. El criterio 2,4,5 de WCAG 2,2 contempla más de una forma de localizar páginas dentro de un conjunto, con una excepción para resultados o pasos de procesos; entre sus técnicas aparecen vínculos relacionados, mapas del sitio, búsqueda y navegación integral.

• Dibuja por separado las rutas de entrada externa, exploración, vínculos contextuales y búsqueda.
• Registra también los callejones sin salida, retrocesos, reformulaciones y recuperaciones.
• Mantén la evidencia al lado del diagnóstico para que una recomendación no pierda su origen.
• Añade responsable, dependencia y condición de retest cuando se acuerde una corrección.

Una auditoría de IA no pregunta si el mapa luce ordenado, sino si una persona puede llegar a un resultado útil por rutas reales y con evidencia accionable.

WebChorus Editorial Team

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

La ruta completa se inspecciona recorriendo cada componente que puede prometer, orientar, desviar o completar la tarea. Revisa la página de entrada, la navegación global y local, los índices, las agrupaciones, los encabezados, las migas de pan u otras pistas de ubicación, los vínculos dentro del contenido, la búsqueda y el destino final. Confirma no sólo que el destino existe, sino que contiene la información, acción o estado necesarios para reconocer que la tarea terminó.

Evalúa cada etiqueta por la expectativa que genera frente a las opciones vecinas y por su correspondencia con el destino. Microsoft recomienda planear la navegación desde las tareas y modelos mentales de los usuarios, y favorece etiquetas precisas, familiares, concisas, escaneables y distinguibles. Además, el criterio 2,4,6 de WCAG 2,2 exige que los encabezados y etiquetas proporcionados describan su tema o propósito. Una etiqueta breve no es automáticamente clara: debe funcionar en su contexto.

• ¿La persona entiende dónde está y qué nivel de la estructura alcanzó?
• ¿Las opciones siguientes son distinguibles y mantienen la promesa de sus etiquetas?
• ¿Existe una recuperación comprensible después de una elección improductiva?
• ¿La misma tarea conserva rutas útiles al cambiar dispositivo, idioma, permiso o estado?
• ¿El destino permite completar y confirmar el resultado?

Compara también los mecanismos repetidos entre páginas representativas. El criterio 3,2,3 de WCAG 2,2 trata su orden relativo consistente, salvo cambios iniciados por el usuario, sin prohibir navegación local o secundaria. Por otra parte, no diagnostiques el uso de búsqueda como fracaso del menú: puede ser una ruta preferida y válida. Investiga la consulta, sus reformulaciones, la relevancia de resultados, la confianza en el destino y la finalización antes de decidir dónde está la falla.

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

El método debe corresponder a la pregunta que sigue abierta, no a la herramienta que el equipo acostumbra usar. La inspección experta y la evidencia conductual localizan defectos probables, pero un problema detectado por especialistas todavía no es una falla observada en usuarios. Formula primero la incertidumbre: si afecta la agrupación, la jerarquía, las etiquetas o la interacción completa. Después selecciona el método que aísle esa duda con la menor ambigüedad posible.

• Clasificación de tarjetas: investiga agrupaciones esperadas y lenguaje de categorías; no valida una ruta renderizada.
• Prueba de árbol: aísla la encontrabilidad mediante jerarquía y etiquetas, pero omite gran parte de la interfaz.
• Prueba de usabilidad basada en tareas: examina navegación visible, pistas de página, controles, vínculos, búsqueda, recuperación y finalización.
• Inspección experta: plantea hipótesis y prepara escenarios; no sustituye la observación de participantes.

NIST describe las pruebas de usabilidad mediante usuarios representativos que realizan tareas representativas, con evidencia posible como finalización, errores, tiempo, comentarios cualitativos y satisfacción. Para esta auditoría también pueden observarse ayuda, giros equivocados, retrocesos, reformulaciones y confianza en el destino. No todos los estudios necesitan todas las medidas: elige las que respondan a la decisión y conserva el razonamiento del participante, porque completar una tarea no siempre significa que la ruta haya sido clara.

Digital.gov muestra que las rutas divergentes y las explicaciones pueden revelar agrupaciones o etiquetas ambiguas incluso si algunas personas encuentran el destino. Aun así, una divergencia no equivale automáticamente a error; puede representar una alternativa válida. Tampoco existe en las autoridades citadas una cantidad universal de tareas o participantes. Define el alcance según la decisión, la diversidad de audiencias, el riesgo de las tareas, la incertidumbre pendiente y la solidez de evidencia necesaria para actuar.

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

Los hallazgos se convierten en decisiones cuando cada síntoma recibe un modo de falla preciso y la intervención más pequeña capaz de repararlo. Clasifica antes de priorizar: una página ausente es cobertura, una entrada sin camino es acceso, una promesa engañosa es etiqueta y un control inutilizable es interacción. Esta disciplina impide que todos los problemas terminen como solicitudes de navegación nueva. Mantén además visible si el hallazgo proviene de observación, inspección, datos operativos o una hipótesis todavía no comprobada.

• Cobertura: falta el contenido, la acción o el estado requerido.
• Entrada: un contexto inicial probable no ofrece una ruta plausible.
• Etiqueta o agrupación: la pista promete otro destino o la ubicación contradice la expectativa.
• Orientación, vínculo o búsqueda: faltan ubicación, siguiente paso o resultados interpretables.
• Consistencia o interacción: los mecanismos cambian de forma impredecible o el control impide utilizarlos.

Prioriza con insumos explícitos: importancia de la tarea, audiencias afectadas, frecuencia observada de la falla, consecuencia, fuerza de la evidencia y dependencias de corrección. No ocultes esas decisiones dentro de una puntuación compuesta presentada como universal. La finalización, los errores, el tiempo y los comentarios son evidencias posibles, no una boleta obligatoria. Dos hallazgos con frecuencia similar pueden merecer respuestas diferentes si uno bloquea una tarea crítica y el otro permite una recuperación clara.

1. Corrige primero contenido, etiqueta o vínculo cuando el problema esté localizado.
2. Reagrupa o ajusta búsqueda cuando la evidencia señale expectativas o resultados sistemáticamente deficientes.
3. Reestructura una sección cuando varias rutas importantes compartan la misma causa estructural.
4. Repite las tareas afectadas en los contextos pertinentes y documenta el cambio observado.
5. Escala a rediseño amplio sólo si las fallas importantes son repetidas, estructurales y no parecen reparables de forma acotada.

Cierra la auditoría con una decisión de retest, no con un mapa nuevo por defecto. Si el equipo carece de experiencia para diseñar las tareas, interpretar rutas divergentes o resolver compensaciones estructurales, involucra a una persona experimentada en arquitectura de información o investigación UX. Si aparecen dudas de accesibilidad, solicita una evaluación con el alcance apropiado: revisar los tres criterios WCAG citados aquí aporta evidencia específica, pero no establece por sí solo la conformidad del sitio completo.