CASO DE ESTUDIO → ARQUITECTURA UX PARA INFRAESTRUCTURA CRÍTICA
Arquitectura de interfaz UI, diseño de la experiencia UX, flows de navegación completos y estrategia UX/UI — para una plataforma nacional de ciberseguridad con datos clasificados y cero tolerancia al error.
Un sistema de inteligencia operacional en la intersección entre arquitectura UX, ingeniería de backend y restricciones de seguridad nacional.
Caso de estudio
Publicaremos el case study completo muy pronto. Mientras tanto puedes explorar ANA en la web oficial del CCN-CERT.
01 — EL CONTEXTO
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."
ANA opera en entornos de alta seguridad. Acceso restringido.
02 — MI ROL
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.
Recorrido en el proyecto Backend → wireframes de validación con el equipo técnico → diseño completo de la capa de interacción → liderazgo de la arquitectura UX de ANA y CLARA — operando como puente permanente entre las decisiones de ingeniería y el comportamiento del producto.
La ventaja estructural
La transición fue progresiva: primero wireframes para validar flujos con el equipo técnico, después diseño completo de la capa de interacción, finalmente liderazgo de la arquitectura UX de ANA y de CLARA — operando como puente permanente entre las decisiones de ingeniería y el comportamiento del producto.
03 — EL RETO
ANA no es una herramienta de un solo uso. Es una plataforma modular con cuatro áreas de funcionalidad distintas, cada una respondiendo a un perfil de operador diferente con necesidades de información distintas.
El reto de diseño no era cada módulo por separado. Era crear una arquitectura de sistema que hiciera coherente la experiencia entre los cuatro — con roles distintos, niveles de acceso distintos y flujos de trabajo que cruzaban módulos sin que el operador tuviera que reconstruir el contexto.
VULNERABILIDADES
Automatización y normalización del proceso de auditoría. El operador necesita saber en segundos qué es crítico, qué está pendiente y qué ha sido resuelto. Sin construir ese contexto manualmente cada vez que abre la plataforma.
INSPECCIÓN TÉCNICA
Seguimiento de planes correctores y procesos de mejora. Estados, plazos y evolución temporal. La interfaz tiene que soportar ese seguimiento sin convertirlo en trabajo administrativo.
SUPERFICIE DE EXPOSICIÓN
El operador evalúa el nivel de exposición de una organización considerando la relevancia operativa de cada amenaza — no solo su severidad técnica abstracta.
PERFILADO DE CUMPLIMIENTO
Estado de cumplimiento respecto a normativas oficiales. El operador necesita una lectura global y la capacidad de profundizar en entidades específicas sin perder el contexto general.
04 — EL DIAGNÓSTICO
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.
PROBLEMA 1
La 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.
PROBLEMA 2
Sin 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.
PROBLEMA 3
Para 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.
PROBLEMA 4
ANA 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.
05 — LA DECISIÓN
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.
DESCARTADO
Habrían mejorado la apariencia sin cambiar el comportamiento. El operador seguiría construyendo contexto manualmente. Los dashboards seguirían siendo inventarios de datos sin orientación operativa. La fricción habría cambiado de sitio, no desaparecido.
DESCARTADO
Sin continuidad con el sistema que los operadores ya conocían. En entornos de alta seguridad, la resistencia a nuevas interfaces es el primer bloqueador de adopción. Un rediseño total sin referencia al sistema existente habría generado un período de rechazo que el equipo no podía asumir.
COMPROMETIDOS CON
Un sistema donde la interfaz establece el contexto antes de que el operador empiece a trabajar. Información operativa en la superficie, no detrás de ella. Jerarquía estructural, no solo visual. Un lenguaje compartido de criticidad que funciona en todos los módulos.
06 — EL SISTEMA · DASHBOARD
La primera decisión fue el dashboard principal. La versión de ingeniería era técnicamente correcta — mostraba los datos. Era operacionalmente inútil — el analista construía mentalmente su flujo de trabajo cada vez que abría la plataforma.
El rediseño partió de una pregunta concreta: ¿qué tiene que saber el operador en los primeros 30 segundos de su turno?
La respuesta determinó la jerarquía: Estado general como señal dominante e inmediata. Total de vulnerabilidades con distribución visual por criticidad. Auditorías activas con progreso por tipo de sistema. Vista resumen con números de acción directa — activos, hallazgos corregidos, hallazgos pendientes.
Cada widget expandible mediante el botón +. El operador decide qué información necesita visible en cada momento sin cambiar de pantalla. Y puede reordenar las tarjetas según su flujo de trabajo real — el dashboard no es una pantalla impuesta, es un espacio de trabajo que el operador hace suyo.
Aprendizaje
El dashboard dejó de ser un inventario de datos y pasó a ser una superficie de trabajo. La jerarquía de información reemplazó la construcción mental del contexto. El operador llega, lee, decide.
Estado general prominente, métricas de acción directa, jerarquía operativa clara.
06 — EL SISTEMA · ASSETS
El sistema de tarjetas de assets fue una de las decisiones con más impacto operacional del proyecto.
Antes: tarjeta con icono y nombre. Para saber el estado de criticidad de un grupo había que entrar y ver el listado. Navegación ciega en un entorno donde el tiempo de orientación importa.
Después: cada tarjeta es un resumen ejecutivo autónomo. Tipo de entidad visible mediante badge — Grupo o Asset. Número de assets que contiene el grupo. Distribución de criticidad mediante puntos de color numerados — cuántos assets son críticos, cuántos altos, cuántos medios, cuántos bajos, cuántos informativos.
El operador escanea la vista y sabe dónde está el problema sin navegar, sin hacer click, sin reconstruir contexto.
Aprendizaje
Información operativa en la superficie elimina navegación exploratoria en entornos donde cada segundo cuenta. La tarjeta dejó de ser un acceso a la información y se convirtió en la información.
Cada tarjeta informa sin necesidad de navegar.
06 — EL SISTEMA · CRITICIDAD
La codificación de criticidad en la versión anterior era principalmente cromática. El problema de depender solo del color en un entorno de trabajo con múltiples pantallas, turnos extendidos y condiciones de luz variables es predecible.
Definí un sistema de criticidad estructural — no solo visual. Cinco niveles con codificación cromática consistente en todos los módulos: Critical en morado, High en rojo oscuro, Medium en naranja, Low en amarillo, Info en verde. Pero la criticidad no vive solo en el color — vive en la posición jerárquica, el peso tipográfico y el tamaño del elemento dentro de cada vista.
Un hallazgo crítico es estructuralmente diferente de uno medio. El operador identifica el nivel de criticidad incluso en condiciones de visualización subóptimas.
"Un sistema. Un lenguaje. Cero ambigüedad."
Cinco niveles con codificación estructural — no solo visual.
06 — EL SISTEMA · AGREGACIÓN
ANA y las plataformas del ecosistema CCN operan de forma independiente. Cada una vive en su silo. Un operador o director que necesita el estado global de seguridad de su organización tenía que abrir sistemas distintos, navegar por cada uno y construir mentalmente una imagen unificada.
Propuse y diseñé un Dashboard General que agrega la información más relevante de cada plataforma del ecosistema en una sola superficie. Sin reemplazarlas. Sin fusionarlas. Cada módulo del dashboard es un resumen ejecutivo de su plataforma — con el mismo sistema de semáforos, la misma arquitectura de información, el mismo lenguaje de criticidad.
El director ve el estado global de seguridad de su organización en 30 segundos. Sin abrir tres sistemas. Sin construir contexto.
Actualmente en desarrollo. Disponible para ver en conversación.
Aprendizaje
Proponer un dashboard cross‑platform en un entorno donde cada herramienta tiene su propio equipo y su propia lógica de datos requiere entender la arquitectura de los sistemas desde dentro. No fue una petición del cliente — fue una propuesta de arquitectura que nació de conocer el backend de cada plataforma.
Estado global de seguridad en 30 segundos. Sin abrir tres sistemas.
07 — EL PROBLEMA DE ESCALA
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.
DOCUMENTACIÓN
Generé documentación completa de uso de la herramienta — no como entregable de cierre, sino como parte del sistema de control. Cada componente documentado con sus entradas, sus restricciones y su comportamiento esperado. Un componente sin documentación en un entorno de infraestructura crítica es una decisión sin contrato.
COMUNICACIÓN
Generé también las presentaciones de venta de la plataforma. Entendía el producto lo suficiente como para articular su valor ante clientes que no son técnicos — traducir arquitectura de sistema en propuesta de negocio. Esa doble capacidad — construir el sistema y comunicarlo hacia fuera — fue parte del valor que aporté al equipo.
RESTRICCIONES
En entornos de alta seguridad, las restricciones son el material de trabajo. El modelo de roles y permisos no podía ser una capa técnica invisible — tenía que manifestarse en la experiencia. La arquitectura de información de cada rol se diseñó desde la pregunta correcta: no qué puede ver cada perfil, sino qué decisiones toma y qué necesita para tomarlas.
08 — RESULTADOS
Tiempos de gestión en auditorías
−40%
Reducción en tiempos de gestión de inspecciones técnicas en auditorías de seguridad.
Velocidad reactiva
×3
Implantación y seguimiento de medidas correctoras y planes de remediación.
Notificación de amenazas
−60%
Reducción en tiempos de notificación de nuevas amenazas que impactan la organización.
Contexto operacional
Los analistas tardaban significativamente menos en identificar prioridades al inicio de cada turno. La arquitectura del dashboard orientada a flujo de trabajo eliminó el paso de construcción mental que antes hacían manualmente.
La adopción fue inmediata sin período de resistencia. En plataformas internas de alta seguridad, la resistencia a nuevas interfaces es el primer bloqueador. La validación continua con operadores reales durante el diseño generó una transición sin fricción.
El modelo de roles implementado desde la capa de experiencia no generó ningún incidente de acceso no autorizado. La arquitectura de información cumplió los requisitos de seguridad sin capas técnicas adicionales de control.
El resultado más verificable
Sistema clasificado
Producción activa
ANA está desplegada y en uso activo en organismos públicos y privados bajo supervisión del CCN‑CERT. Plataforma en producción para la autoridad nacional de ciberseguridad de España.
09 — REFLEXIÓN
Diseñar para analistas de seguridad nacional enseña algo que el diseño de producto convencional raramente exige: que la interfaz no es el producto. El producto es el sistema de decisiones que la interfaz soporta.
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."
Qué haría distinto
Involucrar a los operadores antes en la definición de restricciones, no solo en la validación de soluciones. El conocimiento operacional de los analistas emergió en sesiones de validación tardías — cuando algunos cambios de arquitectura ya eran costosos de revertir. En sistemas complejos, el research de restricciones es tan importante como el research de usuarios.
