Project summary: How I rethought the payments experience to go beyond centralizing services and turn everyday payments into an opportunity to increase preference for Santander.
The project started from a findability problem, but had a bigger ambition: increase Santander's relevance in customers' everyday payments and contribute to higher transactionality and recurrence in the app.
Instead of simply bringing different payment methods into the same place, we explored how the bank could better understand customer intent, make frequent actions easier, and help customers keep track of their financial commitments.
The solution evolved through different product approaches, customer testing, technical constraints and Design System discussions, and later started contributing to a broader strategy of convergence with the Global experience.
THE CHALLENGE
Payments are one of the most frequent interactions between customers and their banks.
For Santander, this represented a strategic opportunity. It was not enough to offer Pix, bill payments, transfers and other services. We wanted Santander to become a more natural choice when customers needed to pay, contributing to an internal transactionality metric where payment volume and frequency were relevant factors.
This led us to a bigger question than simply “how can we centralize payments?”:
How can we make Santander a more natural and priority choice for customers to manage and make their everyday payments?
STARTING POINT
Shortly before the project started, an initial page had been created to bring together the main payment methods.
It came as a quick response to an increase in customer complaints, mainly related to findability: customers had difficulty understanding where they needed to go to complete different types of payments.
This new entry point helped customers find these features, but it still worked essentially as a list of products.
In other words:
We had centralized access, but we had not yet created an integrated payments experience.
Customers still needed to understand the bank's taxonomy and answer:
“Which product do I need to use?”
When their intention was usually much simpler:
“I need to pay this.”
MY ROLE
I worked as the Product Designer responsible for evolving the experience, partnering mainly with my Design Lead, Product Managers, Engineering, Research and business stakeholders.
My role included:
synthesizing data, complaints, benchmarks and research learnings;
facilitating prioritization and co-creation discussions with Product and Business;
exploring different product approaches and information architectures;
creating flows and prototypes;
planning and conducting user validation;
turning learnings into product decisions;
following the solution after launch and supporting new iterations;
presenting and discussing the Brazilian direction with the Global team.
UNDERSTANDING THE PROBLEM
Before defining a solution, we combined different sources of evidence to understand the problem from three perspectives:
BUSINESS
What did we need to move to increase relevance, recurrence and transactionality?
CUSTOMERS
What difficulties were appearing in complaints, behavior and research?
MARKET
How were new behaviors, especially those influenced by Pix, changing customer expectations? And which future trends could change financial experiences?
We analyzed internal data and Google Analytics, customer complaints, benchmarks and desk research.
We also ran co-creation and prioritization workshops with stakeholders to discuss opportunities such as Open Finance, reminders, scheduled payments, shortcuts and other possible capabilities.
These inputs became the foundation for our first product hypotheses.
KEY INSIGHTS
The investigation revealed four important principles for evolving the experience.
CUSTOMERS START WITH AN INTENT, NOT A PAYMENT PRODUCT
A big part of the difficulty was not the lack of functionality, but understanding which product to use to complete a task.
The bank's architecture required customers to first understand the differences between Pix, bill payments, transfers and other methods.
But their intention was usually much more direct:
“I need to pay.”
IMPLICATION
Reduce the need to choose the payment method before starting the task.
THE PAYMENT JOURNEY OFTEN STARTS BEFORE THE APP
Many customers already entered the app with a payment code or other payment information copied.
In the previous experience, they still needed to figure out where that information should be used.
IMPLICATION
Allow the information brought by the customer to help the system identify and direct them to the right journey.
PAYMENTS ARE FINANCIAL COMMITMENTS, NOT ONLY TRANSACTIONS
Complaints and research also showed concerns around remembering payments, identifying what was still pending, and understanding what needed attention at that moment.
The opportunity was not only about completing a transaction.
It was also about helping customers understand their financial commitments.
IMPLICATION
Evolve the experience from a list of payment methods into a view that could also help customers prioritize and keep track of what needed to be paid.
NOT EVERY ACTION DESERVES THE SAME HIERARCHY
Internal data showed different usage patterns across payment methods.
At the same time, workshops and research pointed to new opportunities that could be added in the future.
IMPLICATION
Give more prominence to the most relevant and recurring actions, while keeping an architecture that could grow without turning the experience back into a long list of features.
DESIGN DECISIONS
The insights became four principles that guided our design decisions.
1. STARTING WITH INTENT
Create an entry point that reduces the need for customers to decide which payment method to use before taking action.
2. OPTIMIZING FREQUENT ACTIONS
Prioritize the most frequent actions and make recurring tasks easier to access.
3. FINANCIAL COMMITMENTS
Give visibility to what was pending, upcoming, overdue or scheduled, helping customers understand what needed attention.
4. DESIGN TODAY WITHOUT BLOCKING TOMORROW
Build an experience that was viable for the current product, but still compatible with a future vision of a financial hub, personalization and new financial capabilities.
EXPLORING DIFFERENT PRODUCT APPROACHES
Throughout the project, we were not simply trying to find “the best screen.”
We explored different models for the role payments could play inside the app.
EXPLORATIONS 1–2: ORGANIZING THE DISCUSSION
The first explorations helped turn different opportunities and features into something tangible.
We tested different hierarchies for shortcuts, recurring payments, Open Finance and monthly payment tracking.
The first proposal was still quite constrained by the existing Design System, but it played an important role: making the hypotheses concrete enough for Business, Product and Design to discuss priorities and trade-offs.
{IMAGE — EXPLORATION 1 / EXPLORATION 2}
EXPLORATION 3: DEFINING THE STRATEGIC DIRECTION
The third exploration expanded the discussion.
Instead of only offering payment methods, we moved the experience closer to a financial hub vision:
broader financial overview;
prioritized payment actions;
scheduled payments and reminders;
contextual content;
tracking monthly commitments.
We also explored a multi-bank view through Open Finance to help customers make payment decisions considering their broader financial context.
This exploration helped us define the long-term direction we wanted to preserve.
EXPLORATIONS 4–5: REFINING AND MAKING IT VIABLE
From that direction, we started bringing the experience closer to something that could actually reach customers.
One important change was giving more prominence to the main intention:
Pay.
This was the moment when the unified field became stronger in the solution.
Instead of asking customers to first decide which payment method to use, the proposal allowed them to enter the information they already had and let the system identify the right journey.
At the same time, some more ambitious hypotheses had to be revisited.
The multi-bank balance view, for example, was removed because of technical feasibility limitations.
We also refined shortcuts, contextual content and, mainly, how financial commitments should be displayed — whether they should appear open or in a more consolidated view.
DESIGN SYSTEM + FEASIBILITY
One of the main challenges of the project was avoiding two extremes.
On one side, designing only around the limitations we had at that moment and ending up reproducing the existing model.
On the other, creating an interesting future vision that would be impossible to implement.
In the first explorations, we worked more strictly within the existing Design System.
As the product direction became clearer, we started discussing where consistency should be preserved and where new needs justified evolving the system.
The solution needed to work as a strategic step between the product we had and the financial hub vision we wanted to build.
VALIDATION AND ITERATION
Our research strategy also evolved together with the maturity of the solution.
In the first explorations, we conducted concept testing to understand whether the different models made sense to customers and which capabilities were perceived as more relevant.
As the direction became more mature, we moved into more focused usability testing, especially around the unified field and the way financial commitments were presented.
The tests helped us refine hierarchy, content and interaction behavior before launch.
DESIGN AS A CONTINUOUS HYPOTHESIS
Not every decision ended when the product went live.
One of the main discussions was how to show upcoming payments for the month.
My main hypothesis was to use a consolidated view, allowing customers to quickly understand how much they still had in commitments and access the details when needed.
During implementation, we initially decided to keep the list open, giving direct access to each payment.
After launch, the consolidated-view hypothesis was tested again through an A/B experiment.
The summarized version performed better and became part of the next evolution of the experience.
This became an important learning from the project: design decisions did not need to be treated as final. They could continue as hypotheses and be evaluated through real customer behavior.
FROM LOCAL TO GLOBAL
With the Brazilian direction already more advanced, the Global team joined the discussions as part of a broader strategy to converge experiences across markets.
I presented the explorations, hypotheses and learnings we had built in Brazil so we could evaluate whether that direction could also work in other markets.
There was a strong convergence between the model we had been developing locally and the direction Global was beginning to structure.
The Brazilian proposal started contributing to that evolution and was adapted to the new Global Design System that was being developed at the time.
This change also brought a new layer of governance.
New capabilities for the experience would no longer be evaluated only from a Brazilian perspective, but would also need to consider priorities and needs from other markets.
{OPTIONAL IMAGE — GLOBAL CONVERGENCE / GLOBAL DESIGN SYSTEM, ONLY IF IT DOESN’T EXPOSE SENSITIVE INFORMATION}
THE SOLUTION
The implemented solution transformed the payments area into an experience that combined:
a unified field centered around customer intent;
shortcuts for recurring actions;
contextual alerts and content;
an integrated view of financial commitments;
an architecture prepared to incorporate new capabilities over time.
More than bringing different products together, the new structure created a foundation for evolving payments as part of a broader financial experience.
{IMAGE — EXPLORATION 5 / FINAL PROPOSED SOLUTION}
{IMAGE — CURRENT SANTANDER APP EXPERIENCE}
Evolution of the experience currently available in the Santander app.
IMPACT
The strategic ambition of the project was to contribute to higher transactionality.
Because this is a composite internal metric and the experience continued evolving after launch, I don't attribute a change in this metric exclusively to the redesign.
However, we were able to track relevant adoption and behavior indicators.
During the first months, we saw an adaptation curve to the new experience, while monitoring complaints and opportunities for improvement.
As the solution matured:
we saw a positive evolution in NPS;
customers accessed the new payments area, on average, 4 times per session, compared to 2 accesses to the Pix area;
4.8 million bill payments were initiated through the financial commitments list, a 32% increase compared to the previous DDA entry point.
Beyond usage results, the experience became the foundation for further evolution of the journey and continued to be iterated based on real customer behavior.
LEARNINGS
Making things tangible early helps turn ambiguity into decisions.
Alignment also needs to be treated as part of the product: making, revisiting and remembering agreements and objectives.
Thinking beyond the immediate delivery: building something that can support new capabilities, evolve with the product and later connect with the needs of other markets.
