A platform built for mobile, ready to conquer the web

Íon is Itaú's investment platform, already well-established in the mobile environment as a robust and sophisticated solution for investors.

The challenge was to expand this experience to the web, creating an omnichannel journey that maintained the same level of excellence, now adapted to the desktop context, and more than a simple interface adaptation, the project required rethinking flows, components, and interactions for a new usage scenario, with a strong focus on accessibility, performance, and scalability. The goal was ambitious: to reach 15,000 monthly users by December 2023.

Cross-functional design at the heart of the platform

As a senior product designer, I was part of the squad responsible for the product showcase on íon web, one of the platform's most strategic areas, focused on presenting investment products in a clear, engaging, and efficient way. My role was cross-functional, ranging from UX and UI decisions to technical alignment with development and QA teams.

• Conversion: I structured journeys that encouraged user engagement and decision-making, especially for complex financial products.
• User satisfaction: I worked to create a fluid, intuitive, and pleasant experience, reflected in 80% positive feedback through Likert-scale surveys.
• Accessibility: I actively ensured the platform was inclusive, following best practices and digital accessibility standards, which led to the site being recognized as the most accessible in the sector.

Iterating in the open, from 100 users to 30,000

My involvement in the project began in August 2022, and from the start, we followed an iterative, data-driven approach. With each new release of the platform, whether in beta, alpha, or the final launch, we collected both qualitative and quantitative feedback from users accessing the site. These insights were essential for identifying friction points, validating hypotheses, and prioritizing improvements to the features being developed.

What we inherited, and what needed to change

When I joined the project, I was introduced to a comprehensive set of materials developed by the consultancy Work & Co, which had created the initial concept for what íon web could be. This work was instrumental in selling the vision to the business team and served as a starting point for development. However, upon deeper analysis, it became clear that, despite its strategic value, the material was still far from being a product ready for implementation.

Some of the main issues I identified early on included:

• Misalignment with the iDS (Itaú Design System): Many of the components used did not follow the visual and functional standards of the bank's design system, compromising consistency and making technical implementation more difficult.
• Lack of accessibility: Several interface elements did not consider accessibility best practices, limiting the platform's usability for people with disabilities.
• Incomplete flows: Many navigation and interaction flows were only partially defined, lacking consideration for alternative scenarios, empty states, or expected behaviors in different usage contexts.

These findings made it clear that, while the consultancy's material was a strong conceptual foundation, there was still significant work needed in refinement, adaptation, and depth to turn that vision into a viable, accessible, and standards-aligned digital product.

Bridging the gap between design and development

Throughout the project, I encountered challenges that required not only technical knowledge but also a strategic and collaborative approach to ensure that the deliveries were feasible and consistent. Two key points stood out.

Integration with the iDS (Itaú Design System)

One of the main challenges was the discrepancy between the design system libraries available to the design and development teams. While we, as designers, worked with an up-to-date and complete library, developers had access to an outdated version that often lacked the same components or expected behaviors. This gap required constant alignment with the tech team. In many situations, I had to:

• Map what was actually available in the development stack, understanding the real limitations of the library used by the devs.
• Adapt layouts and flows based on those constraints, without compromising the user experience.
• Negotiate intermediate solutions, proposing visual or functional adjustments that maintained consistency with the iDS, even if the implementation wasn't 100% faithful to the original design.

This process demanded empathy, flexibility, and close communication with the technical team to ensure that the solutions were realistic while still aligned with the project's quality and experience standards.

Usability testing

Another major challenge was the strategic decision to postpone usability testing until after the launch. Due to a tight timeline and pressure to go live, we chose to validate the journeys based on best practices, internal benchmarks, and qualitative feedback during the beta and alpha phases. To mitigate these risks, I took a proactive approach:

• Monitoring usage metrics and user behavior in intermediate versions.
• Collecting qualitative feedback from real users during controlled testing phases.
• Adjusting flows and components based on data and evidence, even before the official public release.

This approach allowed us to launch a solid, functional, and well-received MVP, even without formal usability testing prior to go-live.

Logged-in Homepage

The logged-in homepage was designed to be the user's entry point into the íon web experience. I worked on structuring a page that balanced informative content, efficient navigation, and personalization. Key elements included:

• Interactive cards with information about the stock market, the user's investments, and product suggestions.
• Regulatory content blocks, integrated discreetly but accessibly.
• Relevant news and updates for investors, curated automatically.

Product Carousels

