Bnext, design ops y herramientas de diseño

¡A colaborar se ha dicho!

Bnext es el primer neobanco español. Desde 2017, la fintech española se ha consolidado en España como una verdadera opción alternativa a la banca más convencional. De esta manera, la empresa fundada por Guillermo Vicandi y Juan Antonio Rullán, ha evolucionado su producto para ser mucho más que una tarjeta de prepago sin comisiones o una cuenta. Recientemente ha conseguido la licencia del Banco de España, para operar como Entidad de Dinero Electrónico, y un acuerdo con Mastercard como proveedor principal.

Es hora de que la gente tome el control de su dinero

La premisa principal de Bnext es clara: ayudar a la gente a tomar el control de su dinero haciendo las finanzas más fáciles que nunca. El objetivo es que el usuario sienta que pasa de una de posición de debilidad e incertidumbre a una posición de control, facilidad y confianza financiera.

“En tres años no hemos parado de crecer a un ritmo increíblemente alto. Eso ha hecho que la marca con la que hemos vivido hasta ahora ya no encajara del todo, aunque la vamos a echar de menos. La nueva marca nos ayuda mucho mejor a proyectar, no solo lo que somos ahora, sino lo que queremos ser en los próximos años”

Guillermo Vicandi, CEO de Bnext

La madurez y el crecimiento de la compañía, con su reciente expansión a México, ha despertado necesidades de organización en el desarrollo del producto Bnext.

La incorporación de nuevos miembros al equipo plantea la necesidad de organizar el proceso de trabajo del equipo de Diseño. Definir el protocolo de trabajo y la comunicación junto con el resto de departamentos. La introducción de la nueva herramienta Figma, junto con el planteamiento en base a un Sistema de Diseño, permitirá que el producto escale correctamente a medida que aumenta su complejidad.

Este escenario ha propiciado la colaboración con nosotros. Desde mendesaltaren asumimos el reto de ayudarles a adaptar equipo, proceso y herramientas de diseño a los nuevos desafíos que se les presentan.

Sobre el día a día de un equipo de producto

En un equipo de producto como el de BNEXT, con un equipo engrasado y acostumbrado a trabajar con un alto nivel de exigencia y presión, los retos ya no solo consisten en generar una gran experiencia de usuario. Mantener el listón de su diseño de interacción y experiencia de usuario, ofreciendo una gran performance, y, siendo capaces de iterar, asimilar necesidades detectadas en los clientes y responder a las demandas y oportunidades de los mercados, es un juego muy distinto que se escapa al control de uno o dos individuos sobresalientes. Es en este escenario donde se plantean los mayores retos para escalar y mantener un equipo de diseño de alto nivel.

Bnext es un producto ya posicionado en el mercado y que busca ampliar su negocio abriendo sus servicios a México. En ese contexto, y aprovechando la coyuntura favorable que brinda su nuevo branding, era el momento de parar y preparar las herramientas para un equipo en crecimiento.

Presentación de análisis e inmersión en el proyecto.

En esta situación, arrancó una colaboración de dos meses, donde pusimos nuestro granito de arena en un producto prometedor con un gran presente y un futuro que se anticipa brillante.

Planteamos, como arranque del proyecto, unas semanas de inmersión donde, tras conocer a miembros clave del equipo, tuvimos la oportunidad de escucharles y recoger necesidades, frustraciones, ideas y oportunidades.

Este proceso, tan necesario y tan útil cuando el output de tu diseño va a ser una documentación y una metodología cuyos usuarios puedes tangibilizar y conocer cara a cara, nos arrojó luz sobre la problemática a resolver:

