Context
The most exposed product in fintech
Stone is a fintech focused on payment solutions for Brazilian entrepreneurs. Pix is one of the company's highest-volume products — any design decision, no matter how small, can directly affect the customer's relationship with their money.
I joined the team after a period working on the internal administration platform. It was a significant shift: moving from an internal product to the application's storefront. The team had just gone through a reorganization and needed fresh perspectives.
When I arrived, the product had the basic flows working, but the history of how they were built said everything: each delivery was made against the clock, at the pace the Central Bank of Brazil required. The focus was regulatory compliance. The experience was a consequence, not a starting point.
The Problem
The discovery that opened our eyes
The first thing that needed to happen was understanding the problem for real. We ran a discovery with the team — an artisanal process of reading support tickets, talking to the support team, shadowing Pix-related support interactions. No AI to process the volume; it was manual work: read, categorize, identify patterns.
The results changed the conversation. Most tickets came from situations where the app simply didn't communicate what was happening. Errors that existed in the system never reached the user — or reached them in generic form, without context and without a way out. The customer didn't know what went wrong, didn't know what to do, and the only option was to contact us.
"The most surprising discovery was the most basic one: error handling and the hiding of important data on screens. They were being ignored. And fixing those points had the potential to eliminate a huge chunk of the tickets."
Disconnected flows
Each screen created at different moments, by different teams, with no navigation or language standard.
Invisible errors
Failure states that existed in the backend but never surfaced in the user interface.
No communication rulebook
No definition of when, how, or what to communicate to the customer.
Decentralized teams
Backend, frontend and design were not talking to each other about error states — only about whether the screen was right.
Constant regulatory pressure
The Central Bank can announce a change that needs to be in production within weeks, creating rushed deliveries.
Real money at stake
Pix is money. Any change — however small — has real consequences for the entrepreneur's daily business.
My Role
Productive tension between three perspectives
I was the Product Designer responsible for the entire Pix product — both the payment and receipt flows. I worked in co-creation with two PMs (at different points, I coordinated deliveries with two PMs and two scopes simultaneously), two tech leads, and two teams of developers.
The dynamic that worked: the PM pulled toward business, the tech lead pulled toward technical possibilities, and I pulled toward the customer experience. The tension between the three was productive — we arrived at the best possible output for that moment. When all three perspectives were on the table, deliveries came out more consistent.
Process
Error mapping — Payments flow
The QR Code and transfer payment flows were the most critical: highest volume, most visible, most support contacts. To map those errors, the approach was direct: talk with the backend and frontend teams simultaneously, at the same level. Ask for the list of all possible error states. Understand what the API returned for each case.
The conversation with the technical team was one of the most productive of the period: when you start asking the right questions — 'show me how it looks in the code', 'what's the payload that returns in this state?' — the relationship changes. Development stops being a deliverer and becomes a co-creator.
The result was a complete map of all error states in the QR Code flow, with design for each one. Errors that previously broke the experience silently gained a name, context, and next step.
Home redesign for the entrepreneur
When I joined the team, the Pix home was functional, but hadn't been designed with the entrepreneur in mind. It was a generic screen that put forward what was easiest to display, not what the customer most needed.
The home's evolution was deep information architecture work: what does the entrepreneur actually use? What do they need to see first? What was buried that should be at the top? The process involved customer research, usage metrics analysis in Amplitude, and conversations with the product team about Pix's value proposition for entrepreneurs.
API Down — the feature I'm most proud of
Born from a call where the problem was put on the table: what happens when the Pix infrastructure goes down? The customer who tries to make a transfer and can't doesn't receive any explanation. The app simply doesn't work.
From there, the team ran a complete process: impact-effort matrix with the whole team, leadership alignment, solution design, implementation. API Down is the feature that disables the Pix experience when the infrastructure is down and communicates to the user, clearly, that the problem isn't theirs — and what they can do in the meantime.
Stone was one of the first companies to have this feature. It has already saved the product in critical moments.
Regulatory deliveries under real pressure
Throughout the period, we delivered features required by the Central Bank: Pix Automático (equivalent to direct debit), Pix Agendado Recorrente, Contestação via self-service, and transactional limit adjustments. Each regulatory delivery was a race against the deadline imposed by the Central Bank — with no certainty of when the regulation would come, and no date flexibility.
The learning over time was fitting customer experience needs inside regulatory deliveries, not treating them as separate projects. This accelerated the cycle and ensured that each delivery reached the user with quality, even under pressure.
Results
The most revealing indicator
Over the two years in Pix, support call volume related to the product fell significantly and consistently. The most revealing indicator wasn't just the absolute drop: it was the elimination of spikes. Before, with each Central Bank regulatory change, call volume would rise sharply. With the work the team did over time, those changes started happening without a call spike — because the product communicated the changes clearly before the customer needed to call.
Qualitative feedback from customers arrived at specific moments — like when an accessibility feature was removed due to apparently low usage, and customers called asking for it back. That was one of the most important learnings of the period: usage metrics don't capture everything that matters to the customer.
"Support spikes on every regulatory change: eliminated. That's the metric that best captures what the team built together."
Reflections
What this case really shows
Resilience. The ability to absorb volume, regulatory pressure, decentralized teams, and multiple simultaneous scopes — and still deliver with documented quality.
What this case also shows is how alignment across engineering, PM and design changes the output. Not by consensus, but by productive tension: PM pulled toward business, tech lead toward technical feasibility, I pulled toward customer experience. When all three were in the same conversation, deliveries came out more consistent.
Several initiatives studied during the period didn't reach production — due to technical limitations, priority changes, compliance issues, or lack of time. That's part of the product cycle. What stayed in draft, in research, or in prototype was equally valuable for informing the decisions that did go live.