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

Antes de redibujar el mapa del sitio, audite tareas representativas y todas las rutas plausibles para completarlas. Un menú congestionado, una página con muchas salidas o varias quejas pueden señalar un problema, pero no dicen si falta contenido, si una etiqueta promete el destino equivocado, si el buscador entrega resultados pobres o si un control impide avanzar. Seguir una tarea desde contextos reales de entrada hasta su resultado permite distinguir el síntoma de la falla y evita convertir una observación aislada en un proyecto de rediseño.

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

La auditoría debe diseñarse alrededor de una decisión concreta: reparar una sección, cambiar etiquetas, preparar una migración o determinar si existe evidencia para una transformación más amplia. Defina quién tomará esa decisión, qué evidencia necesita y qué quedará fuera. La arquitectura de información abarca la organización, las etiquetas y la navegación que ayudan a encontrar contenido, reconocer la ubicación y completar tareas. Por eso, el objeto de estudio no es un mapa abstracto, sino el sistema de rutas disponible para resultados seleccionados.

Delimite audiencias, objetivos, puntos de entrada, tipos de página, dispositivos, versiones regionales, permisos y estados del recorrido. Una conclusión obtenida en el portal público para escritorio no se extiende automáticamente al área autenticada ni a la experiencia móvil. Separe también cuatro clases de registro: hechos conocidos, comportamiento observado, hallazgos de inspección experta e hipótesis pendientes. Esa separación evita presentar una sospecha del equipo como si una persona usuaria hubiera tropezado realmente con ella.

• Una auditoría basada en tareas diagnostica si las rutas existentes permiten completar resultados seleccionados.
• Un inventario de contenido registra piezas, propietarios y estado editorial.
• Una auditoría técnica de SEO examina rastreo, indexación y otros factores de visibilidad.
• Una evaluación de conformidad en accesibilidad y un rediseño completo requieren alcances propios.

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

Construya el conjunto escribiendo cada tarea como un resultado reconocible para la audiencia, sin revelar la sección, la etiqueta ni la ruta que el equipo supone correcta. La guía de GOV.UK recomienda investigar qué intentan hacer las personas, cómo lo hacen hoy, qué problemas encuentran y qué resultado necesitan. En vez de pedir «vaya a Recursos», formule algo como «encuentre los requisitos para iniciar una solicitud» y defina qué contenido o acción demostraría una finalización válida.

Analítica, búsquedas internas, contactos de soporte, estudios anteriores, entrevistas, observación y personal que atiende usuarios pueden aportar señales; las opiniones sin evidencia de usuarios siguen siendo supuestos. Los datos operativos ayudan a ubicar preguntas, pero no demuestran por sí solos la intención del usuario, la causa del comportamiento ni la reparación correcta. Un estudio documentado por Digital.gov derivó escenarios realistas de investigaciones previas y revisó su cobertura antes de probarlos, una práctica útil sin convertir las cantidades de ese caso en una receta.

1. Registre la audiencia, el detonante y los contextos probables de inicio.
2. Defina el resultado exitoso y, si aplica, el destino donde puede alcanzarse.
3. Anote la fuente de evidencia y su fecha, distinguiendo observación, dato operativo e hipótesis.
4. Equilibre tareas frecuentes con tareas críticas, difíciles o desatendidas.
5. Revise que el conjunto cubra la decisión sin favorecer únicamente los recorridos más fáciles.

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

La matriz debe conectar cada tarea evidenciada con su resultado, sus puntos de partida, las rutas plausibles, las señales examinadas, el comportamiento observado, el diagnóstico y la nueva prueba. Incluya entradas desde buscadores externos, páginas de sección, enlaces contextuales, áreas autenticadas y búsqueda interna cuando sean realistas. No suponga que todas las personas comienzan en la página de inicio ni que una ruta que funciona desde allí resuelve los demás contextos.

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 esa página sea resultado o paso de un proceso. Entre las técnicas documentadas están los enlaces relacionados, el mapa del sitio, la búsqueda y una navegación integral; la excepción debe permanecer explícita.

• Use el mismo identificador de tarea durante inspección, prueba, diagnóstico, asignación y repetición.
• Adjunte cada observación a una ruta y un contexto específicos.
• Registre tanto los desvíos fallidos como las rutas alternativas que sí permiten completar el resultado.
• Mantenga visible qué recomendación depende de qué evidencia.

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

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

Inspeccione todos los componentes materiales desde la entrada hasta la finalización: página de llegada, navegación global y local, índices, agrupaciones, encabezados, migas de pan u otras señales de ubicación, enlaces contextuales, resultados de búsqueda y destino final. En cada paso pregunte qué promete la señal, si la opción se distingue de sus vecinas, qué encuentra la persona después y cómo puede recuperarse. La estructura puede parecer lógica internamente y aun así contradecir el lenguaje o el contexto de la audiencia.