The consultancy Work & Co had proposed a visual concept where each carousel would have a distinct color, forming a gradient as the user scrolled down the page. While the idea was visually appealing, the original concept included only 8 colors, which quickly proved insufficient given the number of carousels the product needed to support.

I led a study to expand this palette from 8 to 16 colors, ensuring visual harmony and accessibility. This work was done in collaboration with designer Ayrton Mugnaini. We also defined the ideal card sizes for each carousel, considering different screen resolutions and breakpoints. Together with the business team, we segmented the content and defined strategic titles for each carousel, such as:

• "Diversify your investments in equities"
• "Top 5 Portfolio" · "Top Gainers of the Day" · "Top Losers of the Day"
• "Invest Abroad" · "Real Estate Funds Recommended by íon"

Product Table

The product table needed to be robust, high-performing, and highly functional. I designed its structure with the following features in mind: real-time pricing updates, advanced sorting and filtering, responsive pagination, and visual performance indicators. I also ensured the table was fully accessible via keyboard navigation and screen readers, in line with the accessibility standards defined for the project.

Product Detail Page

This screen displayed specific information about an asset. The price chart required significant technical refinement in collaboration with the development team to balance technical constraints with user needs.

Additionally, this delivery had a special focus on accessibility. Since charts are not read by screen readers, I created a complementary table that translated the visual information into textual data.

News Page

The news page was created to integrate informative content into the investment journey. I worked on structuring an internal page that allowed for smooth reading of articles, analyses, and announcements. This delivery helped position Ion Web not only as a transactional platform but also as a knowledge hub for investors.

Accessibility

This initiative was carried out in direct collaboration with the specialized team, ensuring that the solutions were inclusive and functional for all user profiles. Robust accessibility specifications were essential to guarantee that the designed solutions were viable and delivered with quality.

Data-driven changes

Throughout the project, we evolved several features based on two pillars: active customer listening and strategic data analysis. A standout case was the table display function for the chart. In the first version, few users knew they could activate it. With a clear and intuitive redesign, I transformed friction into noticeable engagement.

Double the users, more than twice the conversion

By the end of the project, the results exceeded initial expectations, both in terms of adoption and the quality of the experience delivered. The collaborative work, combined with an iterative and user-centered approach, enabled íon web to be launched as a solid, functional, and well-received product.

One design system. Four tech stacks. Thousands of people.

NTT DATA assembled a multidisciplinary squad of specialists focused on different aspects of the design system: design, mobile and desktop technology, quality assurance, accessibility, and strategy. Our primary objective was to standardize and align the four core technology stacks, Angular, React, Flutter, and Swift, while ensuring Figma components and templates remained up to date and fully optimized for designers and developers.

As a senior designer on this project, alongside one to three other designers depending on the project phase, I was responsible for conducting initial component analyses, refining designs within the core Figma library, updating technical handoff specifications, and ultimately revising the design documentation on the internal design system website. To provide a sense of scale, iDS consists of over 70 components, is utilized by approximately 500 designers, more than 5,000 developers, and over 6,000 product managers. This was a large-scale, high-impact initiative spanning nearly a year, an experience that significantly deepened my expertise in design systems and their strategic implementation.

Getting 20 people aligned before touching a single component

One of the first steps in the project was a general alignment among the nearly 20 professionals involved. After initial introductions, we conducted a detailed assessment based on the client's briefings, establishing a clear understanding of the project scope and execution timeline for each area. Our primary responsibility was to systematically review over 60 designated components, analyzing them in detail, identifying inconsistencies, and implementing the necessary corrections.

To ensure alignment on what aspects of each component we would evaluate and how far our revisions would extend, we developed initial sketches and diagrams in FigJam. These artifacts helped define our workflow and delineate the responsibility structure within the team. The workstream framework and accountability map became foundational elements guiding our approach throughout the project.

From chaos to clarity: how we built our process

Our first analysis was both the most intriguing and the most chaotic. The team focused on a single component, gathering every possible piece of information and insight. It was during this process that the design team's role in consolidating findings and creating a structured report became clear, something that had not been explicitly defined before. This approach became the foundation for all subsequent component analyses, with the design team centralizing evaluations and reporting any critical issues.

Although our initial presentation wasn't the most polished, the analysis was well received by the Itaú team, who recognized it as the first tangible value delivery. We identified key areas for improvement, including taxonomy inconsistencies, documentation gaps, and accessibility issues. It also became evident that efficient communication was essential to ensure components were developed simultaneously across multiple technology stacks. Without it, discrepancies and misalignments were inevitable.

