Donde el dato manda y el error no cabe

ANA — Automatización y Normalización de Auditorías — es la solución de gobernanza técnica del CCN-CERT para la gestión de la superficie de exposición en ciberseguridad. Automatiza la evaluación continua de vulnerabilidades sin intervención humana. Se integra con el ecosistema de herramientas del Centro Criptológico Nacional. Genera alertas tempranas antes de que una amenaza se convierta en incidente.

El problema no era técnico. La plataforma procesaba datos reales de múltiples fuentes con lógica correcta. El problema era que los operadores que tenían que trabajar con ella cada día no podían hacerlo con la velocidad y precisión que el entorno exigía.

Los dashboards los construían los ingenieros. La información existía — pero sin arquitectura de decisión. Sin jerarquía. Sin orientación al flujo de trabajo del analista.

“Cuando los datos son correctos pero la interfaz no los hace operables, el sistema falla igual.”

Entré en este proyecto como desarrollador backend. C#, .NET, MongoDB — construí los pipelines de datos que alimentaban la plataforma. Los mismos datos que después tendría que hacer visibles y operables en la interfaz.

La empresa vio potencial donde yo no lo veía todavía. Invirtieron en dos masters de UX/UI y Product Design para que pudiera hacer la transición. Volví al mismo sistema que había construido por dentro — esta vez desde la capa de experiencia.

Eso no fue un accidente. Fue la ventaja. Entender la arquitectura del sistema antes de diseñar cómo se mostraba cambió completamente el tipo de decisiones que podía tomar. No diseñaba sobre supuestos — diseñaba sobre la estructura real de los datos, sus relaciones y sus restricciones. No había handoff entre diseño e ingeniería. Era la misma persona en los dos lados de la mesa.

El pensamiento sistémico dejó de ser una preferencia aquí. Se convirtió en un requisito.

Antes de rediseñar ninguna pantalla, mapeé los flujos de trabajo reales. Qué hacen los analistas cuando abren la plataforma. Dónde pierden tiempo. Qué información buscan que no encuentran donde esperan. Qué decisiones toman y con qué datos.

El patrón era claro.

1. 01La interfaz seguía la lógica del sistema, no la del operadorLa navegación estaba organizada por módulos técnicos. Un analista cuyo flujo de trabajo cruzaba vulnerabilidades y superficie de exposición navegaba entre secciones distintas reconstruyendo el contexto cada vez. El sistema era coherente con su propia arquitectura. No era coherente con cómo trabaja un analista de seguridad bajo presión.
2. 02Los dashboards los construían los ingenierosSin arquitectura de decisión. Sin jerarquía operativa. Todos los datos con el mismo peso visual — crítico y bajo competían por atención. El operador construía mentalmente la prioridad que la interfaz debería haber establecido por él.
3. 03Las tarjetas de assets no informaban sin navegarPara saber el estado de criticidad de un grupo de activos había que entrar. Navegación ciega — click para descubrir. En un entorno donde el tiempo de respuesta importa, cada clic innecesario es fricción operacional.
4. 04El modelo de roles no se manifestaba en la experienciaANA tiene múltiples perfiles — analistas, supervisores, dirección. Los permisos técnicos determinaban el acceso. Pero la arquitectura de información mostraba lo mismo a todos. Lo que ve un analista y lo que necesita un director son dos cosas distintas que la plataforma trataba como una sola.

Lo obvio era mejorar la UI de cada módulo por separado. Teníamos los módulos definidos, el equipo técnico disponible y los datos funcionando. Decidimos no hacerlo. El problema no era visual: era arquitectónico.

El sistema tenía que funcionar para analistas con flujos de trabajo distintos, en organizaciones con estructuras distintas, bajo niveles de clasificación distintos. No podíamos validar con todos. Teníamos que diseñar con suficiente rigor estructural para que el sistema funcionara en contextos que no habíamos visto.

En Vocento, una mala decisión de diseño reducía la conversión. En ANA, una mala decisión de diseño comprometía una investigación. Esa diferencia de consecuencias no cambia el proceso — cambia el rigor con el que evalúas cada decisión de arquitectura.

“Los sistemas no fallan por la calidad del diseño. Fallan porque la interfaz no hace operable la inteligencia que hay dentro.”