El contexto
Llevo más de cuatro años trabajando en Caja Los Andes, una de las cajas de compensación líderes de Chile, con millones de afiliados y una escala que obliga a pensar en grande desde el primer día.
Llegué en noviembre de 2021 como consultor externo. Con el tiempo me internalizaron, en marzo de 2023, y desde entonces he formado parte de múltiples células UX/UI, casi siempre en duplas, con foco siempre en UI. Durante ese período participé en proyectos de alto impacto — entre ellos el rediseño completo de Tapp, la tarjeta prepago de Caja Los Andes, una experiencia de la que podría escribir otro artículo entero.
Fue precisamente en ese proyecto donde descubrí algo importante: me encanta diseñar componentes. No solo hacerlos visualmente bien, sino entender la lógica detrás de construirlos — cómo una buena decisión de diseño puede escalar a través de todos los flujos de un producto digital.
Al cerrar esa etapa del proyecto, y ya como diseñador senior, pasé a formar parte de un equipo COE (Center of Excellence), desde donde brindé asesorías transversales a los demás equipos UX/UI y participé en proyectos experimentales y de demanda ad-hoc. Paralelamente, también asumí la administración de Figma — herramienta central en todos los equipos de experiencia de la organización — gestionando licencias, espacios de trabajo y asegurando que el equipo aprovechara al máximo lo que la plataforma ofrece. Creo que me asignaron ese rol precisamente porque Figma es una herramienta que me gusta mucho, siempre busco estar al tanto de cada novedad que lanzan y eso se refleja en cómo la aprovecho en el trabajo.
El momento
En septiembre de 2024 me ofrecieron reemplazar al líder del Design System. Era un reemplazo temporal — pre y post natal — pero representaba algo mucho más grande para mí.
Mi primera reacción fue nerviosa. El síndrome del impostor llegó puntual, como siempre. Pero lo miré desde otro ángulo: era una oportunidad real de crecer, de ver cómo me iría liderando un equipo.
Al principio me pareció manejable. "Solo tengo que asegurarme de que el roadmap se cumpla y de que el equipo esté bien", pensé. Y en parte era cierto. Pero pronto empecé a asomar la cabeza hacia las capas más profundas del rol: reuniones con células y líderes técnicos, decisiones que iban más allá del diseño puro, conversaciones donde el conocimiento de desarrollo importaba. Tengo nociones base de programación, pero no es mi fuerte — y aprender a moverme en ese espacio fue parte del desafío.
"Ahí aprendí algo valioso: no necesitas saberlo todo. Saber en quién apoyarte es también una forma de liderar."
Metiéndome de lleno
Poco a poco fui adentrándome en las librerías del design system. Quería entender cómo estaban construidas, qué componentes existían, qué oportunidades de mejora había. Y ahí mi experiencia con Figma jugó a mi favor: rápidamente noté que muchos componentes estaban construidos de una manera antigua, sin aprovechar las funcionalidades más recientes de la herramienta.
Sin embargo, no salí a cambiar todo de inmediato. Continué respetando la planificación ya establecida por el líder al cual estaba reemplazando. Resolviendo las dudas de las células y atendiendo las incidencias que levantaban. Había un orden que mantener.
En cuanto a la metodología de trabajo, usábamos Jira para el seguimiento y Atomic Design como enfoque para estructurar y escalar los componentes. Para medir la complejidad de las tareas aplicábamos una escala de Fibonacci: 1, 5, 8 y 13 puntos. A mayor puntaje, mayor complejidad. Esto era importante porque no nos medíamos por cantidad de tareas completadas, sino por el peso real de cada una.
Esquema de SLA
Tiene todo el sentido: un diseñador o desarrollador podía estar días trabajando en un único componente complejo, como un menú de navegación superior, y eso debía tener un valor proporcional a su dificultad.
Los primeros problemas reales
Uno de los primeros obstáculos concretos que encontré fue el seguimiento dentro de Jira. Conozco bien la herramienta, pero había margen importante para mejorar cómo estaba configurada y aprovechada dentro del equipo.
Lo abordé de manera directa: establecí que todas las tareas debían tener contexto claro, fecha de inicio, fecha de vencimiento y fecha de término. Además, cada tarea tenía que estar correctamente enlazada a su épica correspondiente y bien puntuada según la escala acordada. Un cambio simple en apariencia, pero que mejoró el seguimiento considerablemente.
Mientras tanto, algo más grande estaba ocurriendo en paralelo: llegó un nuevo gerente general a la empresa, y con él, una reestructuración importante. Rotaciones de equipo, movilizaciones a otras áreas, reorganizaciones.
En medio de esa reestructuración, asumí el cargo de líder del Design System — ya no como reemplazo, sino como responsable del equipo.
Una nueva etapa, una nueva visión
Asumir el cargo de forma definitiva me dio algo que antes no tenía: Libertad para planificar mis propias iniciativas.
Mi objetivo era claro — fortalecer y evolucionar el sistema de diseño — y para organizarlo definí cuatro pilares que guiarían el trabajo:
- Ordenar: Establecer una base sólida y coherente.
- Optimizar: Sacar el mayor potencial de los componentes y las herramientas disponibles.
- Automatizar: Incorporar IA para agilizar procesos repetitivos.
- Disponibilizar: Asegurar que el sistema sea accesible y útil para todos los equipos.
Estos pilares no eran solo conceptuales. Se tradujeron en iniciativas concretas: mejoras higiénicas que ordenaron lo que estaba disperso, optimizaciones que modernizaron componentes que llevaban tiempo sin actualizarse, y los primeros pasos hacia la automatización de procesos mediante implementaciones con IA.
De esa última línea nació algo que merece su propio artículo: el desarrollo de un plugin para Figma orientado a automatizar la documentación de componentes — una de las tareas más repetitivas y demandantes del proceso de construcción de un design system. Esto, junto a otras soluciones que he desarrollado con IA para eficientar mis flujos de trabajo, tiene mucho más para contar.
Reflexión final
Cuando miro hacia atrás, me cuesta reconocer al diseñador que dudó antes de aceptar este rol. El síndrome del impostor tiene esa trampa: te hace creer que necesitas estar completamente listo para dar el siguiente paso. Pero la realidad es que nadie llega a un rol de liderazgo sabiendo todo. Se aprende liderando.
Lo que sí me ayudó fue tener claridad en lo que quería lograr, honestidad sobre lo que no sabía, y la disposición de apoyarme en el equipo cuando era necesario.
Liderar no es tener todas las respuestas — es saber hacer las preguntas correctas y crear las condiciones para que el equipo pueda dar lo mejor de sí.
Si estás en un momento similar — dudando si dar ese paso, si estás listo, si te lo mereces — mi consejo es simple: hazlo de todas formas. Las oportunidades no siempre esperan a que te sientas preparado.