eSBARD Edu
De los wireframes de un experto a una plataforma que se entiende
Diseñamos la experiencia de una plataforma de formación práctica en ciberseguridad, traduciendo la visión muy técnica de su creador en flujos claros para los formadores que preparan los ejercicios de su alumnado.
Resumen
- Problema
- Practicar ciberseguridad de forma realista y segura era difícil para los centros de formación, según detectó el responsable de ciberseguridad hablando con profesorado.
- Mi papel
- Diseñar la plataforma, desde los wireframes técnicos del responsable de ciberseguridad hasta las pantallas finales y su design system.
- Solución
- Una plataforma en la nube donde el formador prepara laboratorios, retos y ejercicios de ataque y defensa en un mismo entorno, para su alumnado.
- Resultado
- El producto está en funcionamiento y el profesorado que vio el prototipo lo valoró muy positivamente.
Contexto
eSBARD Edu es un producto propio de la consultora. Nació de una necesidad que el responsable de ciberseguridad detectó hablando con profesorado de universidad y formación profesional (FP): no disponían de una forma sencilla de que su alumnado practicara ataques y defensas reales en un entorno seguro.
La plataforma es una herramienta para el formador: le permite preparar tareas o exámenes de ataque y defensa para su alumnado. Con ella crea laboratorios virtuales en los que el alumnado ataca (Red Team, el equipo atacante) y defiende (Blue Team, el defensor), prepara retos tipo CTF (capture the flag, competiciones de resolución de retos) y supervisa lo que hace cada alumno. El alumnado trabaja dentro de esos laboratorios, por lo que la interfaz que diseñamos es el panel del formador.
El reto
El punto de partida eran unos wireframes de baja fidelidad, pero muy densos en información técnica, hechos por el responsable de ciberseguridad, una persona con un conocimiento técnico muy avanzado. Buena parte de la complejidad del producto estaba en su cabeza.
Nuestro reto era doble:
- Entender un dominio muy técnico lo bastante bien como para poder simplificarlo.
- Hacerlo usable para el mayor número de personas posible. Los usuarios son perfiles técnicos, pero el nivel de complejidad era muy alto.
Además, el diseño debía mantener continuidad con eSBARD, la versión profesional del producto: una plataforma basada en Grafana, sin publicar, de la que solo existían en Figma el logo y una paleta básica de colores.
Momentos clave
Traducir antes de diseñar
No hubo investigación con usuarios al uso: nuestra investigación fue entender al experto. Trabajamos muy de cerca con el responsable de ciberseguridad, revisando con él cada flujo y cada pantalla de sus wireframes hasta entender qué hacía cada herramienta, para quién y en qué momento. Sin esa fase, cualquier simplificación habría sido superficial.
Mapa original de wireframes: decenas de pantallas, flujos y anotaciones técnicas Simplificar sin quitar potencia
Reorganizamos la información para que fuera fácil encontrar las herramientas y entender los flujos del panel del formador. La herramienta sigue siendo compleja (requiere una formación previa), pero el objetivo era que la complejidad estuviera en los ejercicios, no en la interfaz.
Un ejemplo es la asignación de usuarios a los equipos. En el wireframe original, una sola tabla mezclaba los datos técnicos (grupo de WireGuard, imagen de máquina virtual, dos direcciones IP) con la lista de usuarios de Red Team y Blue Team. Propusimos que crear un laboratorio fuera un asistente por pasos (General, Usuarios, Scripts y Resumen). La separación por equipos ya venía de los wireframes del responsable de ciberseguridad; en la pantalla final, cada equipo es un bloque con su lista, su IP de VPN y acciones para asignar o eliminar.
Antes: wireframe original 
Después: pantalla final Construir sobre un sistema, pensando en el futuro
Partimos del UI Kit de Saga, el sistema de diseño de Grafana publicado en Figma, para crear el design system de eSBARD Edu. Como eSBARD está basado en Grafana y no tenía nada en Figma, adaptar un sistema ya existente daba continuidad visual con la plataforma y una base sólida. Así, eSBARD y eSBARD Edu podrían crecer de forma coherente.
Fundamentos: color y tipografía Componentes y composición Accesibilidad de la identidad visual
De eSBARD solo existían el logo y una paleta básica de colores, con problemas de accesibilidad. Propusimos ajustar la paleta y la tipografía, y las propuestas se aceptaron. Comprobamos el contraste con Stark. El texto principal, un gris claro (#CCCCDC) sobre las superficies de la interfaz (#22262B), alcanza una ratio de 9,57:1 y cumple el nivel AAA, el más exigente de las pautas de accesibilidad WCAG. El morado de acento (#7264E5) sobre el fondo oscuro (#181B1F) llega a 3,84:1, que cumple el nivel AA para elementos gráficos y de interfaz, como botones e iconos. Elegimos BBC Reith Sans tras investigar tipografías accesibles: la BBC la creó junto con Dalton Maag para mejorar la legibilidad en pantalla y la accesibilidad.
Texto principal: 9,57:1, nivel AAA 
Acento de interfaz: 3,84:1, nivel AA para elementos gráficos
La solución
Las pantallas que se muestran en la web de presentación del producto las diseñé yo. Las capturas usan datos de demostración.
Validación y resultados
- Con el profesorado: mostramos el prototipo a profesorado universitario. La valoración fue muy positiva: veían la plataforma como una herramienta realmente útil y entendían bien cómo estaba planteada.
- En el equipo: el feedback de compañeros de la consultora sobre el diseño visual fue muy bueno.
- Hoy: la plataforma está en funcionamiento y se comercializa para centros educativos y empresas.
No pudimos hacer tests de usabilidad con usuarios finales. Tras entregar el diseño al equipo de desarrollo, salí del proyecto y no tengo datos de uso.
Aprendizajes
- En productos técnicos, buena parte de diseñar es traducir. Nuestra aportación más valiosa no fueron las pantallas, sino entender lo suficiente para convertir la complejidad en algo usable.
- Pensar en sistema desde el principio facilita que un producto con varias versiones crezca de forma coherente.
- Lo que haríamos diferente: incluir tests de usabilidad con formadores antes de cerrar el diseño, y pedir acceso a datos de uso para seguir iterando.
