Aumentando la eficiencia del desarrollo de producto en 59% con un sistema de diseño escalable.
Design system
UI Design
UX Design
Junior UX/UI Designer
Junior UX/UI Designer
Senior UX/UI Designer
Figma
Atomic design
Stark
Figma tokens
Cuando asumí la responsabilidad de nuestro Design System en Figma, descubrí que, a pesar de su potencial, estaba fragmentado y subutilizado. Los componentes vivían apiñados en una sola página, sin una estructura clara ni una guía semántica que indicara cuándo o cómo usarlos. Los desarrolladores lo veían más como un moodboard visual que como una fuente de verdad de la que pudiera extraerse código limpio; el botón primario, por ejemplo, solo alcanzaba un 60 % de adopción en los nuevos proyectos. Peor aún, casi todas las pantallas incumplían el contraste WCAG AA, poniendo en riesgo la accesibilidad de nuestra plataforma y retrasando los ciclos de desarrollo cada vez que alguien reinventaba la rueda.
Durante tres intensos meses (enero a marzo de 2025), lideré esta transformación como Owner del Design System, acompañado por tres diseñadores UX/UI y tres desarrolladores clave, quienes se convirtieron no solo en implementadores, sino en aliados de esta evolución.
Al adentrarnos en el archivo de Figma, nos dimos cuenta de que cada componente contaba una historia distinta. No había un lenguaje común: unos estilos usaban grises opacos, otros mostraban verdes demasiado brillantes para una alerta, y las tipografías bailaban entre tamaños sin una escala definida. Decidí entonces que nuestra paleta de color y nuestra tipografía debían hablar el mismo idioma: uno claro, predecible y accesible.
Primero, trazamos en FigJam un mapa de tokens primitivos: “GREY/20” era el gris más tenue, “GREEN/60” nuestro tono de éxito. Luego, asignamos un rol a cada uno mediante tokens semánticos —por ejemplo, background-button-primary o text-secondary— de modo que, al tocar código, cualquier desarrollador supiera al instante el propósito de cada variable.
También diseñamos una nueva escala de color que asegurara un contraste mínimo AA según el estándar WCAG, aplicando variables semánticas en cada nivel de luminosidad para cubrir todos los casos de uso.
Paralelamente, establecimos una escala tipográfica basada en una progresión matemática (ratio 1.309 sobre 16 px), definiendo desde heading-xl hasta body-sm, con line-height y kerning cuidadosos que devolvieron la armonía a cada pantalla.
Primero, analizamos la accesibilidad del botón existente, midiendo su ratio de contraste en todos los estados y detectando que no cumplía con el mínimo AA de WCAG.
A partir de este diagnóstico, implementamos la nueva definición de primary-button-background como fondo principal, asegurando que este color cumpliera con los estándares de contraste mínimo AA en cada aplicación.
A continuación, aplicamos las nuevas definiciones de tokens—tanto de fill como de stroke—a los distintos tipos de botón: primario, secundario y terciario. Para cada tipo, detallamos parámetros específicos en los cuatro estados del componente: default, hover, focus y disabled, garantizando así una experiencia coherente, accesible y fácilmente implementable en el entorno de desarrollo.
Este caso de refactorización del botón es solo un ejemplo de nuestro trabajo: en total, abordamos aproximadamente 20 componentes adicionales, incluyendo tarjetas de información, formularios de entrada, menús desplegables y switches, aplicando en cada uno la misma metodología de análisis de accesibilidad, definición de tokens de fill y stroke, y estandarización de estados default, hover, focus y disabled para asegurar coherencia, accesibilidad y facilidad de implementación en todo el sistema.
En lugar de soltar un paquete de cambios y desaparecer, organicé encuentros uno a uno con cada desarrollador. Compartí con ellos el “porqué” detrás de cada token, démonos tiempo para explorar juntos el Dev Mode, responder dudas y escuchar sus sugerencias. De ese diálogo surgieron pequeñas mejoras: un ajuste en la opacidad de un gris para un borde, una variable adicional para un estado de alerta. Cada contribución se integró, centrando al equipo en una misión compartida.
Para formalizar el ritmo de crecimiento, nombramos un responsable único —miembro del equipo de diseño— que revisaría y priorizaría las solicitudes de nuevos componentes o modificaciones, evaluando el impacto según cuántas pantallas los usan y la complejidad de implementarlos. De este modo, el sistema dejó de ser un ente vivo y caótico para convertirse en un organismo gobernado con criterios claros.
Un mes después de desplegar el nuevo Design System, la lead developer me comentó: “Los tiempos de implementación de un nuevo módulo han caído un 20 %. Ya no tenemos que adivinar qué color corresponde a un estado de error ni rehacer botones a mano”. Con datos en mano, calculamos un ahorro de 190 horas por año —un incremento de 59 % en eficiencia— y un impacto económico equivalente a $56 000 USD.Pero el valor real estuvo en el clima de equipo: ver a diseñadores y desarrolladores hablando el mismo lenguaje, resolviendo dudas en Slack con referencias de tokens, y celebrando cada nuevo componente adoptado. Aprendí que un buen Design System no se impone: se co-crea, se nutre de aportes y, sobre todo, se defiende con narrativa.
Optimize the user experience to improve the conversation rate of a SaaS acquisition platform.
Democratizando el bienestar físico y mental con una plataforma digital que refuerza la confianza de la marca y reduce el tiempo de conversión en un 33 %.
Rediseñando la experiencia de usuario de un flujo de registro de eventos, logramos un 18,35 % de conversión y un 25,97 % de nuevas cuentas.
Solución digital basada en insights Job to be Done, construida sobre un proceso UX sólido y proactivo para cubrir dinámicamente las necesidades de los usuarios.
