Evolución y Gobernanza de Sistema de Diseño

Sistemas robustos para equipos ágiles

En organizaciones del tamaño de Skandia o Seguros Bolívar, múltiples células de producto desarrollan funcionalidades en paralelo. Sin una base de diseño unificada, cada equipo crea componentes ad-hoc, lo cual resulta en altos niveles de deuda técnica de front-end y experiencias de usuario fragmentadas y poco coherentes.

Como Product Designer enfocado en Sistemas de Diseño, lideré la evolución de la biblioteca de componentes y tokens en Skandia. Mi labor consistió en auditar la interfaz existente, crear el modelo de tokens semánticos (sincronizando Figma con variables CSS), redactar especificaciones de usabilidad y accesibilidad, y liderar el modelo de contribución técnica con los desarrolladores front-end.

¿Por qué estructurar un sistema?

Antes de consolidar el sistema, identificamos varias brechas operativas en el flujo de diseño y desarrollo:

• Deuda visual extrema: Existían más de 12 variantes de botones con diferentes tonalidades de amarillo, bordes redondeados y fuentes en un mismo portal.
• Desperdicio de tiempo en handoff: Los desarrolladores debían codificar estilos desde cero para cada vista de Figma, en vez de reusar librerías globales.
• Falta de gobernanza: Si se requería un cambio en el color institucional, el equipo debía modificar manualmente decenas de archivos de código y mockups.

Objetivos estratégicos

• Establecer una fuente única de verdad (Single Source of Truth) para tokens visuales (color, tipografía, bordes, espaciado).
• Estructurar componentes interactivos modulares y accesibles (WCAG 2.1) listos para producción.
• Crear un modelo de gobernanza que permita a diseñadores y programadores proponer e iterar componentes del sistema.

La fricción del cambio tecnológico

• Multiplicidad de Stacks: Ciertos portales de la fiduciaria utilizan arquitecturas web tradicionales, mientras que los nuevos usan frameworks SPA. El sistema de diseño debía ser agnóstico a la tecnología, estructurándose mediante Tokens (variables CSS/JSON) reutilizables.
• Resistencia al cambio: Los equipos de desarrollo tenían cronogramas de entrega apretados, por lo que migrar a una nueva librería de diseño debía ocurrir de forma paulatina sin congelar el backlog.

1. Auditoría Interfaz (Audit)

Realizamos una captura de todas las pantallas del ecosistema de Skandia. Agrupamos los elementos por categorías (Navbar, inputs, botones, banners). Demostramos cuantitativamente a la dirección que la falta de consistencia costaba dinero debido a la cantidad de horas que los devs gastaban corrigiendo estilos pixel-by-pixel.

2. Definición del Modelo de Tokens

Mapeamos los colores primitivos a roles semánticos. Por ejemplo, el color primitivo Yellow 500 (#FFCC00) se asignó al token semántico de acción Semantic/Fill/Yellow. Esto asegura que si el día de mañana se cambia el tono corporativo del amarillo, solo se modifica la declaración del token y se actualizan todos los componentes de diseño y código automáticamente.

3. Handoff de Código y Documentación

En conjunto con el equipo de front-end, creamos especificaciones técnicas de animación, comportamientos hover y focus, y estructura HTML semántica para cada componente. Escribimos la documentación del sistema en Figma y Storybook para garantizar que tanto diseñadores como ingenieros contaran con el mismo vocabulario visual.

Un sistema de diseño modular y vivo

La solución no fue un documento PDF estático, sino una librería viva en Figma sincronizada con variables globales de CSS (como el UI Kit de este portafolio), facilitando el desarrollo rápido y coherente.

Impacto y eficiencia operacional

La implementación del sistema de diseño impactó directamente la cultura de desarrollo de la empresa:

• Aceleración de entregas: Reducción en los tiempos de maquetación y diseño de interfaces en nuevos flujos.
• Alineación del equipo: Handoff libre de fricción técnica; el código entregado por los desarrolladores comenzó a coincidir perfectamente con los diseños de Figma.
• Facilidad de mantenimiento: Posibilidad de realizar rediseños visuales a gran escala en un par de días en lugar de meses.

Aprendizajes

• El sistema es un producto, no un proyecto: Un sistema de diseño requiere de mantenimiento y gobernanza constante. Si no se actualiza, la deuda de diseño vuelve a aparecer.
• La comunicación bidireccional es clave: El sistema de diseño no se impone; se co-crea. Las mejores sugerencias de mejora de componentes suelen provenir de los desarrolladores front-end.