• Existía un desequilibrio entre Bnext, un producto maduro, asentado en el mercado, con las herramientas y el proceso que se seguía en el equipo de diseño. Esta situación se debía a la decisión estratégica de avanzar rápido en captación y expansión. Era el momento de romper cosas y generar el problema, antes que tratar de cubrirlo.
• Existía también una gran granularidad en las herramientas. Se propuso el paso de Sketch a Figma para evitar usar el versionado en Abstract, y cambiar a un proceso más sofisticado, donde todas las necesidades de diseño y control de versiones se centralizan sobre un mismo software.
• Se identificó el grado de madurez, tanto a nivel de sistema como de organización, para trabajar en que todo estuviese a la par.
• Se incorporaban nuevos miembros: el crecimiento del producto, fruto del éxito y de la internacionalización, venía acompañado de varias incorporaciones al equipo de diseño. Era necesario un proceso en el que todos pudieran trabajar de forma armónica, con roles claros y bajo un mismo estándar de calidad. Un argumento más para pasar a una herramienta dónde la colaboración está en el centro.
• La demanda al departamento de diseño era muy alta: Diseño debía responder a negocio, producto, desarrollo y data, lo que debilitaba su capacidad de producir con un standard de calidad alto. Centralizaban además sobre sus archivos de diseño gran parte de los procesos de producto.
• Al incorporarse un System Manager para mantener el sistema, era necesario definir bien su rol y cuál era su participación en todos los puntos del proceso de trabajo. Rol de creación y mantenimiento de componentes del sistema, así como de mediación entre diseño y desarrollo, para obedecer a las necesidades de ambos.
• El sistema de diseño debía tener una estructura escalable y que obedeciera a las necesidades del departamento de desarrollo.
• Existía también la necesidad de monitorizar mejor el estado de cada tarea y tener un mejor trazado de las mismas. Hasta el momento, se trabajaba sobre los mismos archivos y costaba entender o diferenciar qué era un diseño a desarrollar o qué estaba en producción.
• Era necesaria una nueva estructura de organización de archivos, la que tenían no era escalable. El alto crecimiento provocaba indecisión a la hora de trabajar.
• La internacionalización hacía difícil la documentación. Se duplicaban pantallas, lo que provocaba que cualquier cambio que se produjese en un flujo de un país se repitiese en otro. Al no estar sistematizado podía provocar actualizaciones dispares y, por tanto, inconsistencias.
• Existía la necesidad de que el equipo de diseño gráfico pudiese acceder a los recursos, y que utilizase Figma para trabajar de manera más ágil.
• La nomenclatura era un área a mejorar que demandaban todos los equipos, aunque principalmente Data. Se nombraba y numeraba tanto pantallas de un flujo como estados o variantes indistintamente. Esto generaba problemas, por la falta de distinción y porque un simple cambio o una nueva pantalla rompía el orden.

Una vez realizado y delimitado este análisis, que representó gran parte del proceso de consultoría, empezamos a diseñar el esbozo de la solución propuesta para el equipo de Bnext. En comunicación constante con Nil Castellvi, Head of Design, y Pablo Peribañez, System Manager JR del equipo, aterrizamos una propuesta que englobaba 2 áreas.

Proceso de trabajo bien definido

Se estableció un proceso de trabajo basado en tareas para:

1. Una mayor eficiencia.
2. Un mejor seguimiento del estado de la tarea por todos los miembros del equipo.
3. Un registro más preciso.
4. Una mejor diferenciación entre lo que está en desarrollo y producción, con la incorporación de archivos Máster.

Proceso de trabajo y sistema de nomenclatura y portadas en Figma

Un equipo que se enfrenta al reto de la escalabilidad debe necesariamente realizar concesiones individuales en beneficio del colectivo. Ya no va a servir la actitud de trabajador individual brillante que saca todo adelante. Necesitas compartimentar en cierta medida las áreas de responsabilidad. Una concesión dura pero necesaria que repercutirá positivamente en el producto. Es sencillo encontrar analogías de este tipo en otras áreas. Cuanto más se sofistica un proceso, cuanto más se complejiza para dar servicio a un volumen mayor, más actores participan del mismo y un tejido más complejo y profundo se genera. En ese sentido, es necesario que cada parte de la cadena entendiese cuál era su aporte de valor y fuese capaz de remar en la dirección del equipo sin perder de vista algo de espacio para la innovación y para la firma personal.

Sistema de diseño y componentización

Parte de la solución a las necesidades del equipo de Bnext pasaba por la creación de un Sistema de Diseño.

Un sistema sirve como ese lenguaje común y estandarizado entre diseñadores, desarrolladores y responsables de producto, respaldado y acordado por todos ellos, que les ayuda a trabajar juntos y de forma fácil y ágil, reduciendo la fricción en la toma de decisiones.

