En corto: La estructura no es un acomodo estético. Traduce al espacio y al comportamiento las decisiones sobre tareas, información, rutas, lenguaje y recuperación.
Esta etapa integra los resultados anteriores en jerarquías, comportamientos, estados y wireframes. El resultado será un modelo táctico listo para validarse, no una interfaz visual terminada.
Por qué la serie termina aquí
En Arquitectura de la información: diseño e implementación, Celso Gonzales Cam representa la estructuración mediante esquemas jerárquicos, segmentación de espacios, menús y bocetos. Así puede discutirse antes de implementarla.
El término Diseño Táctico de Interacción (DTI) no aparece en esa fuente. UXicans lo propone para nombrar el momento en que la evidencia y la estructura se convierten en decisiones concretas de interacción:
La traducción de tareas, modelos de información y reglas del sistema en una estructura espacial y conductual que pueda comprenderse y validarse antes del diseño visual final.
El artículo Por qué la Arquitectura de la Información sí condiciona el espacio gráfico desarrolla el fundamento de esta propuesta. La Arquitectura de la Información no sustituye al Diseño de Interacción ni a la interfaz; les proporciona parte de la lógica que deberán materializar.
Qué se ha construido hasta ahora
| Etapa | Resultado acumulado |
|---|---|
| 1. Objetivos | Tarea prioritaria, resultados, evidencia, restricciones y criterios de éxito |
| 2. Contexto | Actores, escenarios, condiciones de uso, dependencias y riesgos |
| 3. Navegación | Organización, jerarquía, rutas, entradas, retorno y destinos |
| 4. Rotulado | Lenguaje de objetos, acciones y estados |
| 5. Búsqueda | Consulta, coincidencia, resultados, refinamiento y recuperación |
Al integrar estos resultados pueden aparecer contradicciones, información ausente o rutas innecesarias. La etapa 6 también permite regresar a la decisión que los originó.
Método para convertir la arquitectura en interacción
1. Construir una matriz de trazabilidad
Antes de dibujar se relacionará cada decisión con su fundamento:
| Campo | Pregunta |
|---|---|
| Tarea | ¿Qué intenta lograr la persona? |
| Evidencia | ¿Qué observación, dato o restricción sustenta la necesidad? |
| Información o acción | ¿Qué necesita conocer o hacer? |
| Mecanismo | ¿Cómo podrá acceder, decidir o actuar? |
| Prioridad | ¿Qué peso tiene en este momento de la tarea? |
| Estado | ¿En qué condiciones cambia? |
| Validación | ¿Qué deberá comprobarse? |
Esta matriz evita justificar una pantalla mediante frases como “se ve mejor” o “así se acostumbra”. También separa la evidencia de la interpretación: una necesidad puede admitir varias soluciones.
2. Crear un inventario de pantallas o espacios
Una pantalla debe existir porque soporta una necesidad de información, decisión o interacción. No todo nodo de un proceso necesita interfaz: una validación automática, una transferencia de datos o una notificación generada por el sistema pueden ocurrir sin crear una pantalla independiente.
Para cada espacio se registrará:
- Propósito.
- Tarea que soporta.
- Punto de entrada.
- Información necesaria.
- Acciones disponibles.
- Estados y excepciones.
- Salida o continuidad.
El artículo Cómo pasar de un proceso To Be a un user flow sin convertir cada nodo en una pantalla explica con mayor detalle esta separación.
3. Definir la jerarquía según el momento de la tarea
La prioridad no pertenece permanentemente a un elemento. Cambia según el estado y la decisión que debe tomarse.
Para establecerla se responderá:
- ¿Qué necesita reconocerse primero?
- ¿Qué información permite decidir?
- ¿Qué bloquea o modifica la tarea?
- ¿Qué acción puede ejecutarse ahora?
- ¿Qué contenido es secundario, histórico o consultivo?
Después se traducirá mediante orden, peso, agrupación y ubicación. El artículo Cómo decidir la jerarquía visual de una pantalla con evidencia profundiza en este procedimiento.
No se asumirá que lo colocado a la izquierda es universalmente más importante ni que toda información debe verse al mismo tiempo. Idioma, dispositivo, patrón de lectura, frecuencia, riesgo y relaciones entre contenidos modifican la decisión.
4. Seleccionar mecanismos de acceso e interacción
Las rutas definidas en navegación pueden materializarse mediante menú, lista, enlace contextual, pestaña, breadcrumb, acceso reciente o búsqueda. El mecanismo se elegirá por la tarea, no por la cantidad aislada de niveles.
La llamada “regla de los tres clics” no servirá como medida de calidad. La investigación de Center Centre no encontró que las personas abandonaran una tarea al superar tres clics. Resultan más importantes la claridad de cada elección, la información que anticipa el siguiente paso y la continuidad del contexto.
Tampoco existe una prohibición universal de mostrar “Inicio” porque un logotipo pueda cumplir esa función. La decisión dependerá de las expectativas, el espacio, la accesibilidad y el comportamiento comprobado.
5. Definir reglas, acciones y estados
Una arquitectura visible pero sin comportamiento todavía no constituye una interacción. Para cada acción se documentará:
- Cuándo aparece.
- Cuándo está habilitada o bloqueada.
- Qué información necesita.
- Qué modifica.
- Qué respuesta produce.
- Cómo se deshace o corrige cuando corresponda.
- Qué sucede si el sistema falla.
Los wireframes deberán representar los estados que cambian la tarea: inicial, carga, vacío, advertencia, bloqueo, error, éxito y permisos insuficientes. No será necesario dibujar todas las combinaciones posibles, pero sí aquellas que alteren la comprensión o las acciones disponibles.
6. Elaborar wireframes de baja fidelidad
Un wireframe de baja fidelidad permite discutir estructura, contenido y comportamiento sin invertir todavía en el acabado visual. Su fidelidad no depende únicamente del uso de blanco y negro, sino del grado de detalle y certeza que representa.
Deberá mostrar:
- Orden y agrupación de la información.
- Jerarquía de títulos, datos, alertas y acciones.
- Navegación y búsqueda cuando correspondan.
- Contenido suficientemente realista para evaluar comprensión.
- Variantes de estado esenciales.
- Anotaciones de comportamiento que no sean visibles en una imagen estática.
La relación visual también necesita conservarse en la estructura del contenido. WCAG 2.2 señala que la información y las relaciones comunicadas visualmente deben poder determinarse de otras formas. Por ello, agrupación, encabezados y orden de lectura no se tratarán como decoración.
7. Convertir el wireframe en una hipótesis evaluable
La integración de evidencia no demuestra que la solución funcione. El wireframe o prototipo se probará con tareas y escenarios representativos para observar:
- Dónde se intenta comenzar.
- Qué se reconoce primero.
- Cómo se interpreta el estado.
- Qué ruta o mecanismo se elige.
- Qué se espera que ocurra al actuar.
- Si se distingue la acción principal.
- Cómo se comprende el resultado y la recuperación.
Los hallazgos podrán modificar rótulos, rutas, jerarquías o incluso los objetivos. La validación cierra una vuelta del proceso, no la posibilidad de iterar.
Ejemplo: la jerarquía cambia con el estado
En el sistema ficticio, la pantalla de revisión contiene identificador, estado, datos, bloqueos, documento, historial y acciones. Mostrar todo con el mismo peso impediría reconocer qué requiere atención.
Cuando existen bloqueos, la estructura podría priorizar:
- Identificador y estado de la solicitud.
- Resumen de bloqueos.
- Datos afectados y explicación cercana.
- Acción principal: “Solicitar corrección”.
- Acción “Enviar a formalización” bloqueada con su motivo.
- Documento, historial y comentarios como consulta secundaria.
Cuando los bloqueos desaparecen, cambia la jerarquía: “Enviar a formalización” puede convertirse en la acción principal y el resumen de problemas deja de ocupar el primer nivel.
La arquitectura no determinó un color o estilo final. Determinó qué relaciones, prioridades y estados deberá hacer comprensibles la interfaz.
Entregable: paquete de Diseño Táctico de Interacción
| Artefacto | Qué documenta |
|---|---|
| Matriz de trazabilidad | Relación entre tarea, evidencia y decisión |
| Inventario de pantallas | Propósito, información, acciones, entradas y salidas |
| Flujo y estados | Ruta principal, alternativas, reglas y excepciones |
| Wireframes | Jerarquía, agrupación, mecanismos y comportamiento esencial |
| Guion de validación | Tareas, preguntas, observaciones y criterios |
El paquete puede concentrarse en un solo documento. Lo importante es conservar la relación entre las piezas y las decisiones pendientes.
Ejercicio
Seleccionar una pantalla y elaborar una matriz con: tarea, evidencia, información, acción, prioridad, estado y validación. Después dibujar dos wireframes de la misma pantalla en estados distintos.
Comparar:
- Qué cambia de posición o peso.
- Qué acción se habilita o bloquea.
- Qué información aparece o deja de ser prioritaria.
- Qué decisión necesita todavía evidencia.
Conclusión
La Arquitectura de la Información no termina al producir un sitemap. Se vuelve tangible cuando sus relaciones, rutas, rótulos y mecanismos condicionan lo que puede comprenderse y hacerse dentro de una interfaz.
El Diseño Táctico de Interacción nombra esa convergencia sin confundir disciplinas: la arquitectura aporta estructura y lenguaje; la interacción define comportamiento; la interfaz los vuelve perceptibles y operables.
El resultado no es una colección de cajas ni una respuesta definitiva. Es una hipótesis estructurada, trazable y suficientemente concreta para ponerse frente a usuarios, detectar errores y continuar diseñando con evidencia.
Leave a Comment