Mejorando las operaciones de diseño del primer neobanco español

Expertise

Operaciones de diseño

Estrategia

Entregables

Sistema de diseño

Auditoría

Plataformas

Entorno web

App nativa

Visítalo

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

Bnext es el primer neobanco español pionero como alternativa a la banca tradicional. 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. La premisa principal de Bnext es ayudar a la gente a tomar el control de su dinero haciendo las finanzas más fáciles que nunca.

Un problema en expansión

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 asentar un proceso de trabajo y comunicación junto con el resto de departamentos. Esta necesidad sumada al rebranding de la compañía por parte de erretres, creaban una ocasión única para repensar su sistema de diseño, transicionar hacia un menor número de herramientas colaborativas, incorporando Figma al flujo de trabajo, y establecer una operativa de diseño que resolviera problemáticas más complejas en una situación de tensión de la compañía.

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

Bnext es un producto ya asentado, que ha alcanzado su posición en el mercado y que busca ampliar su negocio abriendo sus servicios a México. 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 cambian: mantener los estándares con un equipo en crecimiento, siendo capaces de iterar, asimilar necesidades detectadas en los clientes y responder a las demandas y oportunidades de los mercados en los que operan.

Mapeando necesidades

Tras unas semanas de inmersión fuimos capaces de entender la problemática, con el objetivo de ofrecer una solución funcional y operativa a la medida de sus necesidades.

Existía un desequilibrio entre un producto maduro, asentado en el mercado y con un gran número de usuarios activos. Las herramientas y el proceso que seguía el equipo en su día a día no permitía cubrir las demandas de negocio. Existía una gran granularidad en las herramientas. Se propuso el paso de Sketch a Figma para evitar usar el versionado en Abstract y pasar a un proceso más ligero. El equipo había crecido, y debíamos prepararnos para un potencial crecimiento aún mayor.

Mejorando las operaciones de diseño

Otro de los puntos que detectamos fue la alta demanda que existía hacia el departamento de diseño: debía responder a negocio, producto, a desarrollo y a data, ralentizando su capacidad productiva. Centralizaban además sobre sus archivos de diseño gran parte de los procesos de producto. Vimos también cómo era necesario de monitorizar mejor el estado de cada tarea y tener un mejor trazado de las mismas en los archivos de diseño y en la estructura de los mismos.

Para agravar algunos de estos problemas, la internacionalización añadía una capa de dificultad en 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.

Sistema en el centro

Además de migrar a Figma, hubo una serie de aspectos importantes a tener en cuenta respecto al sistema.
En primer lugar, debía tener una estructura escalable y que obedeciera a las necesidades del departamento de desarrollo. Debía además, equilibrar bien agilidad y simplicidad, así como dar respuesta a las necesidades de internacionalización antes mencionadas, donde existen diferencias entre países, a veces sutiles y a veces bastante grandes.

La nomenclatura era un área a mejorar que demandaban todos los equipos. 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.

Por último, durante el proceso se incorporó Pablo Peribañez como system manager. Un diseñador con ganas de comerse el mundo y con poca experiencia en el manejo de sistemas. Era necesario definir bien su rol y cuál era su participación en todos los puntos del proceso de trabajo. Nos consta que su trabajo está siendo de gran altura.

Profundizando en la solución

Se estableció un proceso de trabajo basado en tareas para conseguir una mayor eficiencia, un mejor seguimiento del estado de la tarea por todos los miembros del equipo, ayudar a mantener un registro así como evitar ruido y distracciones.

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. En ese sentido, es necesario que cada parte de la cadena entienda cuál es su aporte de valor y sea 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

Muchas de estas necesidades las resolvía el Sistema de Diseño, entendido en su concepto más amplio, no sólo como herramienta de diseño si no como contenedor de las operaciones y proceso que intervienen en su uso y creación. Aunando sus problemáticas, estados, nomenclatura, se generó una documentación compartida que sirvió de base como lenguaje común entre equipos así como un mapeo de pasos a seguir en la madurez del proceso de diseño.

Muchas de estas necesidades las resolvía el Sistema de Diseño, entendido en su concepto más amplio, no sólo como herramienta de diseño si no como contenedor de las operaciones y proceso que intervienen en su uso y creación. Aunando sus problemáticas, estados, nomenclatura, se generó una documentación compartida que sirvió de base como lenguaje común entre equipos así como un mapeo de pasos a seguir en la madurez del proceso de diseño.