Design System para SEPE
Creación de un sistema de diseño escalable para la plataforma del Servicio Público de Empleo Estatal.
Contexto
Un sistema de diseño para el ecosistema digital del SEPE
Diseñé y documenté un sistema completo para la plataforma web del Servicio Público de Empleo Estatal (SEPE) con el objetivo de mejorar la consistencia visual, optimizar la colaboración entre diseño y desarrollo, y facilitar la escalabilidad del producto.
El sistema fue concebido para dar soporte a distintos productos digitales bajo el ecosistema SEPE, como la Sede Electrónica, garantizando una experiencia coherente para los usuarios y una base de trabajo común para todos los equipos implicados.
El resultado fue un sistema modular compuesto por 5 librerías de Figma —fundamentos, componentes, recursos, iconos y plantillas— junto con su documentación asociada. Esta estructura redujo aproximadamente un 40% el tiempo de diseño de nuevas funcionalidades, además de mejorar la comunicación entre diseñadores y desarrolladores.
El problema
Un ecosistema fragmentado con múltiples equipos
El ecosistema digital del SEPE había crecido progresivamente y era desarrollado por equipos multidisciplinares pertenecientes a diferentes empresas proveedoras. Esto generaba:
- Cada equipo diseñaba y desarrollaba componentes de forma independiente
- Inconsistencias visuales entre productos
- Componentes y soluciones de diseño duplicados
- Un sistema difícil de mantener y escalar
- Dificultades para traducir los diseños a código
Al tratarse de un entorno de administración pública con múltiples proveedores, la falta de una base común hacía especialmente compleja la coordinación entre equipos.
Objetivos
Resolver problemas de diseño, organización y colaboración
- Crear una base visual consistente para todo el ecosistema digital
- Reducir la duplicación de componentes
- Mejorar la comunicación entre diseño y desarrollo
- Facilitar la escalabilidad del producto
- Establecer reglas claras de uso y documentación
Estrategia
Una arquitectura pensada para escalar
Uno de los aspectos clave fue definir cómo estructurar el sistema para escalar a largo plazo. No se trataba únicamente de crear componentes, sino de construir una arquitectura que permitiera mantener el sistema de forma sostenible y que pudiera ser utilizada por múltiples equipos.
Fundamentos
Colores, tipografía, espaciados, elevaciones y demás valores base.
Componentes
Elementos reutilizables como botones, inputs, cards o menús.
Iconos
Sistema unificado de iconografía.
Recursos
Elementos auxiliares para diseño y prototipado.
Plantillas
Estructuras de páginas y layouts reutilizables.
Esta separación respondía a varias decisiones estratégicas:
1 Escalabilidad y rendimiento
Los sistemas concentrados en un único archivo tienden a volverse difíciles de mantener y ralentizan las herramientas de diseño. Dividir el sistema en librerías independientes mejora el rendimiento de Figma, mantiene los archivos más ligeros y facilita la evolución del sistema.
2 Flexibilidad para diferentes productos
Separar tokens y componentes permite que los componentes no dependan de valores visuales fijos, sino que consuman tokens del sistema. Así se pueden adaptar estilos visuales sin rediseñar componentes, reutilizar la lógica del sistema en distintos productos y mantener la consistencia sin perder flexibilidad.
3 Gobernanza y mantenimiento
Los cambios en los tokens se propagaban automáticamente a los componentes y los equipos podían dividir responsabilidades (Design Ops, diseño de producto, desarrollo). Esta estructura también ayudó a controlar los snowflakes: componentes únicos creados para un caso concreto que terminan contaminando el sistema.
Design Tokens
Una nomenclatura clara para conectar diseño y código
La definición de tokens fue uno de los pilares del sistema. Antes de diseñar las foundations, fue necesario establecer una estructura clara de nomenclatura, basada en el modelo propuesto por Nathan Curtis y adaptada a las necesidades del proyecto. La estructura se organizó jerárquicamente para facilitar su comprensión y reutilización.
Esto permitió mantener la consistencia en todo el sistema, dar claridad a los equipos de diseño y desarrollo, y crear una relación directa entre diseño y código.
Estandarización en Figma
Reglas claras de organización para todos los equipos
Otro de los principales puntos de fricción detectados era la falta de consistencia en la organización de archivos y capas dentro de Figma: capas sin nombres descriptivos, jerarquías inconsistentes y componentes difíciles de interpretar. Para solucionarlo se definieron reglas de nomenclatura y organización:
- Convenciones para nombrar capas
- Estructura de agrupación de elementos
- Nomenclatura de variantes
- Organización de componentes y subcomponentes
Gracias a estas normas, cualquier diseñador o desarrollador podía entender rápidamente la estructura de un componente.
Convenciones de nomenclatura de componentes
Los nombres siguen una estructura clara y consistente, con capitalización en cada palabra para facilitar la lectura:
Form Input Text
Form Radiobutton
Form Select
Construcción de componentes
Se estableció una jerarquía clara entre componentes principales, subcomponentes y moléculas o agrupaciones, lo que facilitó la reutilización y evitó inconsistencias.
Uso de properties
Las component properties de Figma se utilizaron para permitir configuraciones rápidas dentro de los componentes: mostrar u ocultar iconos, cambiar estados o modificar variantes. Las convenciones visuales y de nomenclatura consistentes, tanto en capas como en propiedades configurables, hicieron el sistema más fácil de usar por otros diseñadores.
Impacto
Beneficios para diseño, desarrollo y organización
Para diseño
- Mayor consistencia visual
- Reutilización de componentes
- Reducción del tiempo de diseño
Para desarrollo
- Mejor traducción de diseños a código
- Menos ambigüedades en la implementación
- Reducción de inconsistencias
Para la organización
- Base común para múltiples equipos
- Sistema escalable
- Mejor gobernanza del producto
«Un Design System no es solo una librería de componentes, sino una infraestructura de producto que requiere una arquitectura clara, reglas de uso compartidas, documentación accesible y colaboración entre diseño y desarrollo.»
¿Te cuento más?
Hablemos de cómo un design system puede acelerar tu producto.