Redesigning the card experience for Mastercard
I led the redesign of Asaas Card across web and mobile, creating a scalable experience for 70,000+ customers migrating to Mastercard.
Scope
End-to-end redesign across web and mobile
My Role
Senior Product Designer
Team
+4
Timeline
2025–May 2026
Impact Overview
Customers migrated
70,000+
New card requests
+80%June to July 2025
Approved transactions
+95.9% · June to September 2025
Asaas was investing in the card as a new source of revenue. The company already had a roadmap for virtual cards, additional cards and other capabilities, even though its priorities continued to change as the product evolved. The experience needed to support what was already planned without locking the team into a structure that would become obsolete with the next feature.
The existing product was not ready for that growth. It treated each card as a separate entry point, with statements, limits, transactions and controls organized beneath it. That model made sense for a smaller offering, but it could not support several cards sharing the same financial information or provide a clear place for new capabilities.
At the executive level, Asaas decided to unify its fragmented card portfolio under Mastercard. The decision established a clearer product direction, but it also meant replacing three different card models:
Card type
How it worked
Debit
Worked as credit while drawing funds from the Asaas account
Prepaid
Required customers to add funds before use
Postpaid credit
Was discontinued because the technical setup could not support it well
The redesign therefore had to solve for the current migration and for a roadmap that was still changing. Instead of designing a fixed set of journeys for the features we knew at the time, we needed a structure that could aggregate new card capabilities as they were introduced.
The challenge
How might we improve the card experience during the move to Mastercard, make financial information easier to understand and create a structure that could accommodate new capabilities over time?
The work happened in two stages.
01
Lecacy
I designed the migration journey and adapted the existing Elo experience.
02
Room for the roadmap
I led the broader redesign, starting on mobile, around the new Mastercard account model.
The migration defined how customers entered the new product. The redesign defined how the product worked after they arrived.
We used market benchmarks and reviews with Product and Engineering to define the account model, financial states and migration journeys. Existing customers continued to see Elo until migration, so the new Mastercard model could only be observed in the released product.
Most demand reaching the team concerned access to the card and its core functionality. We then released the product to preselected groups, monitoring adoption and issues before expanding each migration wave.
WHAT WE DID
WHAT IT CLARIFIED
Benchmarked other card products
Common mental models and interaction patterns in other card products
Mapped product and policy rules with Product
The offering, regulatory requirements and credit-policy direction
Mapped technical constraints with Engineering
Implementation constraints, the Pismo integration and card operations
Documented states, exceptions and customer journeys
States, exceptions and the journeys customers needed to complete
Monitored migration and card-use funnels after launch
Migration and card-use funnels showed how customers behaved in the new product
BEFORE LAUNCH
Reduce structural uncertainty
Market benchmarks · Product rules · Engineering constraints · Internal reviews
AFTER LAUNCH
Observe real behavior
Partial release · Migration funnel · Approved transactions · TPV · New card requests
A shared starting point for a growing card portfolio
We could not present the new structure as a validated customer insight. It was a product hypothesis grounded in the Mastercard model, the roadmap and the rules mapped with Product and Engineering.
If shared financial information sits at account level, customers can understand the whole relationship before managing an individual card.
Account level
Statement · Shared limit · Account history · General settings
Card level
Block · Password · Cancellation · Individual card settings
This split gave virtual cards, additional cards, and future financial-management features a predictable place. My role was to translate the hypothesis into an information architecture, define its states, and monitor how the structure performed after launch.
01 · Bring every migration channel into one journey
The migration experience was fragmented. App, web and customer communications used different structures and explained the change in different ways. Customers could enter from several places and receive inconsistent information during a sensitive financial change.
We defined one sequence and one set of messages, from the first communication through eligibility, confirmation and completion. Web already supported migration, so we created an equivalent mobile experience and connected banners, email and marketing campaigns to the same journey.
OPERATIONAL CONSTRAINT
DESIGN RESPONSE
Monthly migration waves
A single journey that did not depend on batch size
Customers with several cards
A separate path for accounts with commercial agreements
Loss of credit for some customers
Explain the consequence and the actions still available
Final automatic migration
Treat completion as an operational result, not voluntary adoption
02 · Put shared information before individual card controls
The new hub shows the statement, limit, general settings and consolidated transaction history before the customer opens a specific card.
Blocking, password changes, cancellation and other controls remain attached to the card they affect. The hierarchy reflects the Mastercard model, where several cards can belong to one account and share the same statement and limit.
The hub also gives virtual and additional cards a place without creating another top-level journey.
One card, one experience
Customers had to select a card before reaching its statement, limit, transactions or settings. As the offering expanded, information shared across cards remained organized around individual cards, making the account harder to understand as a whole.
03 · Make every financial state explain what happens next
The previous experience did not make the payable statement or its status clear enough. The redesign brought amount and status forward so customers could identify the relevant statement and act on it.
We documented open, closed, unpaid and overdue statements; blocked, fully used and recently increased limits; and cards blocked by the customer, company or system.
Limit management supported a slider and direct value entry. Transaction history separated debit and credit activity and left room for future categories.
04 · Give web and mobile distinct responsibilities
Customers often manage a card away from a desk, so we started the broader redesign on mobile.
Relationship
Use case
Pace
Design focus
Both platforms used the same concepts and visual language, while their depth and layout reflected the tasks performed in each context.
Asaas had historically invested more in desktop, so the mobile work required new patterns. I worked with the Design System team on tabs, statement and limit cards, transaction rows, detail screens and the limit-adjustment control.
The launch completed the transition to Mastercard and was followed by growth across card requests, approved transactions and TPV.
70K+
customers migrated
+80%
new card requests
+95.9%
approved transactions
+90.1%
TPV from June to September
More than 70,000 customers moved to Mastercard within the Elo deadline. The rollout began with controlled waves and concluded with the automatic migration of approximately 42,000 remaining customers, allowing the team to complete the transition while managing operational risk.
Card use after launch
Approved transactions and TPV, June to September 2025
Month
Approved transactions
TPV
June
37,725
R$2.82M
July
47,819
R$3.60M
August
58,180
R$4.45M
September
73,903
R$5.36M
Three decisions that created leverage beyond launch
Model shared finances before individual controls. Moving statements, limits and transaction history to the account level gave virtual and additional cards a shared foundation.
Make policy consequences explicit. Product and the credit team determined credit eligibility. I designed how customers understood the outcome and the actions available to them.
Use delivery to strengthen the design system. Building the mobile experience required patterns Asaas did not yet have, so I developed reusable components and interaction patterns with the Design System team.
Credits and responsibilities
My contribution
Led the end-to-end redesign across web and mobile; owned the migration experience and initial Elo web adaptation; benchmarked card products; structured the account-level information architecture; documented financial states and exceptions; worked with the Design System team; and mentored a senior designer for three months.
Partners and boundaries
Product owned regulatory requirements, product strategy, the card offering and credit-policy direction.
Engineering owned implementation, the Pismo integration and card operations. The Design System team supported mobile interaction patterns.
