Audita primero tareas representativas y todas sus rutas plausibles; solo después juzga menús, jerarquías o un nuevo mapa del sitio. Un menú saturado, una página con muchas salidas o varias quejas pueden señalar un problema, pero no explican si falta contenido, falla una etiqueta, se ha omitido un enlace contextual, el buscador devuelve resultados pobres o un control impide avanzar. Seguir una tarea relevante desde distintos puntos de entrada hasta su resultado convierte indicios dispersos en decisiones comprobables y evita gastar el presupuesto de migración o rediseño en una solución que no repara el recorrido.
Principios para orientar la auditoría
Audita tareas representativas y sus rutas plausibles antes de evaluar menús o proponer un nuevo mapa del sitio.
Interpreta la analítica, las búsquedas internas, el soporte y la revisión experta como señales que necesitan contexto de usuarios.
Usa ordenación de tarjetas para agrupaciones, pruebas de árbol para jerarquía y etiquetas, y pruebas de usabilidad para recorridos renderizados.
Clasifica el fallo antes de elegir la solución, porque cobertura, etiquetas, enlaces, búsqueda e interacción requieren intervenciones distintas.
Aplica la reparación más pequeña respaldada por evidencias, vuelve a probar la tarea y amplía el cambio solo si persiste un problema estructural.
¿Qué decisión debe fundamentar la auditoría?
La auditoría debe fundamentar una decisión delimitada: reparar una sección, cambiar etiquetas, preparar una migración o comprobar si existen razones para un rediseño más amplio. La arquitectura de la información abarca la organización, el etiquetado y la navegación que permiten encontrar información, orientarse y completar tareas. Por eso, el objeto de análisis no es un diagrama abstracto, sino el sistema de rutas disponible para unas tareas, audiencias y circunstancias expresamente incluidas.
Fija también el alcance de las conclusiones: audiencias, objetivos, puntos de partida, tipos de página, dispositivos, idiomas, permisos y estados del recorrido. Una ruta que funciona en el área pública puede desaparecer tras iniciar sesión; una etiqueta clara en castellano puede no conservar su sentido en otra versión local. Separa en el registro los hechos conocidos, las conductas observadas, los hallazgos de inspección experta y las hipótesis todavía no probadas.
Decisión: qué aprobación, reparación o inversión deberá orientar el resultado.
Contextos: para quién, desde dónde y bajo qué dispositivo, idioma, permiso o estado se audita.
Evidencia exigida: qué debe observarse para mantener, limitar o descartar cada hipótesis.
Límites: qué pertenece a inventario de contenidos, SEO técnico, evaluación de accesibilidad o diseño y queda fuera.
¿Cómo se construye un conjunto representativo de tareas a partir de evidencias?
Un conjunto representativo se construye describiendo resultados que las personas reconocen y documentando de dónde procede cada tarea. Una formulación sólida recoge qué intenta conseguir alguien, cómo actúa actualmente, qué problema encuentra y qué resultado necesita, sin revelar el nombre de la sección ni la respuesta de navegación. «Averiguar qué documentación necesita mi empresa para solicitar el servicio» sirve mejor que «Visitar Documentación», porque permite observar expectativas reales.
Combina investigación previa, analítica, consultas del buscador interno, solicitudes de soporte, comentarios, entrevistas, observación y conocimiento del personal que atiende a usuarios. Estas fuentes no tienen el mismo valor probatorio: la analítica y los datos operativos localizan preguntas, pero no demuestran por sí solos intención, causa o solución. Conserva como hipótesis las opiniones de responsables y especialistas hasta contrastarlas con evidencias de usuarios.
Incluye tareas frecuentes, pero también tareas importantes, difíciles o vinculadas a públicos desatendidos.
Registra para cada tarea la audiencia, el desencadenante, los puntos de partida y la condición observable de éxito.
Nombra el contenido o la acción final necesaria sin introducir en el escenario la etiqueta que pretende evaluarse.
Anota la fuente, la fecha y la calidad de la evidencia para poder revisar después por qué se incluyó.
Antes de probar, revisa el conjunto como cartera: busca tareas duplicadas, resultados vagos y públicos ausentes. Un estudio documentado por Digital.gov creó escenarios realistas a partir de investigación previa y revisó su cobertura antes de probarlos. Esa práctica es transferible; las cantidades concretas de aquel caso no lo son. El tamaño adecuado depende de la decisión, la diversidad de contextos y la incertidumbre que deba reducirse.
¿Qué debe recoger la hoja de tareas y rutas?
La hoja debe conectar cada tarea y su procedencia con el resultado esperado, los puntos de partida, las rutas plausibles, las señales inspeccionadas, la conducta observada, el diagnóstico y la nueva prueba. Mantén un único registro durante todo el trabajo: así, una recomendación no queda separada de la evidencia que la originó y puede seguirse desde el primer indicio hasta la persona responsable de aplicar y validar el cambio.
No presupongas que todo recorrido comienza en la portada. Traza entradas desde buscadores externos, páginas de campaña o de sección, enlaces guardados, áreas autenticadas y el buscador interno. Para cada alternativa de navegación, enlace contextual o búsqueda, apunta la señal visible, la expectativa que crea, el destino alcanzado y la posibilidad de reconocer un error y recuperarse sin reiniciar el recorrido.
Resultado: contenido, decisión, trámite o acción que permite dar la tarea por terminada.
Ruta: secuencia plausible de entradas, elecciones, consultas y destinos, incluidas alternativas válidas.
Observación: acción, duda, retroceso o explicación efectivamente registrada, separada de la interpretación.
Decisión: modo de fallo, solidez de la evidencia, cambio mínimo, responsable y condición de la nueva prueba.
Una auditoría basada en tareas no pregunta si el mapa parece ordenado, sino si las personas alcanzan resultados reales por rutas que podemos observar y mejorar.
Hoja compacta para mantener cada recomendación unida a su evidencia y a su nueva prueba
Tarea, audiencia, desencadenante, resultado y evidencia de origen
Puntos de partida, rutas plausibles y señales inspeccionadas
Conducta observada, medidas, modo de fallo y solidez
Cambio mínimo, responsable y nueva prueba
Comparar requisitos antes de solicitar un servicio; responsable de compras; investigación y consultas internas
Resultado externo, página de sector, navegación local, enlace contextual y búsqueda; etiquetas y encabezados revisados
Retrocesos y consultas reformuladas; confusión entre dos categorías; evidencia observada en contextos delimitados
Diferenciar etiquetas y añadir un enlace contextual; responsable de contenidos; repetir la tarea en las mismas rutas
¿Cómo se inspecciona la ruta completa sin limitarse a 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 u otras señales de ubicación, los enlaces contextuales, el buscador y el destino final. En cada paso pregunta qué espera una persona tras leer la señal y si la página siguiente cumple esa promesa.
Microsoft recomienda planificar la navegación desde las perspectivas, tareas habituales y modelos mentales de los usuarios, y evaluar las etiquetas por su precisión, familiaridad, concisión y capacidad de distinguirse. Una etiqueta breve no es automáticamente clara: debe diferenciarse de las opciones próximas y conservar sentido en el contexto. El criterio 2,4,6 de WCAG 2,2 exige que los encabezados y etiquetas proporcionados describan su tema o finalidad.
Promesa: la señal anticipa con precisión el contenido, nivel o acción que aparecerá después.
Orientación: la persona entiende dónde está, qué relación tiene la página con el conjunto y qué puede hacer.
Consistencia: los mecanismos repetidos conservan nombres, comportamiento y orden relativo previsibles entre páginas.
Recuperación: una elección improductiva puede reconocerse y corregirse sin perder el contexto ni empezar de nuevo.
Finalización: el destino contiene realmente la información, el estado o la acción requeridos por la tarea.
Repite las tareas importantes cuando cambien materialmente el dispositivo, el idioma, los permisos, el tipo de página o el estado del proceso. El criterio 3,2,3 de WCAG 2,2 pide conservar el orden relativo de los mecanismos de navegación repetidos, salvo que la persona usuaria inicie un cambio, pero no prohíbe la navegación local. Usar el buscador tampoco demuestra un fallo: puede ser una vía alternativa válida cuya calidad debe evaluarse.
¿Qué método de investigación valida cada ruta incierta?
El método adecuado es el que responde a la incertidumbre concreta, no el más cómodo o conocido por el equipo. La inspección experta y los datos existentes sirven para localizar posibles defectos, pero un problema detectado por especialistas no debe presentarse como un fallo observado en usuarios. Formula primero la pregunta: ¿dudamos de la agrupación, de la jerarquía, de la etiqueta o del comportamiento del recorrido completo?
Ordenación de tarjetas: investiga cómo se agrupan los contenidos y qué lenguaje resulta natural para nombrar categorías.
Prueba de árbol: aísla si una jerarquía y sus etiquetas permiten localizar un destino sin influencia del diseño visual.
Prueba de usabilidad basada en tareas: observa navegación renderizada, controles, enlaces, búsqueda, recuperación y finalización.
Inspección experta: identifica hipótesis y riesgos que después deben conservar su condición de inspección o validarse.
La ordenación de tarjetas no valida una ruta existente y la prueba de árbol no reproduce la experiencia completa. Esta última puede revelar categorías confusas, pero omite controles, señales de página, enlaces contextuales y resultados de búsqueda. Cuando la duda atraviesa esos elementos, observa a personas representativas realizando tareas representativas en el sitio. NIST contempla evidencias como finalización, errores, tiempo, comentarios cualitativos y satisfacción, sin imponer una batería universal.
Elige únicamente observaciones que ayuden a decidir: finalización, ayuda solicitada, errores, giros equivocados, tiempo, retrocesos, reformulaciones de búsqueda, confianza en el destino o razonamiento expresado. No conviertas todas ellas en un cuadro de mando obligatorio. Las rutas divergentes y las explicaciones pueden descubrir etiquetas ambiguas aunque varias personas completen la tarea; también pueden revelar alternativas legítimas que conviene conservar.
¿Cómo se convierten los hallazgos en cambios acotados o en un rediseño justificado?
Los hallazgos se convierten en decisiones clasificando primero el fallo y eligiendo después la intervención más pequeña capaz de repararlo. No llames «problema de navegación» a cualquier síntoma: puede faltar el contenido necesario, no existir una entrada plausible, fallar una etiqueta o agrupación, desaparecer el contexto, faltar un enlace, rendir mal la búsqueda, cambiar la navegación repetida o impedir el avance un control renderizado.
Cobertura: el contenido, la acción o el estado necesario no existe o está incompleto.
Entrada, enlace u orientación: falta una ruta plausible, un siguiente paso contextual o una señal de ubicación.
Etiqueta o agrupación: la promesa resulta equívoca, desconocida, solapada o está situada donde no se espera.
Búsqueda o consistencia: los resultados no ayudan o los mecanismos repetidos cambian de nombre, orden o comportamiento.
Interacción: la estructura es plausible, pero el diseño o el control impide utilizarla.
Prioriza mostrando los elementos del juicio: importancia de la tarea, públicos afectados, frecuencia observada del fallo, consecuencias, solidez de la evidencia y dependencias de reparación. Ninguna métrica aislada o puntuación compuesta determina si procede rediseñar. El registro debe permitir discutir por qué un cambio de etiqueta, un enlace contextual, una corrección de contenido, una reagrupación o un ajuste del buscador merece precedencia.
Vuelve a probar las tareas y rutas afectadas antes de declarar el éxito. La finalización, los errores, el tiempo y los comentarios cualitativos pueden servir para comparar la experiencia, siempre que respondan a la decisión planteada. Escala a un rediseño amplio solo cuando los fallos importantes sean repetidos en contextos relevantes, estén respaldados por observación, sean estructurales y no puedan corregirse razonablemente mediante intervenciones acotadas.
El cierre de la auditoría debe ser una decisión de nueva prueba, no un mapa del sitio nuevo por defecto. Recurre a profesionales con experiencia en arquitectura de la información o investigación cuando el diseño del estudio o los compromisos estructurales superen la capacidad interna. Si aparecen dudas de accesibilidad, solicita una evaluación especializada: esta auditoría y la revisión de criterios concretos de WCAG no acreditan por sí solas la conformidad de todo el sitio.
Preguntas frecuentes sobre auditorías de arquitectura de la información
¿Qué incluye una auditoría de arquitectura de la información?
Una auditoría basada en tareas examina puntos de entrada, navegación, etiquetas, agrupaciones, señales de orientación, enlaces contextuales, búsqueda y destino final. Se centra en si rutas concretas permiten completar resultados definidos. No sustituye un inventario de contenidos, una auditoría de SEO técnico, una evaluación completa de accesibilidad ni el propio rediseño.
¿Cuántos usuarios o tareas hacen falta para una auditoría de arquitectura de la información?
Las fuentes aportadas no fijan una cifra universal. Define el alcance según la decisión, la diversidad de audiencias y contextos, el riesgo de las tareas, la incertidumbre y la solidez de evidencia necesaria. No conviertas el tamaño de un caso publicado en una regla general.
¿Puede la analítica detectar problemas de navegación web?
Puede señalar dónde investigar mediante rutas, salidas, consultas internas o contactos de soporte. Sin contexto cualitativo, esos datos no prueban la intención, la causa del comportamiento ni la solución estructural adecuada. Contrasta la señal observando tareas y recogiendo el razonamiento de usuarios relevantes.
¿Usar el buscador interno significa que la navegación ha fallado?
No: buscar puede ser una preferencia y una ruta alternativa válida. Examina si las personas reformulan consultas, si los resultados son relevantes, si reconocen el destino correcto y si completan la tarea. Solo entonces podrás distinguir un fallo de búsqueda, navegación, contenido o etiquetado.
¿Cuándo justifica una auditoría de arquitectura de la información rediseñar la web?
Cuando fallos importantes se repiten en los contextos pertinentes, están respaldados por conducta observada, responden a causas estructurales y no pueden repararse de forma razonable con cambios locales. Antes, prueba ajustes de contenido, etiquetas, enlaces, agrupaciones o búsqueda y vuelve a ejecutar las tareas afectadas.
Referencias y fuentes
Este artículo se ha elaborado a partir de las siguientes fuentes:
Cubrimos las decisiones que dan forma a una web mucho después del lanzamiento. Partimos de fuentes identificadas, separamos lo que encontramos de lo que opinamos y usamos IA para investigar y redactar conforme a estándares editoriales documentados. Declaramos cualquier relación comercial que exista.