Following the delivery of our first report and the subsequent approval of the proposed corrections, we immediately shifted our focus to implementing the necessary adjustments, refining our workflow, and preparing for the analysis of the next batch of components.

Here is an example of one of the subsequent analyses we conducted, this time with a more structured approach, componentized elements, and full alignment with the client's visual identity. We consistently aimed to create deliverables that could evolve into internal tools or reference materials, ensuring we spoke the client's language and adhered to their brand guidelines, including colors, typography, and design principles.

To facilitate asynchronous reviews and ensure comprehensive documentation, we also included a final column consolidating key insights. This section provided an overall assessment of the component, highlighted inconsistencies and issues, and outlined opportunities for improvement. In case of any doubts regarding points discussed during our analysis presentation, stakeholders could simply refer to the final column for clarification.

Later, we had to adapt our deliverables due to timeline constraints and changes in the team structure. To streamline the process while maintaining essential quality, we developed a minimum viable version of our analysis, focusing on three core aspects for each component:

• Anatomy
• Properties
• Design Tokens

Where design meets development

After refining our workflow and completing our initial analyses, the next steps were to update the components in the bank's official Figma library and, subsequently, revise the technical handoffs. As a team, we consistently adhered to best practices at every stage, working in isolated branches for each component to ensure a structured and controlled update process.

Additionally, to facilitate the approval process and optimize time for all stakeholders, we placed component playgrounds within Figma. These interactive spaces allowed reviewers to explore components in different states and variations, often accompanied by a concise changelog summarizing the updates made.

Once the Figma updates were finalized, we moved on to the handoff phase, one of the most critical aspects of our work as a design team. This step served as the final bridge between our improvements and the development team, ensuring seamless implementation. From the outset, the Itaú team shared with us an initial handoff model they had been using, and we quickly began refining and adapting it to fit our needs.

Ayrton Camossa, the Lead Designer of the project, transformed each section of the provided handoff model into reusable Figma components, ensuring consistency across all deliverables. This mini-library of handoff elements was carried throughout the project and significantly accelerated our workflow, maximizing the reuse of standardized elements while maintaining clarity and efficiency.

My mainly contribution for the handoff process was creating structured properties and variants table that was quickly adopted as the standard for all materials we produced. This table became a foundational element, allowing developers to clearly understand each component's full range of possibilities. While Figma's Dev Mode provides a solid foundation for developer handoffs, a well-structured example table remains an invaluable reference, eliminating ambiguities and further streamlining our process.

Additionally, we collaborated closely with the accessibility teams from both Itaú and NTT DATA to build and refine accessibility guidelines for each component. Given that accessibility is a fundamental principle of the design system, we dedicated significant effort to maintaining and even raising the system's high standards of inclusivity and usability.

We handled both relatively simple handoffs, such as the image component example above, and highly complex ones, like the modal component example below. Regardless of complexity, we always put ourselves in the shoes of developers and QA professionals who would rely on this documentation, ensuring clarity in every aspect of a component development.

To finalize this phase, and in alignment with the internal guidelines set by the iDS team, we conducted all approvals and reviews using Figma's branch review tools. Since updates were automatically notified through Figma's interface and email, we maintained a clear and structured approval record at all times. Once a handoff was approved, we simply updated our Overview Panel to reflect the latest status of each step.

The phase no one planned for, and why it mattered

As we approached the final stretch of the project, we were unexpectedly assigned a new phase in our workflow. Beyond updating components and technical handoffs, we were now responsible for revising and maintaining the official documentation on the design system's internal portal.

This task built upon the work of another consultancy that had previously handled documentation but was now shifting to a different initiative. Since the components had been updated after their involvement, we needed to revisit these materials to ensure full alignment and consistency.

Each component went through a two-step process:

• Initial validation in Figma: We updated usage examples, property tables, and instructional content. To streamline approvals, we also introduced a simplified changelog format, clearly documenting and illustrating every change, an approach we had successfully applied in other stages of our workflow.
• Portal updates: We then uploaded revised images and text to the designated documentation platform, ensuring that the latest specifications were accessible to all stakeholders.

Below is an example of our modal component update (original version on the left, revised version on the right), where we meticulously reviewed every instance and application of the component. These documents are referenced daily by thousands of designers, developers, and product managers, making precision and clarity essential.

600+ issues resolved. 60+ components reviewed and standardized. One system to rule them all.

Working in a multidisciplinary team required close collaboration and shared responsibility across design, development, QA, and accessibility. Strong partnerships between disciplines allowed us to analyze, refine, and update components effectively while keeping our workflow seamless.

