Arquitectura de la Información: Etapas de Diseño de la AI – Etapa 2/6 Definir el contexto

En corto: Un objetivo indica qué resultado se busca; el contexto explica bajo qué condiciones debe alcanzarse. Esta etapa identifica quién realiza la tarea, qué la detona, dónde ocurre, con qué conocimientos e información, qué obstáculos existen y cuáles son las consecuencias del error.

El resultado será una matriz de contexto y un conjunto de escenarios priorizados. Estos insumos todavía no describen pantallas, pero permitirán decidir después qué rutas, ayudas, alertas, controles y mecanismos necesita la interacción.

Del objetivo general a una situación concreta

La etapa anterior produjo un marco de intención con objetivos, tareas, evidencia, restricciones, supuestos y preguntas pendientes. Sin contexto, esa información sigue siendo insuficiente.

“Revisar una solicitud” puede significar una actividad ocasional realizada con calma o una tarea repetida cientos de veces bajo presión. Puede requerir una sola fuente de información o depender de llamadas, documentos y otros sistemas. La tarea parece la misma, pero sus condiciones cambian las decisiones de diseño.

En su propuesta de 2003, Gonzales Cam incluye dentro del contexto la audiencia, los escenarios, el análisis de productos comparables y la realidad organizacional. La práctica contemporánea amplía esta observación hacia comportamientos, capacidades, ambiente, dispositivos, dependencias y situaciones de exclusión. ISO 9241-210 denomina a este trabajo comprensión y especificación del contexto de uso.

El contexto no es una ficha demográfica

Edad, género, ingresos o fotografía no explican automáticamente cómo debe funcionar un producto. Una variable personal resulta relevante cuando modifica una necesidad, un comportamiento o una condición de uso.

Para Arquitectura de la Información suelen ser más útiles preguntas como:

• ¿Qué intenta conseguir la persona?
• ¿Con qué frecuencia realiza la tarea?
• ¿Qué conocimiento y vocabulario posee?
• ¿Qué información tiene disponible y cuál debe buscar?
• ¿Qué interrupciones o límites de tiempo enfrenta?
• ¿Qué dispositivo, canal o tecnología utiliza?
• ¿Qué sucede si interpreta mal una opción?
• ¿Qué barreras pueden impedirle percibir, comprender u operar la interfaz?

Las personas y los arquetipos pueden sintetizar patrones encontrados en investigación. Cuando se construyen solamente con lo que el equipo cree saber, deben identificarse como proto-personas e hipótesis. El artículo Proto-Personas, Personas reales y Arquetipos profundiza en esta diferencia.

Método para definir el contexto

1. Identificar actores por su relación con la tarea

Una audiencia puede contener grupos con responsabilidades, necesidades y permisos diferentes. En lugar de segmentar primero por demografía, conviene observar:

• Rol dentro de la tarea.
• Objetivo y responsabilidad.
• Nivel de experiencia.
• Frecuencia de uso.
• Información que produce o consume.
• Decisiones que puede tomar.
• Dependencia de otras personas o sistemas.

La clasificación entre actores principales y secundarios puede ayudar, siempre que se base en la tarea. Un actor principal no es el más importante para el negocio, sino aquel cuya necesidad define la interacción que se está diseñando. Otros actores pueden consultar, aprobar, corregir o dar soporte mediante rutas distintas.

2. Investigar la situación actual

El contexto no debe construirse únicamente en una reunión con stakeholders. Según el alcance, puede estudiarse mediante:

• Entrevistas con las personas que realizan o reciben la tarea.
• Observación contextual o acompañamiento.
• Revisión de procesos, formatos y manuales.
• Analítica, incidencias y registros de soporte.
• Evaluación del producto existente.
• Investigación previa disponible.

La guía de GOV.UK sobre investigación en descubrimiento recomienda estudiar cómo se resuelve actualmente la tarea, qué canales se utilizan y qué barreras enfrentan distintos grupos, incluidas las personas que necesitan apoyo.

No es obligatorio aplicar todas las técnicas. La selección dependerá de la incertidumbre: si no se conoce el flujo real, observar puede ser más útil que encuestar; si se desconoce la frecuencia de un problema, los registros pueden complementar las entrevistas.

3. Registrar las condiciones de uso

Cada tarea prioritaria se documentará con estas variables:

Estas variables convierten una descripción general en condiciones que más adelante podrán reflejarse en la arquitectura y la interacción.

4. Construir escenarios basados en evidencia

Un escenario describe una situación de uso sin decidir todavía la interfaz. Debe incluir:

1. Actor y detonante.
2. Resultado que necesita alcanzar.
3. Condiciones y restricciones.
4. Información disponible.
5. Obstáculos o excepciones probables.
6. Señal de finalización.

Cuando un elemento no esté comprobado, deberá marcarse como hipótesis. El escenario no necesita narrar cada clic ni convertir cada actividad en pantalla. Su función es representar el problema desde el punto de vista de la tarea.

5. Analizar productos comparables con una pregunta

El benchmarking puede mostrar convenciones, alternativas y riesgos, pero no demuestra qué necesita el usuario. Antes de observar otros productos se definirá qué se quiere aprender, por ejemplo:

• Cómo comunican estados y bloqueos.
• Qué mecanismos utilizan para encontrar un registro.
• Cómo organizan información extensa.
• Qué acciones permiten según el momento de la tarea.

Los hallazgos se registrarán como referencias o hipótesis, no como decisiones que deban copiarse. Un patrón frecuente puede ser familiar, pero deberá contrastarse con el contexto propio.

6. Priorizar escenarios

No todos los escenarios tienen el mismo peso. Pueden priorizarse mediante:

• Frecuencia.
• Criticidad.
• Cantidad de personas afectadas.
• Valor del resultado.
• Riesgo de error.
• Incertidumbre de diseño.

Priorizar no significa descartar casos menos frecuentes. Un escenario excepcional puede requerir atención si sus consecuencias son graves o si revela una barrera de accesibilidad.

Ejemplo: revisión interna de solicitudes

En el caso ficticio de la serie, el marco de intención indicó que una persona debe determinar si una solicitud puede avanzar. La investigación de contexto podría producir este escenario:

Una analista recibe una solicitud marcada como pendiente. Realiza revisiones durante gran parte de su jornada en una computadora de escritorio y alterna con otros sistemas. Necesita identificar rápidamente datos incompletos y reglas que bloquean el avance.

Las interrupciones son frecuentes. Si interpreta un bloqueo como advertencia menor, la solicitud puede regresar más adelante y generar retrabajo. La tarea termina cuando solicita una corrección o envía la solicitud a formalización y recibe confirmación del nuevo estado.

Este escenario no prescribe pestañas, modales ni una página única. Sin embargo, empieza a revelar condiciones de diseño:

• El estado y los bloqueos necesitan alta visibilidad.
• Debe conservarse el avance frente a interrupciones.
• Las acciones dependen de reglas y permisos.
• El sistema debe confirmar el resultado y el nuevo estado.
• Cambiar entre herramientas incrementa el esfuerzo.

Estas son implicaciones, no soluciones definitivas. Las siguientes etapas deberán determinar cómo organizar, nombrar y hacer accesible la información.

Entregable: matriz de contexto

La etapa concluye con una fila por cada combinación relevante de actor, tarea y situación. Además de los campos anteriores, conviene añadir:

• Evidencia que respalda la condición.
• Nivel de certeza.
• Implicación preliminar.
• Pregunta pendiente.

Una implicación como “el estado debe reconocerse rápidamente” todavía no decide color, tamaño ni posición. Solamente establece una necesidad que deberá resolverse y validarse después.

Qué deja resuelto para la interacción

Esta etapa permite conocer:

• Qué condiciones deberá soportar la experiencia.
• Qué información se necesita en cada situación.
• Qué errores requieren prevención o recuperación.
• Qué diferencias entre actores pueden modificar rutas y permisos.
• Qué escenarios deberán representarse en flujos, estructura y prototipos.

Todavía no determina categorías, navegación, rótulos ni pantallas.

Ejercicio

Seleccionar una tarea y redactar dos escenarios contrastantes. Ambos deberán conservar el mismo objetivo, pero cambiar una condición relevante: frecuencia, experiencia, dispositivo, interrupción, permiso o consecuencia del error.

Después, completar la matriz y responder:

1. ¿Qué decisión de diseño cambia entre los escenarios?
2. ¿Qué dato respalda esa diferencia?
3. ¿Qué información todavía falta investigar?

Conclusión

Definir el contexto transforma un objetivo abstracto en condiciones de uso observables. No se trata de decorar una persona con datos biográficos, sino de comprender la relación entre actor, tarea, entorno, información, dependencias y riesgo.

Con los objetivos y escenarios documentados, la siguiente etapa podrá estudiar cómo se agrupa y recorre la información. El sistema de navegación dejará de partir del organigrama o de las preferencias del equipo y comenzará a construirse alrededor de rutas necesarias para completar tareas reales.