Improving the design operations of the first Spanish neobank


Design operations



Design System



Web environment

Native app

Take a look 

It’s time for people to take control of their money

Bnext is the first pioneering Spanish neobank which offers an alternative to traditional banking. The Spanish fintech has established itself as a real, viable option for those looking for something other than a conventional bank. The company, founded by Guillermo Vicandi and Juan Antonio Rullán, has evolved its product to be much more than simply an account or a prepaid card without commission. The main premise of Bnext is to help people take control of their money by making finance easier than it’s ever been.

A growing problem

The maturity and growth of the company, with its recent expansion into Mexico, has brought about new organisational needs in regard to the development of the Bnext product. As new members joined the team, the need to create a standardised work and communication process throughout all departments became apparent. This need, along with the rebranding of the company by Erretres, created a unique opportunity to rethink the brand’s design system, transition to fewer collaborative tools - incorporating Figma into the workflow - and establish a design operation that would resolve more complex problems in moments of tension. 

The day-to-day life of a product team

Bnext is already an established product that has reached a strong position in the market and now seeks to grow its business through its expansion into Mexico. In a product team like that of Bnext, one which is more than accustomed to working in demanding and high-pressure situations, the challenges are different: being able to maintain high standards in a growing team; iterate; understand the needs of customers; respond to the demands and opportunities of the markets in which Bnext operates. 

Mapping needs

After a few weeks of full immersion into Bnext, we were able to understand the problem and offer a functional and operational solution tailored to the needs of the company. 

We noticed an imbalance between what was a developed product, which was already established in the market, and a large number of active users. The tools and processes that the team were using in their day to day did not allow them to meet the demands of the business, because they were using too many, over-specialised tools. It was decided that Bnext would move from Sketch to Figma, to avoid using the versioning in Abstract and to adopt an easier, all-in-one process. The team had grown, and we needed to prepare for even greater growth potential.

Improving design operations

We also noticed the extremely high demand that the department of design was facing: they had to respond to the business, product and development and data, all of which was slowing down their productive capacity. Additionally, they centralised a lot of the product processes in their design archives. We realised it was necessary to monitor the status of each task more closely and have a better layout for those tasks in the design archives and in their structure. 

To exacerbate the problem, the internationalisation added another layer of difficulty when it came to documentation. The screen interfaces were duplicated, which meant that any change that occurred in the workflow of one country was repeated in the other. Incorrect synchronisation led to disparate updates causing inconsistencies.

The system, at the centre

On top of moving over to Figma, there were a number of important aspects that we had to bear in mind in regard to the system. Firstly, the system had to have a scalable structure that adhered to the needs of the development department. It also had to sit somewhere in-between agility and simplicity, so that it could answer the needs of the international expansion aforementioned. There were differences between countries, some of which were subtle and some of which were more significant. 

All of the teams at Bnext wanted the nomenclature to be improved and standardised. Interface flow, phases and variants were named and numbered indistinctly. The lack of distinction was causing problems, as well as the fact that a simple change or a new interface could break the order. 

During the process, Pablo Peribañez was brought on as system manager. Pablo is a designer with huge ambition but little experience of how to manage systems. It was necessary to clearly define his role and participation throughout the work process. We know that he is doing a very fine job. 

Delving into the solution

A task-based work process was established to ensure all team members could work more efficiently, follow-up on the status of tasks more easily, help keep a record of the work and avoid unnecessary noise and distractions.

A team facing the challenge of scalability has to make individual concessions for the benefit of the team as a whole. The attitude of a brilliant, individual worker who wants to get ahead and get it all done himself doesn’t help. Everyone needs to hone in on their area of responsibility to a certain extent. To this effect, it’s essential that every person who forms part of the chain understands what their value contribution is and is able to work together and move forward with the team, without completely denying people the space to innovate and reveal their personal touch.

Design system and componentization

Many of these needs were solved by the Design System, understood in its broadest terms, not only as a design tool but also as home to the operations and processes involved in its use and creation. A shared documentation was made that served as a basis for a common language between teams, uniting the problems, different phases and nomenclature. Additionally, it provided a mapping of the necessary steps to follow as the design process evolved.