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

Audite tareas y rutas representativas antes de ordenar menús o dibujar un sitemap nuevo. Si la propuesta de rediseño se apoya solo en una navegación recargada, páginas con muchas salidas o reclamos generales sobre información difícil de encontrar, todavía falta el diagnóstico. Elija una tarea relevante, defina qué resultado significa completarla y siga cada vía realista hasta su destino. Así podrá distinguir entre contenido ausente, una etiqueta confusa, un enlace contextual que falta, resultados deficientes de búsqueda o un control que impide avanzar. Cada problema exige una intervención diferente; convertirlos a todos en «mala arquitectura» puede consumir presupuesto de migración sin reparar la experiencia que originó la decisión.

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

La auditoría debe diseñarse para resolver una decisión delimitada: reparar una sección, cambiar etiquetas, preparar una migración o determinar si existe evidencia para un rediseño más amplio. Especifique qué audiencias, objetivos, puntos de entrada, tipos de página, dispositivos, idiomas, permisos y estados del recorrido quedarán dentro del estudio. Una conclusión obtenida en el sitio público de escritorio no se extiende automáticamente a un portal autenticado, una versión móvil o una experiencia localizada. El informe debe declarar esas fronteras para que nadie convierta un hallazgo contextual en una afirmación sobre un usuario promedio imaginario.

Una auditoría basada en tareas examina si la organización, las etiquetas y la navegación permiten encontrar información, orientarse y completar resultados seleccionados. No reemplaza un inventario de contenido, que registra piezas y atributos; una auditoría técnica de SEO; una evaluación integral de conformidad de accesibilidad; ni el rediseño que eventualmente podría recomendarse. Antes de inspeccionar la interfaz, abra un registro de evidencia y separe hechos conocidos, conducta observada, hallazgos de revisión experta e hipótesis pendientes. Esa procedencia evita que una opinión interna adquiera el mismo peso que una dificultad vista durante una tarea.

• Decisión: qué aprobación, reparación o inversión debe informar el trabajo.
• Alcance: audiencias, recorridos, páginas, dispositivos, idiomas, permisos y estados incluidos.
• Estándar de evidencia: qué debe observarse para confirmar o descartar una hipótesis.
• Exclusiones: disciplinas y contextos que requieren una evaluación distinta.

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

Construya el conjunto desde resultados que las personas necesitan alcanzar y conserve la procedencia de cada tarea. GOV.UK recomienda investigar qué intentan hacer, cómo lo resuelven actualmente, qué dificultades encuentran y qué resultado necesitan. Escriba el escenario en lenguaje reconocible, sin revelar el nombre del destino ni sugerir la respuesta de navegación. «Necesita actualizar los datos de facturación de su empresa» permite observar decisiones; «vaya a Administración de cuenta» solo comprueba si alguien sigue una instrucción. Para cada tarea, registre audiencia, detonante, punto de partida, resultado satisfactorio y fuente que justificó incluirla.

Combine investigación previa, entrevistas, observación, analítica, consultas del buscador interno, contactos de soporte, comentarios y conocimiento del personal que atiende usuarios. Estos insumos no tienen el mismo significado: una salida muestra que una sesión terminó en una página, pero no explica intención, causa ni satisfacción; un reclamo revela una experiencia, pero no su extensión. Las afirmaciones de interesados y los supuestos expertos deben quedar rotulados como hipótesis hasta contrastarlos. Un caso de Digital.gov muestra un enfoque útil: derivar escenarios realistas de estudios anteriores y revisar su cobertura antes de probarlos, sin convertir las cantidades de ese caso en una receta universal.

• Incluya tareas frecuentes, pero también las de alta consecuencia, difíciles o desatendidas.
• No concentre el conjunto en los recorridos más fáciles de medir ni en la estructura organizacional vigente.
• Defina una condición observable de término: información comprendida, acción completada o decisión habilitada.
• Mantenga el vínculo entre cada tarea y la evidencia que explica por qué importa.

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

La matriz debe conectar cada tarea con su resultado, rutas posibles, señales inspeccionadas, conducta observada, diagnóstico, cambio propuesto y nueva prueba. Comience por contextos realistas: una página encontrada en Google, una portada de sección, un enlace enviado por soporte, el área autenticada o el buscador interno. Desde cada entrada, trace navegación global y local, índices, enlaces contextuales y búsqueda. No suponga que todos parten desde la portada ni que una sola ruta satisfactoria basta para cualquier contexto. El criterio 2,4,5 de WCAG 2,2 contempla más de una forma de localizar páginas de un conjunto, salvo resultados o pasos de un proceso.

En cada decisión anote la señal visible, la expectativa que crea, el destino alcanzado y la posibilidad de reconocer y corregir una elección improductiva. Registre también dónde termina realmente la tarea: llegar a una página relacionada no equivale a obtener la información o completar la acción. Use la misma fila durante inspección, investigación, diagnóstico, priorización, asignación y repetición de la prueba. Cuando la recomendación llegue a un comité de inversión, esa continuidad permitirá volver desde el cambio propuesto hasta la observación y la tarea que lo justifican, sin reconstruir el razonamiento desde presentaciones separadas.

1. Defina la tarea, su audiencia, el detonante, el resultado y la evidencia de origen.
2. Enumere entradas y rutas plausibles de navegación, enlaces contextuales y búsqueda.
3. Capture señales, expectativas, destinos, recuperación y término efectivo.
4. Clasifique la falla, proponga el cambio más acotado y deje preparada la nueva prueba.

Una auditoría basada en tareas no pregunta si el sitemap se ve ordenado, sino si las personas alcanzan un resultado por rutas reales y con evidencia accionable.

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