We take pride in the impact we achieved: over 600 issues resolved across dozens of components, improving consistency, accessibility, and overall quality. Through teamwork and continuous iteration, we optimized the design system while establishing a scalable, efficient delivery process for future iterations.

More than just delivering components, we delivered clarity, trust, and a solid foundation for the design system to continue evolving with consistency.

A new project, an untested journey and an uncertain budget

Itaú was expanding into the free energy market, aiming to become a reference in the sector following new regulations that allow consumers to migrate from the traditional regulated market to the open market. The initiative offered individual customers spending over R$200/month on electricity the chance to save 10% on their bills, without needing to invest in their own infrastructure like solar panels.

When I joined the project, a Visioning had already been designed. I was brought in to turn it into an MVP and, at the project coordinator's request, conduct usability testing with real users, something that had not yet been done.

We didn't know if the budget would come. So I started testing.

The project sat within IBBA, the bank's B2B structure, but the end client was Retail, a B2C structure. That difference created a bureaucratic barrier that made direct access to clients impossible. On top of that, we couldn't use Itaú's own research credits, making a traditional test with a research institute extremely expensive: around R$40,000.

The project manager was working to get the budget approved, but there was no guarantee it would happen. We needed to move forward regardless. The alternative was the RITE method.

Midway through the tests, the budget was approved. What started as a plan B became an essential part of the process: RITE refined the journey and the prototype to the point where the institute's test became far more efficient.

The tool that solved the problem

RITE (Rapid Iterative Testing and Evaluation) is a usability testing approach designed to identify and fix problems quickly and continuously, during the testing process itself. Unlike traditional testing, RITE allows prototype adjustments between sessions, or even during a session, without waiting for all tests to finish before acting.

The method originated in 2002 at Microsoft Games Studios during the development of Age of Empires II. Engineers realized the development pace was too slow and needed an approach that allowed immediate iteration and implementation of improvements.

During testing, problems are classified into three categories:

• Obvious cause and quick fix: corrected immediately and tested in the next session
• Obvious cause but harder to fix quickly: adjustments started to be tested in the following session
• No obvious cause or solution: more data needed before taking any action

Six tests, five prototypes, many discoveries

For the tests, two journeys were considered: the end-to-end purchase journey and the post-purchase journey. Based on these, I developed a test script with targeted questions aimed at validating hypotheses built by me and the business team. For recruitment, we looked for people spending over R$200/month on electricity.

We ran 6 tests across 5 different prototype versions.

Home screen

In the first version, users didn't notice there was more content below the fixed button — it was blocking the visual flow. We also identified redundancy: two buttons with the same function placed close together created confusion.

The decision was to keep the first button to gather more data on whether it was truly necessary, and move the discount simulation button to the bottom of the screen.

Checkout screen

In the first test, users assumed the discount would be applied the month after signing up, which was incorrect. We updated the journey to clearly communicate that there would be an onboarding process and inform the estimated timeframe for completion.

In the next test, a new issue emerged: users had no idea who the partner behind the service was. One participant joked it was the "mystery partner." We added the partner's name to the journey.

The final version featured a closing screen with much clearer next steps in the contracting flow.

Product and billing cards

In the first version, the open billing section competed visually with the address card, and users felt the information was repetitive. We removed the section and moved the billing line inside the card itself.

In the next test, users could only find information like payment history through trial and error. We updated the section title and action button to be more direct.

The final version had a clearer title and a more objective call-to-action, enabling users to self-serve without friction.

Product cancellation

The feedback here was sharp: having to contact the partner to cancel a service purchased through the app was considered a terrible experience. As it was a more complex issue to resolve, we decided to gather more data before building the cancellation journey.

RITE opened the door for the definitive test

With the prototype refined through RITE, we ran a full usability testing round conducted by a research institute.

The RITE method was essential not just for validating hypotheses, but for refining the journey, the prototype, and the test script itself. This allowed the team to get the most out of the institute's testing sessions, extracting new insights with greater depth and precision.

What I would bring to the next project

Think about context before applying RITE. Do you have time to update the prototype between sessions? Can you run multiple tests in the same day? The method only works well when there are real conditions for iteration.

Have a solid foundation. Define clear hypotheses and specific objectives before you start. Knowing what you want to discover is what makes RITE efficient, not just fast.

RITE is not chaos. Not every user error or hesitation requires an immediate change. Avoid rushed decisions: observe, analyze, and then validate.

Be agile, but responsible. Every prototype change must be thought through strategically. Agility does not mean disorganization. It means focus, judgment, and collaboration.