Context
The platform that nobody wanted to use
Stone's mission is to democratize access to financial services for Brazilian SMEs. With over 1 million clients, the company needed internal tools that could serve every team — support, product, operations — without forcing people to context-switch between systems.
A first-generation admin platform had been built with pure technical priorities: consolidate tools, reduce infrastructure costs. The result was functional but unusable. Adoption was low, teams still used old platforms, and the customer relationship team — the primary users — rejected it entirely.
By March 2022, it was clear: you could have the right architecture and wrong experience. The question became: how do you rebuild not what's easy to build, but what users actually need?
The Problem
Why a technically sound solution failed in practice
Using the Double Diamond framework, we ran deep discovery: interviews with customer relationship analysts, shadowing their full workday, analyzing support tickets, and documenting how they actually worked. The pattern was clear within days — these were power users with complex, context-dependent workflows. The platform didn't speak their language.
We discovered three systemic problems. First, there was disparity between the admin platform and the customer app — information looked different depending on which tool you opened. Second, experience was fragmented: different areas used completely different patterns, styles, and interaction models. Third, and most painful: solving a single customer problem required jumping between multiple systems. A support agent might need to cross four screens just to answer one question.
"Analysts were performing infinite context-switches — alt-tabbing between systems. Each task jump added 20–30 seconds. When you multiply that across a thousand analysts, that's lost efficiency and lost customer satisfaction."
Platform disparity
Information presented differently between admin platform and customer-facing app, creating confusion and inconsistent decision-making.
Fragmented experience
Each area of the product used different patterns, styles, and interaction models — no coherent language.
Multi-system workflows
Single problems required switching between 3–4 different platforms to resolve.
Long learning curve
New analysts required extensive training; high cognitive load for every interaction.
Low adoption
Teams reverted to old platforms despite being told the new one was the standard.
High operational cost
Time spent navigating systems directly increased support cost per interaction.
My Role
Designer as translator between three worlds
I was the Product Designer responsible for the full admin platform redesign — from discovery through production. While I had access to a design leader for alignment on direction, I drove every phase independently: research planning, synthesis, IA decisions, design system strategy, prototype, and validation. The work required translating between three perspectives: business (consolidate tools, reduce cost), technology (scale architecture, enable new integrations), and human (analysts need to work fast and confidently).
The key insight came early: I had to spend as much time understanding analyst workflows as I did understanding design systems. I talked with analysts, documented exactly how they moved through a day, and mapped which information needed to be accessible when. That became the North Star — not 'support all 6–8 old tools,' but 'eliminate one context switch for every task.'
Collaboration was essential. We worked closely with the PM to balance feature requests against priority, with the customer relationship team to validate every assumption, and with engineering to understand what was technically feasible.
Process
Deep discovery — why did the first version fail?
We started with a CSD matrix: conversations with stakeholders and users to understand Certainties, Suspicions, and Doubts. This revealed the real gaps — it wasn't that the feature set was wrong, it was that nobody understood how to use it.
Then we went deeper. Interviews, shadowing, heuristic evaluation, data analysis on system usage. We discovered that analyst workflows were far more complex than imagined — they'd build mental maps of information, jump between systems to correlate data, and often work around limitations rather than report them.
"The key finding: analysts needed to see the customer's full context immediately — all at once. The old platform forced them to drill through levels to get that view."
Information architecture redesign — where does everything go?
With 6–8 tools being consolidated, we faced a puzzle: how do you organize this much functionality so it's neither cluttered nor buried? We ran remote card sorting with actual users, asking them to organize all the system's functions into logical groups.
The results surprised us. Analysts didn't think in terms of 'tool' — they thought in terms of 'customer journey.' The navigation should follow how analysts actually solve problems, not how the old systems were structured.
Design system strategy — unified language across products
Fragmentation was a major problem. We created a comprehensive design system with patterns specific to admin workflows — how to display error states in a busy environment, how to structure tables for fast scanning, how to highlight risk. These patterns were derived directly from what analysts needed.
Critically, we built patterns that referenced the customer app's design language. When an agent opened the admin platform, the visual and interaction language should feel familiar from the customer app — building confidence rather than confusion.
Validation through user testing — the HEART framework
We built high-fidelity prototypes in Figma and brought analysts in for structured usability testing. Using the HEART framework, we measured Happiness (did you feel secure making this decision?), Engagement (did you want to use it?), Adoption (did you understand what to do?), Retention (would you come back?), and Task Success (did you complete it?).
With a UMUX survey, we asked analysts directly: 'Did you feel more secure with the new design versus the old platforms?' On top of core task metrics, we also measured time-on-task reduction and error rates. The results were clear — the new design reduced document search time from 24 seconds to 16 seconds, and service order open time from 116 seconds to 46 seconds.
Results
The moment adoption flipped
After 6 months in use, 92.7% of analysts reported feeling more secure with the new platform than all previous systems. But the metric that mattered most was what happened next: teams voluntarily stopped using the old platforms. In May 2023, we discontinued them entirely. The new platform became the primary tool by choice, not mandate.
By consolidating workflows, reducing cognitive load, and aligning with the customer app's language, we cut operational costs per interaction significantly. The NPS score moved from 55 to 94 — a 39-point jump. More importantly, the platform became extensible. New products could be added without breaking the experience. Other internal teams started asking if they could use it. What started as a failed platform became Stone's standard for building internal tools.
"NPS from 55 to 94. That number captures what happens when you stop building for systems and start building for people."
Reflections
What this taught me about platform design
Technical correctness is not user correctness. A platform can have perfect architecture and still fail if it doesn't match how people think and work. The first version proved that. Understanding context — not features — is what makes the difference.
But deeper than that: this work showed me the power of centering human workflow in architecture decisions. When design and engineering aligned around 'how analysts actually work' instead of 'what's easiest to build,' everything got better — performance, adoption, cost, extensibility. The better experience wasn't a nice-to-have; it was the prerequisite for everything else.
The design system that emerged from this work became broader than expected. It codified lessons about building interfaces for high-volume, high-stakes work. Other teams adopted it. That's the real win — not just fixing one platform, but creating a reusable framework for others to build better tools.