A nivel de equipo, el utilizar un Sistema de Diseño fomenta el conocimiento compartido de todos los integrantes del equipo, a los que empuja a trabajar juntos, y ayuda también a incorporar a nuevos miembros, los cuales necesitan mucho menos tiempo para familiarizarse con el producto, al darles acceso a una documentación completa y que se consume fácilmente desde el principio.

En definitiva, el contar con un sistema ayuda a poder centrar la atención en nuevos retos y en la solución de problemas, sin perder tiempo en diseñar de nuevo algo que ya ha sido utilizado previamente, y a mantener la consistencia en el producto. Algo que, con la nueva internacionalización y el fuerte crecimiento, era necesario en Bnext.

Nuestro modelo define los elementos que componen ese sistema y la relación que existe entre ellos bajo unos estándares claros, que permitan cualquier combinación para adaptarse a las necesidades del usario. En el caso de Bnext trabajamos principalmente en dos capas: Foundations y Componentes.

Foundations:
Son los aspectos que definen el visual del sistema y nos ayudan a lograr la armonía y coherencia en la interfaz de usuario. En este proyecto en particular abordamos uso de color, tipografía, iconografía, espaciado y layout, pero podría incluir otros aspectos como tono o fotografía.

Las Foundations se materializan en Tokens o Design Tokens. Utilizamos Tokens para una mayor consistencia y para, sobre todo, trabajar de manera agnóstica. En el caso del color, por ejemplo, se logra abstrayendo al mismo de su valor real (código hexadecimal) y dándole uno en función de su uso o rol. La nomenclatura de los tokens es, por tanto, agnóstica a sus valores, permitiendo así que estos puedan cambiar fácilmente, o incluso ser dinámicos y permitir cambios entre distintos temas (como podría ser la aplicación de un Dark Mode), un uso potencial dentro de Bnext.

Tokens del sistema

Componentes:
Son los elementos clave del sistema de diseño. Diseñamos y codificamos componentes para ser reusables y dar solución a las necesidades básicas de la UI de nuestro producto. Estos componentes, junto con el uso de reglas y tokens permitirán evolucionar Bnext de manera consistente y a que el avance sea mucho más rápido.

Templates:
En Bnext también llegamos incluso a trabajar un nivel por encima, templates. Los templates son pantallas construidas mayoritariamente por componentes o fragmentos propios, que ayudan a minimizar o eliminar de manera total el impacto de los cambios, ya que se repiten con mucha frecuencia.

En definitiva, se trabajó en un sistema de diseño para:

1. Mejorar la consistencia y la escalabilidad.
2. Ganar velocidad y agilidad, simplificando el proceso.
3. Economizar recursos y simplificar la toma de decisiones.
4. Lograr una fácil evolución.
5. Mejorar los lazos entre diseño y desarrollo, una única fuente de la verdad.

¿Cuál ha sido el resultado?

Todavía es pronto para evaluar de forma inalterable el resultado del proyecto, y, sin duda, el equipo BNEXT deberá seguir adaptando las formas y usos que se les han propuesto a la medida de su equipo, para que se alcance el poso necesario para tener la perspectiva completa. No obstante, y tras dos meses del cierre del proyecto, sabemos que se están cubriendo estas necesidades:

1. Diseño — Unas reglas estandarizadas y una mejora en la escalabilidad y el mantenimiento. Se ha minimizado el impacto de la alta y constante demanda por parte de negocio. Se puede entrar a un archivo y entenderlo fácilmente, y las reglas documentan bien estados, dispositivos y comportamientos para que desarrollo pueda actuar de forma ágil e independiente sin necesitar soporte continuo de diseño.
2. Producto — Se ha logrado una estructura consistente y ágil, que permite tener todo actualizado en tiempo real.
3. Mobile — Se ha mejorado en consistencia y estandarización, también en orden. Hay una mayor disciplina con la forma de documentar.
4. Data — Puede saber instantáneamente el estado de una pantalla y si está actualizada. Es más intuitivo el encontrar una pantalla y que se pueda entender bien cuándo ha habido cambios en un flujo.

No queremos terminar sin dar las gracias a Bnext por su confianza. No hay duda de que tienen todas las herramientas para seguir creciendo como hasta ahora, y un grandísimo equipo. También a Alberto Roldán (Eventbrite), Carlos Tallón (Cabify) e Ismael Viejo (Coverwallet), por compartir con nosotros su conocimiento.