Cómo migramos los Design Systems de Aplazame a Figma
Hace unos meses, Andrea os contó en este post que en Aplazame estábamos trabajando 100% en Figma y que desde diseño de producto estábamos felices con el cambio.
Lo cierto es que tanto product managers como desarrollo se han adaptado súper rápido y los equipos están muy contentos con la nueva herramienta, que facilita los flujos de trabajo y la comunicación entre todas las personas.
Pero como no es oro todo lo que reluce, y aunque estamos más alegres que unas castañuelas con las posibilidades que Figma nos ha dado, queremos contar algunos retos que supuso migrar los design systems para nosotras, cómo organizamos esta migración y cómo comenzamos a trabajar con ellos de manera eficiente.
Así que en este post me gustaría resumiros nuestra experiencia gestionado el traslado de Sketch a Figma, por si puede ayudar a prever algunos problemas y hacer una migración sin fisuras. Ni dramas. 😊
¿Cuándo migrar TODO un design system?
El precio del cambio
Una migración a una nueva herramienta no es una decisión que tomar a la ligera, ya que no solo afecta a el equipo de diseño si no a todos los flujos de trabajo de producto.
Para un equipo de diseño ocupado, con una carga de trabajo alta, hacer una migración supone esfuerzo y tiempo y, por tanto, también un coste económico.
Honestamente, no era la primera vez que hablábamos de migrar la herramienta porque teníamos problemas, pero nunca parecía ser un buen momento… pero llegó un momento en que los problemas comenzaron a ser más caros que el precio del cambio.
Proyectando la migración
A diferencia de anteriores propuestas/intentos/interés de cambiar de herramienta, esta vez hicimos varias cosas diferentes:
- Dedicamos tiempo a estudiar la herramienta para poder hacer una estimación: vídeos, cursos y tutoriales, jugamos con la herramienta y por supuesto -un básico-, preguntamos a profesionales que ya habían pasado por esto 🤓
- Calculamos el impacto que tendría la migración en el día a día y nos organizamos para no dejar de sacar trabajo del backlog de producto
- Ponderamos los beneficios que obtendríamos con el cambio respecto a cómo trabajábamos en ese momento
- Involucramos a los squads y les enseñamos cómo la herramienta iba a beneficiar el flujo de trabajo. Aunque la decisión final fuera nuestra, creemos que es muy importante involucrar a todas las partes, tener en cuenta su visión y enseñarles lo guay que iba a ser trabajar en una herramienta tan colaborativa y abierta
- Valoramos que el verano era un buen momento para asumir este trabajo “extra”: personal de vacaciones, menos volumen de peticiones, y por tanto, más tiempo para dedicar a aprender a usar el sistema
- Mientras llegaba el verano y e investigábamos cómo funcionaba la herramienta, también hicimos un plan de organización de archivos, un plan de migración de productos y revisamos los planes de pago de Figma para presentarlo al departamento financiero
¿Cómo migramos los design systems de Aplazame?
Primeros objetivos
Por si no lo habíamos dicho anteriormente, en Aplazame trabajamos con dos design systems que, aunque comparten muchas cosas en común, responden a la necesidad de alimentar los productos web (checkout y paneles) y app.
Nuestro primer objetivo fue tener uno de los sistemas de diseño operativo y disponible con el que poder comenzar a trabajar cuanto antes de manera integral, ya que esto nos permitiría trabajar simultáneamente en la migración de los diferentes archivos de producto.
Por eso comenzamos a trastear con la herramienta de manera más autónoma y autodidacta, empezando por migrar los DSs, lo cual nos ayudaba a entender cómo funcionaba la herramienta y sus posibilidades, y no requería muchísimo tiempo (hacer un componente que funcionase bien entre historia de usuario e historia de usuario, y ya otro día variantes…).
Otro de los objetivos fue retrasar la compra de licencias hasta tener la seguridad y la confianza de que íbamos a ser totalmente eficientes y podríamos trabajar solo con Figma. Así que una vez generadas las librerías de diseño fue cuando adquirimos licencias y comenzamos a enlazarlas a los archivos que íbamos creando por productos y cuya estructura previamente habíamos definido en el plan de migración.
En resumen, en esta fase aprovechamos para adelantar trabajo invirtiendo el tiempo “improductivo” -entre dos reuniones, dos HUs…- en sacar los design systems.
Poder dedicar tiempo a aprender de manera más independiente y libre, nos sirvió para tres cosas:
- Retrasar la compra hasta que sentir seguridad con la herramienta
- Familiarizarnos con Figma (2 de las 3 no la habíamos usado jamás. Y ninguna la había usado para crear sistemas de diseño)
- Generar un roadmap y planificar la migración de los productos y saber cuándo podríamos estar trabajando 100% con Figma, ser eficientes, diligentes, y deshacernos del resto de herramientas que estábamos usando (Sketch, Abstract, Invision…)
¿Cuánto tiempo se tarda en migrar un design system?
En toda esa fase, investigamos cuánto tiempo habían tardado otros equipos en crear un DS consistente con Figma, y las estimaciones medias eran bastante superiores a nuestro deadline.
Después de haber creado varios design systems, el tiempo estimado para tener un sistema de componentes y patrones de uso funcionales, bien diseñados, y bien documentados a nivel librería debería ser entre 3y 6 semanas. Lo que vendría a ser una buena definición de tokens y componentes básicos que podemos encontrar en todos los productos, incluyendo algún componente específico para un producto.
En el caso de una migración, todo el diseño, estados e interacciones, así como toda la documentación de patrones, funcionamientos, convivencias, etcétera, debe estar ya generada, así que el tiempo para pasar de una herramienta a otra debe acortarse sustancialmente (según nuestra experiencia, deberíamos tardar aproximadamente 2 semanas por sistema de diseño como mucho).
Crear un design system no es lo mismo que migrar un design system.
Pero realizar los mismos componentes, con las mismas características, en una herramienta totalmente nueva fue difícil, porque -lógicamente- no funcionan de igual forma.
Cuenta siempre con la curva de aprendizaje
La curva de aprendizaje de Figma es sencilla. Utilizar Figma para migrar un DS complejo, sin tener ni idea previa del programa no. Fundamentalmente por el mindset heredado de Sketch y por la definición ya existente de los componentes.
Crar un design system nuevo será más fácil con una nueva herramienta, porque como diseñadores tenemos la capacidad de adaptarnos a la herramienta y buscar la manera de utilizarla según nuestras necesidades. Cuando tienes que migrar un sistema de diseño ya hecho -y en pleno desarrollo-, es la herramienta la que debe adaptarse al diseño, ya que no podemos optar a modificar componentes.
Reconstruir el DS
Es cierto que Figma es capaz de abrir archivos de Sketch e importar elementos… pero solo importará las capas, no importa ni aplica estilos automáticamente, ni mantiene símbolos.
Tras ver la función de la importación y evaluar el tiempo que íbamos a invertir “arreglando cosas” en lugar de creándolas decidimos generar cada componente de manera individual basándonos los componentes que teníamos.
No vimos esto como algo malo, porque reconstruir el DS nos daba la oportunidad de aprender a usar la herramienta.
Este flujo de trabajo fue mucho más rápido, porque la organización de Figma simplifica mucho los componentes. Creándolos de nuevo evitamos el trabajo de modificar elemento por elemento, eliminar lo que no era necesario del archivo anterior, y agruparlos de nuevo y mencionar variantes a posteriori.
Retos de la reconstrucción
Los estados y la accesibilidad
En Aplazame miramos mucho por la accesibilidad, y para crear el estado focus de nuestra botonera (con borde de 1px a 2px del borde contenedor), tuvimos que hacer muuuchas pruebas y rebuscar por tutoriales hasta conseguir saber que había que crear un efecto con el borde…
Bueno, uno no, 4. Uno para el primario, uno para el secundario y lo mismo para los botones con el color secundario (negro). En el caso del secundario, que además es un ghost, el hecho de que sean dos líneas complica el componente. Carlota y yo sufrimos muchísimo aquí.
En Sketch esto era tan fácil como crear 2 bordes de color (uno blanco y otro azul) en el color del estado focus, mientras que en Figma hay que aplicar a la variante focus del botón un estilo de capa compuesto de 2 drop shadow con estilos diferentes. Tardamos días en descubrirlo.
Otra opción -la fácil- hubiera sido redefinir cómo mostrar los estados de los componentes, pero como ya hemos dicho, nosotras no nos estábamos enfrentando a un rediseño sino a una migración. El equipo de desarrollo comenzó esta migración hace apenas un año y, aunque el sistema es iterativo, no queríamos cargar de trabajo al equipo de desarrollo (¡porque aún no hemos lanzado a producción el rediseño en todos los productos!). Queríamos optimizar flujos sin efectuar grandes cambios.
Paletas de colores
Figma, como herramienta, exige algunos cambios. Por ejemplo, cambiar el mindset y simplificar las paletas de colores.
En Sketch, los colores se organizan por ramas de uso: (colores de texto, colores de acción primaria y secundaria (con sus respectivos estados), colores para fondos, colores de alerta, colores de subrayado (gráficos), nieblas… y claro, en cada ramita, los colores se repetían pero diseño era incapaz de ver todos esos colores a la vez, y para verlos debía navegar. La facilidad de usar los colores así organizados es que siempre podías sustituir por otro del mismo contenedor.
Figma te muestra todos los colores a la vez, y los diferencia mediante una etiqueta superior, por lo cual, al migrar la paleta tal cual la teníamos (y pensábamos con Sketch), teníamos muchísimas veces repetidos los colores y todos a la vista.
En Sketch nuestro color azul de marca aparece como color de texto, de fondo, de acción (en la acción primaria en varios estados (enabled y focused), en la secundaria (active), en los chips (active), y también en una V1 aparecía como color de alerta informativo.
Tener ese esquema complejo facilita el lenguaje común con desarrollo y mejorar la semántica del sistema. Con este tipo de organización es más simple hacer un refresh de la marca o iterarla en el futuro (¿que queremos botones holográficos?, pues cambiamos solamente colores y efectos de la paleta de acción primaria, sin modificar el resto de colores). Simplemente sustituyes un color por otro sin tener en cuenta el color “en sí mismo”, sino el uso que se hace de ese color (de acción, en el caso de un botón).
Si necesitas un dark mode, o lo estás proyectando, o necesitas que funcione con diferentes configuraciones de color, esta manera de trabajar el color es la manera más fácil de implementarlo.
Figma está pensado para trabajar con gradaciones de color. La organización que teníamos en Sketch, en Figma se traduciría a repetir un mismo color a lo largo de la lista de colores. Y aunque es cierto que Figma permite definir el uso y organizar los colores por secciones… ¿realmente vamos a ir al fondo de la lista para utilizar un “background” teniendo el mismo color nada más abrir la herramienta de color?
En diseño siempre íbamos a correr el riesgo de escoger “el primer color válido” que estábamos buscando que se encontrara al principio de nuestra búsqueda -y mandar al traste la semántica construida entre diseño y desarrollo-.
Me gustaría decir aquí que en cuanto comenzamos a trabajar con Figma nos dimos cuenta de que esto funcionaba así. Pero si así hubiera sido no estarías leyendo esto.
Puedo decir que el mayor error en la migración fue migrar “tal cual” nuestra paleta de colores. “Tal cual” no, porque los colores no funcionaban igual y no podíamos definir los estados -como vimos en los botones- como estilos de acción dentro de la paleta... Pero nos esforzamos realmente en adaptar esa estructura lo máximo posible y en cuanto llegó al equipo de desarrollo saltaron las alarmas.
La conversación con dev hizo que lleváramos a cabo una primera simplificación de la paleta cromática, intentando mantener la nomenclatura semántica que heredábamos del modelo mental de Sketch.
Tras la simplificación se llevó a cabo una refactorización por parte del equipo de desarrollo de la paleta cromática que teníamos en Sketch a la nueva síntesis de Figma.
A pesar del refactor seguimos teniendo problemas de atribución, así que después de varias reuniones, varias semanas y crisis existenciales por ambas partes, lo que terminamos por hacer es una simplificación a, ahora sí, gradaciones de color.
Aprovechamos para simplificar y reducir la paleta eliminando cualquier color que no estuviéramos usando.
Por supuesto, tanto la nueva organización por gradaciones como la eliminación de colores provocó otra refactorización completa de la paleta por parte del equipo de desarrollo y la revisión de la aplicación de color en todos y cada uno de los componentes por ambas partes.
En resumen, todos los cambios supusieron no solo cambios en las estructura básica del DS, sino la reformulación de toda la documentación que ya estaba generada con anterioridad, en la cual cambiaron todos los nombres semánticos por el número dentro de la escala de color correspondiente así como la definición de las especificaciones de las posibles intercambios con el resto de colores y otras escalas.
Otros cambios…
El mindset de Figma nos obligó a revisar la construcción de símbolos/componentes y a simplificarlos a nivel tokenización.
Mientras que en Sketch existe un botón-primario-relleno-L-enabled por cada una de las alineaciones, en Figma tenemos un botón al que asocias variantes (pero no alineación porque eso lo editas en el propio frame). Además de mejorar la organización del DS, hizo que la rama que solía tener una ruta larguííísima como “Agregar símbolo > Componentes > Nombre componente > Tipología > Tamaño > Color > Alineación > Estado” se convirtiera en añadir “el botón” al frame y editar luego las variantes para modificarlo.
También dividimos la biblioteca de entornos web, de manera que simplificamos el sistema creando un sistema base o principal que aplica a todos los proyectos y un protosistema -que se nutre del primero- que solo aplica a productos independientes.
Últimos pasos para integrar el design system
En cuanto tuvimos los DS disponibles y a falta de migrar la documentación (que teníamos en Invision DSM disponible y actualizada mientras no migrábamos esto también a otra plataforma), organizamos varias reuniones con los equipos de desarrollo para mostrarles la herramienta que iban a utilizar a partir de ahora. 💙
En las reuniones abordamos conceptos básicos sobre cómo usar Figma (inspect y comentarios) y cómo iba a ser el flujo de trabajo. Hicimos una demo de cómo íbamos a organizar los archivos y a cuáles iban a recurrir y a tener acceso. Como comentaba al principio del post, que desarrollo y product managers comenzaran a usarlo fue un éxito rotundo desde el principio.
Lógicamente tuvimos que ir refinando flujos y día de hoy seguimos iterando la manera de trabajar. Ahora incluso son ellos los que nos comentan nuevas features que comenzar a usar e implementar en el flujo de trabajo. 😊
Conclusiones:
A pesar de que quisimos mantener “intacto” el sistema de diseño existente, el uso de una nueva herramienta trae consigo cambios necesarios que en nuestro caso afectaron no solo a diseño, sino a desarrollo, lo que implico también por su parte una dedicación extra a la migración.
No contamos con esto debido a nuestras “buenas intenciones” de mantener todo igual y pensamos que el esfuerzo de la migración de herramienta caería en nuestro tejado. Desarrollo, efectivamente, tuvo que invertir tiempo en refactorizar el design system y comprobar que todo siguiera funcionando bien.
Todos los cambios que fuimos acometiendo, tanto nosotras como de la mano del equipo de desarrollo, han hecho que mejorara muchísimo el rendimiento de la herramienta y sea mucho más ágil y rápido trabajar con Figma, y sobre todo ha ayudado a depurar más aún todos los productos y organizarlos.
Hubo un tiempo en el que convivieron las “2” herramientas (Figma y el trío Sketch+Abstract+Invision), pero la transición fue tan rápida que comenzamos a usar exclusivamente Figma en tiempo récord. A día de hoy conservamos los archivos de Sketch -no realizamos ningún mantenimiento ni actualización sobre ellos- como documentación de trabajo y como parte de la historia de Aplazame.
Cada design system pude ser más o menos complejo y ser más o menos fácil migrarlo de otra herramienta a Figma. El nuestro, tanto por características de los componentes iniciales, como los estilos, como la manera de organizarlo, supuso varios cambios, pero esto no tiene que ser así en otros casos. Cada DS, como cada proyecto, tiene necesidades específicas.
Si estás pensando en acometer una migración, investiga, trastea con la herramienta, comprueba las posibilidades y haz un plan. Pero sobre todo, ten paciencia, tómatelo con calma e involucra a todos los equipos.
¡En producto nos sorprende ver cómo la migración ha cambiado no solo la herramienta de trabajo sino nuestra manera de trabajar de manera global en tan solo 6 meses!
Y aunque en su momento lo retrasáramos, si nos preguntan hoy: sí, hubiéramos migrado antes.
¡Esperamos que este post pueda os servir si estáis pensando hacer una migración a Figma!
Si tienes cualquier duda o pregunta -o quieres compartir tus penas o alegrías en un proceso similar- no dudes en escribirnos, estaremos encantadas de poder ayudaros 💙👇🏻
