Financial BPO: The Happy Path Is an Illusion
Em meio a alta complexidade e regras de negócio rígidas, o erro deixa de ser exceção e passa a ser regra.
In this project, the work didn't stop at the screen. I translated how a company's finances actually work for a team that had never worked with this before — except for me.
Timeline
Dec/2025 - Mar/2026
Role
Product Designer
Company
OpenCON
Interface
Web Plataform
Context
A Brazilian company spends an average of 1,500 hours a year just calculating, filing, and paying taxes. It's the country that spends the most time on this in the world — five times the global average. Meanwhile, the country issues around 37 new tax rules a day. One every forty minutes.
With the tax reform underway, this scenario gets even tighter. Between 2026 and 2033, companies will have to live with two tax systems at once — the old and the new — and tax credit now depends directly on a company's financial organization, not just its accounting. This is heating up a market that already existed but is now becoming a priority: financial BPO (business process outsourcing). Managing a company's finances is no longer an isolated task for the accountant — it now walks hand-in-hand with tax compliance.
Responsibilities
With a short deadline, top-down requirements arriving along the way, and dense technical rules that needed to be understood by the whole team — not just product — I worked strategically across every one of these fronts, alongside the Product Manager.
I was responsible for translating business rules into screens, structuring the product's ICP (ideal customer profile), leading tests, interviews, and documentation, making platform flow decisions, defining success metrics, and speaking directly with stakeholders.
Constraints
The deadline to launch the MVP was short. Along the way, new requirements kept coming in top-down, which required replanning without losing momentum. And there was a dense technical layer that needed to be understood not just by the product team, but by every developer involved.
Team
The team was small for the size of the challenge: one PM, one designer (me — who also ended up as the PM's business partner throughout the process), one senior frontend dev, one junior frontend dev, one senior backend dev, two mid-level backend devs, and a CTO following closely.
Problem
The project started in the negative
The platform had no structured BPO. The existing financial features were shallow and didn't cover what users needed, and that showed up clearly in the numbers. Nearly 40% of monthly active users had already opened at least one support ticket related to these features.
The work couldn't just be about designing a BPO from scratch. The entire financial structure of the platform had to be rethought alongside it.
Process
The illusion of the happy path
The more the team tested and analyzed the platform, the clearer it became that a financial BPO doesn't follow a linear flow. Direct client contact, bank account syncing via open finance, low client responsiveness in communication — all of this creates constant back-and-forth.
There is no single happy path. There are several. And each one needs to be mapped, because the cost of leaving one out isn't a poorly resolved visual detail — it's a real financial error, in someone's account.
That was the project's main mindset shift: stop designing around one ideal flow and start designing around every possible flow.
Initial research
We analyzed more than a dozen existing financial BPOs on the market, looking at structure, flow, and positioning for each. But almost none of it applied directly, because the audience OpenCON wanted to serve (Brazilian micro-entrepreneurs and small businesses under the simplified tax regime) is different from the audience most of these products serve. A big part of the work here was filtering out what made sense to adapt and discarding the rest.
In-depth research
We interviewed almost 30 people across 8 partner companies and clients, including accountants and finance professionals. The biggest challenge wasn't technical: neither the accountants nor OpenCON itself had clarity on who the target audience actually was. Before we could extract any workflow insight, we first had to lock down the ICP internally, and only then go back to interviews with a sharper filter.
Part of the initial interviews were done with people outside that ICP: accountants used for years to a different platform and to clients much bigger than OpenCON's, which biased the answers. We caught this early, avoiding bigger problems down the line. What helped reduce the bias was changing who we interviewed, prioritizing smaller accountants and finance-only professionals, without the weight of larger firms' rigid routines.
Prioritization and planning
We used MoSCoW to lock the MVP scope and draft the initial plan, defining what needed to exist, what could wait, and which business rules were non-negotiable. For the roadmap conversation with stakeholders, we re-presented that plan in a Now / Next / Later format.
There was no internal disagreement within the team about which features would make up the product — that was clear. The real tension was about what would go into the first version, and it was the stakeholders who felt that pain, not the team. We had to have a direct conversation with them, showing that handling everything at once wasn't viable and that some fronts needed to wait. It wasn't well received at first, but it changed once we showed the full reasoning behind the decision.
Ideation and testing
In interviews, accountants said the source of truth was whatever was entered into the system, since that's where their routine happened. But observing actual usage made it clear the real source of truth was something else: the bank statement. That's what reflects what actually happened in the period, not what was manually typed in. This difference seemed small on the surface, but it changed the reconciliation logic of the entire product — instead of treating manual entries as the reference and the bank as confirmation, we flipped the logic: the bank became the reference, and manual entries became what needed to match it.
Testing also showed that small clients and large clients use the BPO differently. A simple example: the frequency of logging transactions, which ranges from daily for smaller clients to weekly or even monthly for larger ones. That different rhythm meant the screen needed to support more than one way of using it, not just one.
Development
Design was adjusted side-by-side with engineering, as implementation revealed new technical and time constraints. Some cuts became clear early on — not because they were less important, but because they weren't non-negotiable for V1 to work.
Transaction history is the clearest example of this kind of decision. Testing had already shown it made a real difference, especially for clients who don't log transactions daily. Even so, we decided to leave it out of the MVP: it improved usability, but it wasn't what made the product functional. Given the deadline, shipping the essentials mattered more than shipping everything at once, even knowing we were postponing a validated insight. Open finance followed the same logic, launching in a simpler version, with its evolution already mapped for later phases.
Challenge
The work nobody saw on screen
The hardest part of the project never showed up on any screen. I was the only person on the team who had ever worked in finance before, so a big part of the job was translating for the team how a company's finances actually work, even before discussing any interface flow.
A concrete example of this was the difference between cash date and accrual (provisioning) date. The accounting flow works with one logic, finance with another, and mixing the two in reports would generate numbers that looked right on screen but didn't match the company's actual cash reality. Understanding and protecting that distinction from the start avoided a mess that would only surface months later, when it would be far more expensive to fix.
This translation work didn't end once the design was ready. At handoff, it became clear that part of the development team didn't have that same background, and explaining the flows once wasn't enough — the same concepts had to be revisited more than once before they made sense outside a financial context. That led me to create a handoff manual covering not just the screens, but the business rules behind them, so the team could build the flow on their own without depending on me for every question.
Results
What the numbers confirmed
Queda nos chamados relacionados ao financeiro.
In the first 90 days after the MVP launch, the share of monthly active users opening at least one ticket related to financial features dropped from 40% to 16%, tracked via ticket-opening events cross-referenced with user segment in Mixpanel. This drop directly validates the decision to map alternative paths instead of designing for a single flow.
Completion of the bank sync flow
Open finance syncing didn't exist before the project. In the first 90 days, only 28% of users who activated the BPO completed the bank connection funnel, measured via Mixpanel funnel tracking.
BPO adoption among the eligible audience
42% of eligible micro-entrepreneur and small-business users activated the financial BPO within the first 30 days of availability, tracked via the feature activation event in Mixpanel.
Learnings
The next barrier isn't technical
The bank sync funnel, with only 28% completion, exposed something research hadn't captured: end clients' fear of connecting their own account to the system. It's not a technical barrier — it's a trust barrier. Based on this, the product is revising the copy and onboarding for this step, along with educational material aimed at accountants, to make clear that syncing poses no risk to the end user and only increases the reliability of the data used in the BPO. It's the kind of result that doesn't close the case with a clean win, but pinpoints exactly where the next version needs to focus.
Other projects to check out
Tax Service · WhatsApp · 2026
EmitaZap: No screen is the best screen
Anticipating every scenario has never mattered more — after all, the entire experience depends on how each word is written.
Design System · Mobile/Desktop · 2026
Open Library: A system with no favorites
The challenge goes beyond just building a library — it's making it adapt to the visual identity of hundreds of different clients.