Inspeccione desde cada entrada material hasta el contenido o la acción final, incluyendo navegación global y local, portadas de sección, agrupaciones, encabezados, migas u otras señales de ubicación, enlaces contextuales, búsqueda y recuperación. En cada punto pregunte qué promete la señal y si el destino cumple esa promesa. Microsoft recomienda considerar tareas y modelos mentales, y evaluar etiquetas por su precisión, familiaridad, concisión, facilidad de escaneo y diferenciación. Una etiqueta breve no es necesariamente clara: debe distinguirse de sus vecinas y usar lenguaje comprensible para la audiencia en ese contexto.

Compruebe si la persona puede saber dónde está, qué nivel alcanzó, qué opciones siguen disponibles y cómo volver después de una elección equivocada. 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 repetidos, sin prohibir navegación local o secundaria. Repita recorridos cuando dispositivo, idioma, tipo de página, permisos o estado cambien materialmente las rutas. No interprete el uso del buscador como fracaso automático: puede ser una vía preferida y válida, cuya calidad debe evaluarse por separado.

• Entrada: ¿existe una vía plausible desde el contexto donde comienza la necesidad?
• Promesa: ¿la etiqueta, el encabezado o el enlace anticipa correctamente el destino?
• Orientación: ¿se entiende la ubicación, el nivel alcanzado y el siguiente paso?
• Recuperación: ¿una elección improductiva se reconoce y se puede deshacer?
• Término: ¿el destino entrega la información, acción o estado que define el éxito?

¿Qué método valida cada ruta incierta?

Elija el método según la pregunta pendiente, no según la herramienta disponible. La inspección experta y los datos existentes sirven para ubicar posibles defectos, pero una preocupación detectada por especialistas no debe presentarse como una falla observada en usuarios. Use clasificación de tarjetas cuando la incertidumbre sea cómo agrupar contenido o qué lenguaje emplear en categorías: en una clasificación abierta, participantes crean y nombran grupos; en una cerrada, ordenan contenido dentro de categorías definidas. Ninguna modalidad valida por sí sola un recorrido completo a través del sitio renderizado, sus controles, enlaces y resultados de búsqueda.

Use una prueba de árbol para aislar si la jerarquía y sus etiquetas permiten encontrar un destino sin la influencia del diseño de página. Emplee pruebas de usabilidad basadas en tareas cuando la pregunta abarque navegación renderizada, señales dentro de páginas, controles, enlaces contextuales, búsqueda, recuperación o término. NIST describe este método mediante usuarios representativos que realizan tareas representativas y señala evidencia posible como término, errores, tiempo, comentarios y satisfacción. Seleccione solo las observaciones que informen la decisión. Las rutas divergentes y las explicaciones pueden revelar ambigüedad incluso cuando algunas personas alcanzan el destino.

• Inspección experta: formula hipótesis y localiza puntos que conviene investigar.
• Clasificación de tarjetas: examina agrupaciones esperadas y lenguaje de categorías.
• Prueba de árbol: aísla encontrabilidad mediante jerarquía y etiquetas.
• Prueba de usabilidad: observa el recorrido renderizado, la recuperación y el término.
• Medidas posibles: término, ayuda, errores, desvíos, retrocesos, tiempo, reformulaciones, confianza y razonamiento.

¿Cómo se convierten los hallazgos en reparaciones o en un rediseño justificado?

Convierta cada hallazgo en una falla específica antes de elegir la solución. Use categorías operativas: cobertura cuando falta contenido, acción o estado; entrada cuando un contexto probable no ofrece ruta; etiqueta cuando la señal promete otra cosa; agrupación cuando el destino está donde no se espera; orientación cuando no se entiende ubicación o siguiente paso; enlace contextual cuando falta continuidad en el punto de necesidad; búsqueda cuando los resultados son deficientes; consistencia cuando mecanismos repetidos cambian; e interacción cuando la estructura parece razonable, pero el control renderizado impide utilizarla.

Priorice con insumos visibles: importancia de la tarea, audiencias afectadas, frecuencia observada de la falla, consecuencia, solidez de la evidencia y dependencias de reparación. No esconda esas decisiones en un puntaje compuesto supuestamente universal. Dos hallazgos con igual frecuencia pueden requerir prioridades diferentes si uno bloquea una tarea crítica y el otro admite recuperación sencilla. La matriz debe mostrar dónde hay observación directa, dónde existe evidencia conductual que requiere interpretación y dónde sigue habiendo una hipótesis. Esa transparencia permite discutir criterios y restricciones sin confundir precisión aritmética con certeza.

Elija la intervención más acotada respaldada por el registro: corregir contenido, reparar una etiqueta o enlace, reagrupar páginas, ajustar búsqueda, reestructurar una sección o, cuando corresponda, rediseñar ampliamente. Asigne responsable y vuelva a probar las tareas y rutas afectadas antes de declarar éxito. Escale a cambio estructural amplio solo si las fallas importantes se repiten en contextos pertinentes, están respaldadas por observación, son estructurales y no pueden resolverse razonablemente con reparaciones locales. Si surgen dudas de accesibilidad, involucre a especialistas: revisar los criterios citados no establece conformidad integral del sitio.

• Repare localmente cuando la evidencia apunte a contenido, etiqueta, enlace, agrupación, búsqueda, consistencia o interacción.
• Solicite apoyo de arquitectura de información o investigación UX cuando el diseño del estudio o las decisiones estructurales excedan la capacidad del equipo.
• Cierre con una decisión de nueva prueba y evidencia esperada, no con un sitemap nuevo por defecto.