home. / work. / iDL – Itaú Design Language (B2B)

Bank Challenge

• Low satisfaction levels across digital channels.  
• Negative feedback in surveys, app stores, and customer service channels.  
• A vast ecosystem of brands and sub-brands.  
• Accelerated growth of products and development cycles.  
• Lack of a unified structure and guide.  
• Time-to-market inefficiencies.

Business Challenge

• Transitioning to a work tool mindset.  
• Delivering intelligence and personalization to serve a wide range of customer profiles (moving away from “one size fits all”) while keeping pace with increasing competition.  
• Matching or exceeding competitors’ time-to-market capabilities.  
• Leveraging data heavily for decision-making and results tracking.  
• Continuous evolution of experiences without abrupt disruptions (addressing resistance to change).  

Customer Challenge

• Bureaucratic processes causing time delays (e.g., including and authorizing actions).  
• Complex usability (e.g., supplier payment system – SISPAG).  
• Lack of personalized experiences for individuals and businesses.  
• Inconsistent experiences between personal and business banking, leading to cognitive strain and frequent relearning.  
• The perception that the bank is not a business partner contributing to their success.  

Exemple: 3 different experiences for a login page

Defining the objectives

We analyze and prioritize the main challenges and desires of corporate clients.

We aim to be recognized as an essential work tool, seen as a business partner that supports clients’ decisions.To be the leading business bank for companies, delivering the basics with excellence.

Evolution and Scale Strategy

We can divide the construction of the IDL into two main scopes of work:

Structuring the Digital Product

A data intelligence that permeates the entire customer experience

Tests Conducted by the Core Team

Not Everything Is Roses

• Due to tight deadlines, the natural person team stopped testing and developing reusable components, causing massive rework for the corporate entity team.
• In the OPS team, there were squads dedicated to NP but none for CE which consistently resulted in long queues for the officialization of components into the library.
• Egos also played a role, as many teams felt threatened when we refactored a component.
• The timing mismatch between NP and CE teams created additional challenges.
• Changing the mindset of designers and developers to adopt the new Design System (DS) was a significant hurdle.

Minimizing the Challenges

• The CE team created a HUB of specialists (governance squad) tasked with connecting with the NP team.
• Alongside the OPS team, we developed a more structured contribution model, where we refactored, fixed bugs, or developed components within our squads and only involved the OPS and NP teams for regression testing. This reduced bottlenecks and speed up the officialization process in the core library.
• Secured headcount to join the OPS team, exclusively focused on CE team.
• Eliminated CE’s dependency on NP, allowing the CE team to progress at its own pace and meet the needs of its clients, as NP was already significantly more advanced.
• Established library usage metrics and mandatory training courses for all areas, with leaders responsible for ensuring their teams completed the courses.
• Templates were created to facilitate visual execution and planning.

Diagnostics and Roadmap for Core Team and Communities Deliverables

Establish a clear and actionable roadmap for evolution and prioritization.

Since the core team was only responsible for login, home, menu, and core structure such as the chassi, we defined a governance team together with the project leadership to conduct an in-depth analysis of usage across channels, pain points, current product architecture, completeness on both mobile and web, and finally, we cross-referenced all this data in a priority matrix. This allowed us to define a roadmap based on higher usage versus the biggest pain points, so that the communities and products, beyond the core team, could plan to start developing their journeys in iDL.

Expansion Plan

Satisfaction Results

We conducted weekly metric reviews with the core team and biweekly sessions with the extended team. The pilot was assessed by comparing pre- and post-iDL access metrics, as well as tracking GMUDs (Managed Updates), features, and stories activated and completed, along with BCP (Business Continuity Plan), among others. Metrics such as Likert scales, NPS, customer service feedback, clicks, accesses, and more were also measured.

iDS Metrics

A huge challenge, due to the scalability and consistency requirements, was ensuring that all teams used the core library without breaking the components and that the development team also used the GitHub library, rather than developing broken code, reusing already developed code and thus reducing time spent both in design and especially in development teams. This is how the iDL Academy was born—a portal with all the necessary courses and training to create and develop experiences within the new design system. And, of course, we tracked library usage data and the volume of people completing the courses. In addition, we gathered data such as the average time for design and development before and after iDL, as well as the volume of new components, illustrations, and brands adopting the design system. All of these follow-ups were essential to ensure a skilled and engaged team.

Awards