construyendo el sistema de diseño

Bankinter 

Cómo creamos el sistema de diseño de movilidad en bankinter

? Comenzando el viaje

En 2019 los equipos de movilidad de Bankinter decidieron unificar sus tres aplicaciones core (Particulares, Empresas y Broker) con varios objetivos claros:

• Unificar y armonizar plataformas generando consistencia tanto funcional como visual.

• Estandarizar procesos y agilizar el «Way of Working» entre diseño y desarrollo.

• Facilitar el escalado y evolución de los productos pensando a largo plazo.

• Ahorrar tiempos y costes.

• Mejorar la accesibilidad y el engagement de cliente.

¿Cómo logramos estos objetivos?

☂️ Trabajando bajo un mismo paraguas

Tras una Kick Off enfocada en cómo lograr estos objetivos, el equipo de movilidad propuso una solución: trabajar bajo un mismo paraguas utilizando un sistema unificado donde diseño y desarrollo pudieran trabajar de manera colaborativa.

Así, se decidió crear un sistema de diseño propio aplicando los principios del diseño atómico al que llamamos BK DSL (Bankinter Design System Language).

Con el diseño atómico, los desarrolladores y diseñadores teníamos un punto de vista común: reducir el diseño a pequeños componentes, o átomos , que podrían componerse para formar otros más grandes, o moléculas, y finalmente combinarlos todos para formar estructuras u organismos.

Así podríamos construir nuevas pantallas con componentes ya desarrollados y la interfaz de usuario podría construirse de forma modular (como piezas de Lego) siguiendo una misma filosofía: coordinación, consistencia y velocidad.

¿por dónde empezamos?

? Auditoría de componentes

Partiendo de la nueva guía de estilo del banco, comenzamos a hacer un inventario de todos los tipos de estilos, colores, tipografías y demás elementos utilizados en las 3 aplicaciones con el objetivo de ver inconsistencias, unificarlos y reducirlos al menor número posible.

En este punto, descubrimos que teníamos muchos más elementos de los necesarios y que trabajar con menos sería mucho más sostenible y haría más feliz al equipo de desarrollo.

Por lo tanto, antes de crear ningún componente nuevo, lo más importante fue simplificar lo que ya había e identificar lo realmente necesario.

El siguiente paso fue definir la nomenclatura de los componentes de manera que fuera clara y universal. Tras varias reuniones se definió una nomenclatura universal entendible para todos los integrantes de los diferentes squads (PO, TL, UI/UX y Devs).

creando la librería de componentes

? Proceso

Partiendo de estas premisas se dio luz verde y comenzamos a construir nuestra librería de componentes bajo la metodología agile en la que cada sprint agregábamos nuevos componentes o iterábamos sobre los ya existentes.

Una vez los validábamos dentro del equipo del Sistema de Diseño, la librería se versionaba y se compartía con diseño y desarrollo a través de InVision con el objetivo de no interrumpir su proceso de trabajo y evitando a su vez, que los componentes se rompieran al actualizar la librería y a la vez creara inconsistencias en los diseños.

Como el desarrollo del componente se llevaba a cabo en el código fuente de cada uno de los proyectos, para evitar tener múltiples versiones de cada uno de los componentes, una vez completado el desarrollo del componente, se enviaba el código fuente a la librería a modo de repositorio de código quedando disponible para que todos los desarrolladores los utilizaran y colaboraran de manera transversal.

Un paso más

? Dark Mode

Meses después cuando la librería estaba bastante madura, surgió un nuevo reto, crear el Dark Theme.

Esto supuso hacer innumerables pruebas de definición en las paletas de color y pruebas de accesibilidad lo que nos obligó a cambiar los colores de nuestro sistema varias veces.

Estos cambios habrían sido extremadamente difíciles de implementar sin la librería de componentes y el sistema de diseño. Pero con el sistema de diseño, el cambio fue localizado y mucho menos difícil. Los miembros de los diferentes squads pudieron comprobar el resultado visual en dispositivos reales, corregir errores y realizar mejoras de manera rápida y eficiente así como los PO’s y TL’s pudieron comprobar el cumplimiento de los requisitos de negocio y tecnología.

Conclusión

? Errores y aprendizajes

Como comenté al principio, uno de los objetivos de utilizar el sistema de diseño y la librería de componentes era mejorar la forma en la que trabajamos en Bankinter, pero este no fue el único éxito.

Crear un sistema de diseño desde cero nos dio la oportunidad de cometer errores en las etapas iniciales y aprender de ellos entendiéndolo como un sistema vivo en continua transformación en el que iban apareciendo nuevas necesidades a la medida que las Apps crecían y se iban añadiendo nuevas funcionalidades.

Descubrimos que el esfuerzo se amortiza exponencialmente. No solo porque hay menos código que escribir, sino también porque otras tareas se benefician de la reutilización. Se pueden realizar revisiones de diseño exhaustivas por componente, mientras que antes no valía la pena cuando lo que realmente importaba era enviar una nueva función.