CHALLENGE
To enable new members to open accounts with the aim of using multiple accounts.
MY ROLES
Main focal point for connecting teams; Responsible for defining information architecture and interface.
TEAMMATE
Gabriel Jose Rodriguez Miranda (Product Designer - digital channels team).
Overview
In the Brazilian financial scenario, it is very common for people to have joint accounts and move money between them or even have a distinction in spending for each type of account. For example, a couple where each has a personal account and a joint account at the same bank. Or parents who take care of their minor child's account and their own individual accounts. Another case is someone who has a personal account as an individual and another account for their company as a legal entity. When the multiple account functionality was introduced to the app, it was necessary to define a flow so that an account holder could carry out financial transactions from all their accounts without having to leave the app (log out).
The premise for this challenge was: to make this flow viable with the least possible impact.
The problem
With several teams each taking care of a part of the application (investments, cards, payments, etc.) and some legal and software engineering definitions, after a few joint sessions we arrived at the following problem:
how to design a component and its interaction that adapts to the architecture and particularities of each area of the application and how to orchestrate this with all responsible teams understanding the needs of each one?
how to design a component and its interaction that adapts to the architecture and particularities of each area of the application and how to orchestrate this with all responsible teams understanding the needs of each one?
The Solution
As this is a design system challenge, the solution and its respective processes must have a specific act, a systemic effect. Right away, we decided that changing accounts should be next to the profile identification in the app, as it is already a market standard and the only place in the app that is visible almost all the time. In other words, we would redesign the app's header (or top bar) to accommodate this functionality.
Mapping impact
So, we started by identifying the areas of the app that would be impacted and what questions we had about each of them. Some questions (among many others) that we had were:
﹒in the balance, which account's balance will be shown?
﹒will all accounts be loaded on the app's home page or just the one the user logged in to?
﹒which will be the default account?
﹒in the balance, which account's balance will be shown?
﹒will all accounts be loaded on the app's home page or just the one the user logged in to?
﹒which will be the default account?
Blurred image of mapping impacted app areas
Mapping architecture
To design a component that is available throughout the application, the most important thing for everyone to understand is to make the architecture of the entire application visible and to outline how that component should be presented at each level. In this first diagram, we illustrate the application architecture levels with their respective names and descriptions, and with a box with the guideline for that component for each level.
Component and specs
This component would have its greatest impact at the product home and sub-home levels, where it was defined that account exchanges would take place. From the third level down, each team could define whether they would like to enable the exchange or not because from a development point of view it would be more complex.
We needed to design a component for 3 different account types:
We needed to design a component for 3 different account types:
1. individual account
2. joint account
3. minor account
So we test everything! From spacing, font sizes, lines to colors and contrasts.
And then we came to the final version: presented, tested and validated by all teams involved including product, design and software. The idea was to create just one component that would be developed in a unique way with its variants and core elements. This was the biggest development impact and yet it worked in compliance with the premise established at the beginning of the project: that it would have the least impact possible. In this way, all account switching rules could be easily connected with the component in each specific product context.
Prototype and documentation
In the end, we organized all the focal points of the teams involved in a Teams chat with the FigJam document with all the documentation pinned and we published each definition or update in that file. In addition, this component was added to the official design system library and is now used by all teams in the Sicredi X application.
The result was a simple component that fits the current application architecture without causing major changes and meets all business and engineering requirements.
Do you have any questions or would like to exchange some ideas? Check out the contact page and contact me.
Thanks! ;)
