Gestiona la web como un sistema empresarial.
Arquitectura de la información
Guía práctica para auditar tareas, rutas, etiquetas y búsquedas antes de aprobar un rediseño, una migración o un cambio estructural del sitio.
WebChorus Editorial Team9 min de lectura
Antes de auditar menús o dibujar un nuevo mapa del sitio, audite tareas representativas y todas las rutas plausibles para completarlas. Empiece con un resultado importante —encontrar un requisito, comparar una opción, enviar una solicitud o retomar un trámite— y siga el recorrido desde los contextos donde una persona realmente podría comenzar. Registre qué señal ve, qué espera encontrar, adónde llega, cómo se recupera de una elección equivocada y si finalmente consigue lo que necesitaba.
Este enfoque evita convertir síntomas aislados en una orden de rediseño. Un menú saturado, una página con muchas salidas o varias quejas pueden apuntar a contenido ausente, una etiqueta ambigua, un enlace contextual faltante, resultados de búsqueda deficientes o un control difícil de usar. Sin evidencia a escala de tarea, el equipo corre el riesgo de financiar una migración costosa y conservar intacto el problema que interrumpe el recorrido.
Decisiones clave para la auditoría
La auditoría debe diseñarse alrededor de una decisión delimitada: reparar una sección, cambiar etiquetas, preparar una migración o determinar si existe evidencia suficiente para estudiar un rediseño más amplio. Defina desde el comienzo las audiencias, metas, contextos iniciales, tipos de página, dispositivos, idiomas, permisos y estados del recorrido incluidos. Las conclusiones solo serán válidas para esos contextos; no describirán a una supuesta persona usuaria promedio ni a todo el ecosistema digital.
Una auditoría basada en tareas examina si el sistema actual de organización, etiquetas y navegación permite encontrar información, orientarse y completar resultados. No es un inventario de contenido, una auditoría técnica de SEO, una evaluación integral de conformidad de accesibilidad ni un ejercicio de rediseño. Puede descubrir preguntas que requieran esos trabajos, pero debe conservar su alcance diagnóstico para que cada recomendación responda a la decisión original.
Construya el conjunto como una cartera de resultados que las personas reconocen, no como una lista de páginas que el equipo desea promocionar. Una tarea debe expresar qué necesita lograr alguien sin revelar la etiqueta del destino ni sugerir el camino correcto. Combine tareas frecuentes con otras de alta consecuencia, difíciles o desatendidas. Así evita que la auditoría favorezca únicamente los recorridos más visibles o fáciles y deja espacio para audiencias menos numerosas pero relevantes.
La investigación previa, la analítica, las consultas del buscador interno, los contactos de soporte, la retroalimentación, las entrevistas, la observación y el personal que trabaja con usuarios pueden aportar candidatos. Sin embargo, un registro de búsqueda o una salida de página no explica por sí solo la intención ni la causa. Mantenga las afirmaciones de áreas internas y las conjeturas expertas como hipótesis hasta contrastarlas. Un caso documentado por Digital.gov, por ejemplo, derivó escenarios de investigaciones anteriores y revisó su cobertura antes de probarlos, sin convertir sus cantidades particulares en una receta universal.
La matriz debe conectar cada tarea evidenciada con su resultado, sus rutas posibles, las señales inspeccionadas, la conducta observada, el diagnóstico y la nueva prueba prevista. Registre comienzos realistas como una página recibida desde un buscador externo, una sección, un área autenticada o la búsqueda interna. Luego trace rutas de exploración, enlaces contextuales y búsqueda sin asumir que toda visita empieza en la portada o que un único trayecto exitoso sirve para todos los contextos.
| Tarea, audiencia, activador, resultado y evidencia | Contextos iniciales, rutas y señales inspeccionadas | Conducta, medidas, falla y solidez de evidencia | Cambio mínimo, responsable y nueva prueba |
|---|---|---|---|
| Resultado expresado en lenguaje del usuario; audiencia y fuente documentadas | Entrada externa, exploración, enlace contextual o búsqueda; expectativa creada en cada decisión | Finalización, ayuda, desvíos, retrocesos o reformulaciones; diagnóstico provisional | Corrección acotada, dueño de la acción, tarea y rutas que se volverán a probar |
En cada punto de decisión, anote la señal visible, la expectativa que produce, el destino alcanzado y la posibilidad de reconocer y corregir un error. También compruebe rutas alternativas cuando correspondan. El criterio dos punto cuatro punto cinco de la versión dos punto dos de WCAG exige más de una forma de localizar páginas dentro de un conjunto, salvo resultados o pasos de un proceso, y contempla recursos como enlaces relacionados, mapa del sitio, búsqueda y navegación integral. Esta comprobación específica no equivale a una evaluación completa de accesibilidad.
Una auditoría basada en tareas no pregunta si el mapa del sitio luce ordenado, sino si las personas alcanzan un resultado por rutas reales y con evidencia que permita actuar.
Inspeccione de principio a fin todos los componentes que pueden sostener o romper la tarea: entrada externa, navegación global y local, páginas índice, agrupaciones, encabezados, migas de pan u otras señales de ubicación, enlaces contextuales, buscador interno y destino final. En cada tramo pregunte si la promesa es comprensible, si el lugar alcanzado coincide con ella, si la persona sabe en qué nivel está y si existe un siguiente paso útil cuando la primera elección no funciona.
Microsoft aconseja planificar la navegación desde tareas y modelos mentales, y evaluar etiquetas por su precisión, familiaridad, concisión y capacidad de distinguirse. WCAG añade comprobaciones puntuales: el criterio dos punto cuatro punto seis exige que encabezados y etiquetas describan tema o propósito, mientras el criterio tres punto dos punto tres pide conservar el orden relativo de mecanismos de navegación repetidos salvo un cambio iniciado por la persona. Repita los recorridos en dispositivos, idiomas, permisos y estados que alteren materialmente las rutas. El uso del buscador puede ser una preferencia válida, no prueba automática de que el menú falló.
Elija el método según la pregunta que todavía no puede responder, no según la herramienta disponible o la costumbre del equipo. La inspección experta y los datos existentes sirven para ubicar posibles defectos, pero un problema detectado por especialistas no debe presentarse como una falla observada en usuarios. Formule primero la incertidumbre: ¿está en la agrupación, en el lenguaje de la categoría, en la jerarquía sin diseño o en el recorrido completo dentro de la interfaz?
NIST describe las pruebas de usabilidad con usuarios y tareas representativos, y contempla finalización, errores, tiempo, comentarios cualitativos y satisfacción. Seleccione solo las observaciones que ayuden a decidir: asistencia, desvíos, retrocesos, reformulaciones de búsqueda, confianza en el destino o explicación del razonamiento pueden resultar pertinentes. No existe una tarjeta universal de puntuación. Las rutas divergentes y lo que las personas explican pueden descubrir una categoría ambigua aun cuando parte de los participantes complete la tarea por un camino alternativo válido.
Convierta los hallazgos en decisiones clasificando primero la falla y escogiendo después la intervención más pequeña que la evidencia permita defender. Evite llamar «problema de navegación» a todo síntoma. Una tarea puede fracasar porque el contenido o estado necesario no existe, porque la entrada no ofrece una ruta plausible, porque la etiqueta promete otra cosa o porque la estructura es correcta pero el control renderizado impide usarla. El diagnóstico determina quién debe intervenir y qué debe volver a probarse.
Priorice mostrando los insumos de juicio: importancia de la tarea, audiencias afectadas, frecuencia observada de la falla, consecuencia, solidez de la evidencia y dependencias de remediación. No los oculte dentro de una puntuación compuesta supuestamente universal. Según el diagnóstico, la respuesta puede ser corregir contenido, etiqueta o enlace; reagrupar; ajustar la búsqueda; reestructurar una sección; o plantear un rediseño. Asigne responsable, fecha de revisión y recorrido de validación, y compare las mismas observaciones pertinentes antes de declarar éxito.
Escale a un cambio estructural amplio únicamente cuando las tareas importantes fallen de forma repetida en contextos relevantes, la evidencia observada señale causas estructurales y las reparaciones locales no sean razonables. Si el conjunto de tareas, el diseño de investigación o las compensaciones entre estructuras exceden la capacidad del equipo, incorpore a una persona con experiencia en arquitectura de información o investigación UX. Cuando aparezcan dudas de accesibilidad, solicite una evaluación especializada: esta auditoría y sus comprobaciones WCAG seleccionadas no establecen conformidad para todo el sitio.
Una auditoría basada en tareas revisa entradas, navegación, etiquetas, agrupaciones, señales de orientación, enlaces contextuales, búsqueda interna y capacidad de completar el resultado. Mantiene una matriz que conecta evidencia, rutas, conducta observada, diagnóstico, intervención y nueva prueba. No reemplaza un inventario de contenido, una auditoría técnica de SEO, una evaluación integral de accesibilidad ni un rediseño.
No existe una cantidad universal respaldada por las fuentes utilizadas. El alcance depende de la decisión, la diversidad de audiencias y contextos, la importancia de las tareas, la incertidumbre y la solidez de evidencia necesaria. Las cantidades de un caso de estudio describen ese caso y no deben convertirse en umbral para otro sitio.
Puede señalar dónde investigar mediante patrones de entrada, salida, búsqueda y avance, especialmente al combinarse con consultas internas y contactos de soporte. Sin embargo, esos registros no prueban por sí solos qué pretendía una persona, por qué actuó así o qué cambio estructural resolvería el problema. Contraste la señal con observación, entrevistas u otra evidencia contextual.
No. La búsqueda puede ser una ruta preferida y válida para localizar información. Revise si las personas reformulan consultas, si los resultados son pertinentes, si reconocen el destino correcto y si completan la tarea antes de diagnosticar una falla de navegación o del propio buscador.
Un rediseño amplio se justifica cuando fallas importantes se repiten en audiencias y contextos pertinentes, han sido observadas con evidencia suficiente y responden a causas estructurales. Primero descarte reparaciones acotadas de contenido, etiquetas, enlaces, agrupaciones, búsqueda o interacción. Vuelva a probar las tareas afectadas antes de aprobar una transformación mayor.
Para investigar este artículo se utilizaron las siguientes fuentes:
Estrategia de contenido para sitios web
Define el propósito de una página con una ficha de nueve campos y decide si conviene actualizar, combinar, redirigir, rechazar o crear.
Construya una estrategia web trazable que conecte trabajos de la audiencia y recorridos con capacidades, resultados medibles y decisiones de inversión.
Guía práctica para preservar propósito, evidencia, opciones y próximos pasos en páginas que cambian de ancho, orden o nivel de ampliación.
