Understanding a debt shouldn’t feel like an interrogation.
A self-service redesign for Fintrail, a credit portal operated as a joint venture — built from support-ticket evidence and user experience and usability research. Company name and identifying details have been changed under NDA.

The problem
People didn’t know if they owed money, who to pay, or why the number on screen kept changing.
Fintrail’s users weren’t confused about money in the abstract. They were confused about their own money — a debt tied to a partner company most had never directly interacted with. Sometimes the debt had already been paid, and they still couldn’t work out why it was on screen — flooding support with questions that should never have needed asking.
The portal showed numbers. It rarely showed why those numbers existed, what they meant, or what to do next. When a section didn’t apply to someone, it simply disappeared — with no explanation. Silence, in a financial product, reads as something being hidden.
"Apparently I have a lot of debt with UniBank. I can’t reach them or pay anything here. What do I do with this information?"
Support ticket, B2C segment
Trust broke down not because the debt was wrong, but because the experience gave people no way to verify it was right. This wasn’t a UI problem in isolation — it was a business blind spot: a B2C audience the company wasn’t built to serve well.
My role
What I owned, and who I owned it with.
Scope
Lead Product Designer, end to end — research, information architecture, UI, and rollout sequencing. Nine months from discovery to sustained rollout, working with a cross-functional pod spanning product, engineering, and support ops across Atlanta, Brazil, and the UK.
Complexity
This wasn’t simply a UI redesign — five forces pulled in different directions.
Every proposed fix touched a different constraint: users needed clarity, the business wanted lower support costs without a dedicated dev team, compliance required careful handling of debt and ID data, engineering had no funded squad yet, and legal needed any change to avoid violating existing partner agreements.

The design question was never “what’s the best screen?” It was “what’s the smallest change that respects all five constraints at once?”
Discovery
Cross-referencing support data with portal behaviour revealed where the journey broke down, not just that it did.
Counterintuitive insight
The lack of clear routing to the credit partner left users without direction whenever they had questions about payment or debt settlement. Debt and personal-ID information lacked the context users needed to understand what it actually referred to.
Grounded Theory codification on 5,000 support tickets — chatbot, forms, and phone transcripts — combined with a heuristic analysis across 100+ web and mobile screens, surfaced a clear hypothesis: the logged-out contact form invited overuse, and the UI silently hid sections instead of explaining why they didn’t apply.
The portal never explained what the debts were, why they appeared there, or what to do about them. Even positive information went unexplained. Users saw numbers describing their own credit situation with absolutely no clarity about what any of it meant — the interface explained nothing.

Design principles
Three principles turned discovery into direction.
Explain before you ask for action
People disputed debts they didn’t understand. Every call to action now earns a plain-language explanation first.
Make invisible logic visible
Sections that silently disappeared — like Credit Card, when a user had none — read as something being hidden. Hidden state became visible, explained state — even an empty section now says plainly that there is no information here, and why.
Route people, don’t just inform them
Information without a next step just produces another support ticket. Every screen now ends in a clear path forward.
Strategy
The interface became a consequence of how information was organised — not the other way around.
Before touching any screen, the flow needed a new information hierarchy: what a user sees first, what each page explains about the information that does and doesn’t exist, and what always has a visible next step — following a line of thought shaped by the context of each page and how people arrive at it.

Progressive disclosure replaced hidden logic: instead of removing sections silently, the new flow explains why something isn’t available and what to do instead. Before, only the credit score gauge lived on the home screen — everything else, documents, positive credit history, outstanding items, the PiggyOne partnership, was buried behind a menu the user had to actively search. After, the home screen surfaces all five sections at once, each with a visible next step, and the score itself comes with a plain-language explainer instead of a raw number.
Interface showcase
Three screens, three decisions.

Why this screen exists: It is the first thing a user sees on signing in. Before, the home was a single score — a number with no explanation. If a user had nothing on file, the screen was just that number, and empty space.
Design decision: Fill the home with useful content instead of a lone metric, so nobody has to work out how to reach the information they came for.
Trust reinforced: Users now understand what they are looking at, what the score actually means, and where it leads next.

Why this screen exists: It answers the single most common support question — “what is this, and why do I have it?”
Problem it solves: Debt information arrived without context, which drove repeat contact.
Design decision: Clear signposting on every entry: what the debt is, why it exists, and what to do with the information. If it needs paying, the screen routes the user to the joint venture that owns it.
Trust reinforced: Users can verify their situation, and act on it, without calling anyone.

Why this screen exists: Requesting a credit report used to be fully manual, on a three-day SLA, routed through calls or messaging apps.
Problem it solves: A document people needed in order to understand their own situation was gated behind human handoffs.
Design decision: Automated generation inside the portal: the user signs in, sees that the report is available, generates it instantly, reads what they need, and gets on with their day.
Trust reinforced: No contact, no ambiguity. And when something on the report does raise a question, the report itself makes clear which company to approach — our job is to produce the document, as well as it can possibly be produced.
Before / after
Comparing experiences, not UIs.
The goal wasn’t a prettier interface. It was a fundamentally clearer one — measured in clarity, confidence, navigation, emotional response, and decision support.

Outcomes
Three months after launch, support volume was still 69% lower — and the numbers moved well beyond tickets.
Business outcomes
69% reduction in support ticket volume (7.1k → 1.5k per month). $62k per month in average B2C support cost eliminated at the root. Still holding three months post-launch — not a launch-week spike.
Operational outcomes
Apdex improved 74% (0.6 → 0.81). Partner routing time down 74% (12.3s → 3.2s). Partner routing volume up 467% (203 → 1,184 sessions).
User outcomes
Users can now verify a debt without calling anyone. A dispute that used to require a phone call now takes three short steps. Credit report requests, previously 100% manual on a 3-day SLA, are now generated instantly inside the portal.


Reflection
Support data is underused UX research — and it now shapes how the company prioritises work.
This case became the starting point for a formal continuous-listening process between teams that were too far apart: engineering, product, design, and support. Design became not only the enabler that solved user pain points, but also a medium between areas.
What I’d do differently
The people closest to daily user friction — support agents — often hold research insight that never reaches design. Including them in discovery, not just end users, was what made this solution work for both the business and the user. If I ran this again, I’d formalise the support-data-to-design pipeline earlier, instead of treating it as a one-off research input.
"Financial products shouldn’t simply expose information. They should help people understand it."
Closing thought
Let's talk