Contexto del proyecto
Un sistema de diseño para el ecosistema digital del SEPE
Diseñé y documenté un Design System 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 se concibió para dar soporte a distintos productos digitales bajo el ecosistema SEPE, como la Sede Electrónica, garantizando una experiencia coherente para las personas usuarias y una base de trabajo común para los distintos equipos implicados.
El resultado fue la creación de un sistema modular compuesto por 5 librerías de Figma (fundamentos, componentes, recursos, iconos y plantillas) junto con su documentación asociada. Gracias a esta estructura se consiguió reducir 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 de forma progresiva a lo largo del tiempo y estaba siendo desarrollado por equipos multidisciplinares pertenecientes a diferentes empresas proveedoras.
Esta situación generaba varios problemas:
- Cada equipo diseñaba y desarrollaba componentes de forma independiente
- Existían inconsistencias visuales entre productos
- Se duplicaban componentes y soluciones de diseño
- Era difícil mantener y escalar el sistema
- Los desarrolladores encontraban dificultades para traducir los diseños a código
Además, 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 del proyecto
Resolver problemas de diseño, organización y colaboración
El Design System debía resolver tanto problemas de diseño como de organización y colaboración. Los principales objetivos fueron:
- 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 del Design System
Una arquitectura pensada para escalar
Uno de los aspectos clave del proyecto fue definir cómo estructurar el sistema para que pudiera 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 utilizado por múltiples equipos.
Estructura del Design System
El Design System se organizó en librerías de Figma separadas, cada una con un propósito específico:
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 de diseño que se concentran en un único archivo tienden a volverse difíciles de mantener y a ralentizar las herramientas de diseño. Dividir el sistema en librerías independientes permite mejorar el rendimiento de Figma, mantener archivos más ligeros y facilitar 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 los tokens del sistema. Esto permite adaptar estilos visuales sin rediseñar componentes, reutilizar la lógica del sistema en distintos productos y mantener consistencia sin perder flexibilidad.
3. Gobernanza y mantenimiento del sistema
Los cambios en los tokens se propagaban automáticamente a los componentes. 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.
Sistema de 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ó de forma jerárquica para facilitar su comprensión y reutilización:
Esto permitió mantener consistencia en todo el sistema, claridad para los equipos de diseño y desarrollo, y 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. Era habitual encontrar capas sin nombres descriptivos, jerarquías inconsistentes y componentes difíciles de interpretar.
Para solucionar este problema se definieron reglas de nomenclatura y organización que incluían:
- Convenciones para nombrar capas
- Estructura de agrupación de elementos
- Nomenclatura de variantes
- Organización de componentes y subcomponentes
Gracias a estas normas se consiguió que cualquier diseñador o desarrollador pudiera entender rápidamente la estructura de los componentes.
Convenciones de nomenclatura de componentes
Los nombres siguen una estructura clara y consistente, utilizando capitalización en cada palabra para facilitar su lectura. Por ejemplo:
- 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. Esto 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. Se utilizaron convenciones visuales y nomenclaturas consistentes tanto en capas como en propiedades configurables, lo que permitió que el sistema fuera más fácil de utilizar por otros diseñadores.
Impacto del proyecto
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
Aprendizajes
Un Design System es infraestructura de 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.
Cuando estas piezas se alinean, el sistema se convierte en un acelerador real para el producto y los equipos.