Microsoft recomienda planear la navegación desde las perspectivas, tareas comunes y modelos mentales de los usuarios, y describe las buenas etiquetas como precisas, familiares, concisas, escaneables y distinguibles. El criterio 2,4,6 de WCAG 2,2 exige que los encabezados y las etiquetas proporcionados describan su tema o propósito. El criterio 3,2,3 pide conservar el orden relativo de los mecanismos de navegación repetidos, salvo que el usuario inicie un cambio; esto no impide contar con navegación local o secundaria.

• Compruebe si la persona puede reconocer dónde está, qué nivel alcanzó y qué puede hacer después.
• Repita tareas importantes cuando dispositivo, región, permiso o estado cambien las rutas disponibles.
• Revise si el destino contiene la información o acción necesaria, no solo si fue posible abrirlo.
• Observe la búsqueda sin asumir culpabilidad: buscar puede ser una preferencia legítima y una ruta alternativa, no una confesión automática de que el menú falló.

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

Seleccione el método según la incertidumbre que debe resolver, no según la herramienta disponible. La inspección experta y los datos existentes sirven para localizar puntos sospechosos, pero un hallazgo inspeccionado no equivale a una falla observada en usuarios. Conviértalo en una pregunta verificable: ¿la agrupación contradice las expectativas?, ¿la etiqueta desvía?, ¿el control móvil impide desplegar opciones?, ¿los resultados permiten reconocer el destino correcto?

Digital.gov presenta la clasificación de tarjetas como un método para conocer cómo agrupan contenido los participantes y, en la modalidad abierta, cómo nombran sus grupos. La prueba de árbol puede aislar la encontrabilidad de un destino dentro de una jerarquía y revelar categorías o etiquetas confusas, pero omite buena parte de la interfaz renderizada. Para señales de página, controles, enlaces contextuales, búsqueda, recuperación y terminación, pruebe la tarea en el sitio o prototipo representativo.

NIST describe las pruebas de usabilidad como la realización de tareas representativas por usuarios representativos, con evidencia que puede incluir finalización, errores, tiempo, comentarios cualitativos y satisfacción. Añada asistencia, desvíos, retrocesos, reformulaciones de búsqueda o confianza en el destino cuando respondan a la decisión. Las rutas divergentes y las explicaciones de los participantes pueden revelar agrupaciones o etiquetas ambiguas incluso cuando algunas personas llegan al destino previsto.

• Clasificación de tarjetas: agrupación esperada y lenguaje de categorías.
• Prueba de árbol: encontrabilidad mediante jerarquía y etiquetas sin diseño de página.
• Prueba de usabilidad basada en tareas: comportamiento en la experiencia renderizada y finalización.
• Inspección experta: hipótesis priorizadas que todavía deben distinguirse de la evidencia observada.

¿Cómo convertir los hallazgos en cambios acotados o justificar un rediseño?

Convierta cada hallazgo en un diagnóstico específico antes de recomendar una solución. Clasifique la falla como cobertura, entrada, etiqueta, agrupación, orientación, enlace contextual, búsqueda, consistencia o interacción. Esta taxonomía evita que todos los síntomas terminen convertidos en «problemas de navegación». Si el contenido requerido no existe, cambiar el menú no lo crea; si la jerarquía es plausible pero un control no funciona, mover páginas tampoco repara la interacción.

Priorice con insumos visibles: importancia de la tarea, audiencias afectadas, frecuencia observada de la falla, consecuencia, fuerza de evidencia y dependencias de remediación. Finalización, errores, tiempo, comentarios y satisfacción son formas posibles de evidencia, no una tarjeta de puntaje obligatoria para toda auditoría. Ninguna fuente citada ofrece un puntaje compuesto universal que decida si un sitio necesita rediseño; documente el juicio para que otra persona pueda cuestionarlo o reproducirlo.

• 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 señal promete otra cosa o el destino aparece donde no se espera.
• Orientación o enlace contextual: falta ubicación, siguiente paso o recuperación en el punto de necesidad.
• Búsqueda, consistencia o interacción: fallan los resultados, la predictibilidad o el control renderizado.

Elija la intervención mínima respaldada por el registro: corregir contenido, ajustar una etiqueta o un enlace, reagrupar, afinar la búsqueda, reestructurar una sección o, solo cuando corresponda, rediseñar. Asigne responsable, ruta afectada, criterio de decisión y fecha de nueva prueba. El rediseño amplio se justifica cuando fallas importantes se repiten en contextos relevantes, están respaldadas por observación, son estructurales y no admiten una reparación acotada razonable.

Cierre con una decisión de repetición, no con un mapa nuevo por defecto. Involucre a una persona experimentada en arquitectura de información o investigación UX cuando el conjunto de tareas, el diseño del estudio o los compromisos estructurales excedan la capacidad del equipo. Si aparecen dudas de accesibilidad, solicite una evaluación apropiada a un especialista calificado: revisar estos criterios puntuales no establece la conformidad de accesibilidad del sitio completo.