
Experian2025–2026
Leading PFM at suite scope
Leading design across four inherited products — and building the team and culture to hold them together.
The scope
Four products, one small team
My scope expanded from Personal banking to Experian's full personal financial management (PFM) suite, called Money Hub: four products, each with its own PM and roadmap, and a Cash advances product already in development. It came with a restructure: a new VP of product took ownership of the UX organization and asked leads to take on more, including mentoring the designers on their teams.
None of the four started with us; I inherited them all. I owned Spending breakdown, co-owned Recurring bills and led the design of Personal banking, and the senior designer led Debt management.
Holding four products together was an organizational problem as much as a design one. There was no structure for it, across the suite or inside the team, so building one, without the authority to mandate it, became the job.

Owned by me
Spending breakdown
Where users' money goes across linked accounts, and how it shifts over time.

Co-owned
Recurring bills
Subscriptions and repeating charges, in a single monthly view.

Design led by me
Personal banking
Checking and savings, built in where users already manage their money.

Led by the senior designer
Debt management
Credit cards and loans, with tools for prioritizing payoff. Built with our partner Array.
The suite · Workflows
Where the features touch
The four products looked separate, but they rested on the same two pages: every feature's insights came from the transaction archive, and drill-downs ended in Transactions and then Account details. None of the four roadmaps covered those pages, so a change one team made there reached every feature built on them, unseen until it shipped. I mapped where the features touched, so every team could see what a change to those pages would reach, and made the case to PMs across the suite that the shared pages were worth investing in: foundation work against feature work.
Money Hub · Features
- Spending breakdown
- Recurring bills
- Personal banking
- Debt management
Every feature's insights read from the same archive
Shared pages
Every feature depended on these. None of their roadmaps covered them.
Transactions
Tap a transaction → its account's history
Account details
Debt management reads the same card and loan data directly.
Cash advancesSeparate offer, not built on spending data
The suite · The forum
One room, every roadmap
I established a recurring cross-suite design review: the PMs from every product, with the designers representing each one. Designers brought live work, the group critiqued it, and decisions that crossed product lines got made in the room rather than discovered after launch.
Setting up the review was the easy part. The harder work was the trust it took for designers and their PMs to bring unfinished work in front of their peers.
The review earned its place when the suite inherited Cash advances, a premium product already in development with our partner Brigit. I led its design. Once activated, it added a progress widget to Money Hub. Only one other team needed that space, so we negotiated the placement with them and brought it to the review so every team knew before launch. They agreed because only activated users, a small share of Money Hub's audience, would ever see it.

The suite · Ownership
Inherited, then owned
No feature in Money Hub belonged to one designer from start to finish. What I owned was their upkeep and how they evolved; these are the screens I was responsible for.

01 · Spending breakdown 
02 · Category detail 
03 · Recurring bills 
04 · Account details 
05 · Personal banking 
06 · Transfer
The team · Practices
Talent without scaffolding
When I took on the suite, the senior designer was doing strong work with no structured lead above her: no formal check-ins, no defined growth path, no one protecting her time from meeting pressure.
Designers are judged on their artifacts, but calendar pressure eats into the time to produce them — and a senior designer doesn't grow toward lead without lead-level decisions to make. Four practices gave her that structure.
- 01
Protected maker time
Blocked uninterrupted design time. Meetings deferred to specific windows. Artifacts — not attendance — became the measure of contribution.
- 02
Permission to decide
Made it safe for her to make lead-level calls on her own, without checking with me first. Over time, consulting me became her choice, not a required step.
- 03
Candid check-ins
Regular 1:1s structured around honesty rather than status updates. What's working, what's not, what needs to change.
- 04
Open critique
Work shared early, critiqued honestly, defended openly. Showing unfinished work was encouraged — the only way to get better faster.
When we added a junior designer, she joined into these practices instead of waiting for them to exist.
Growth of the team
The human outcome
The senior designer led the design of Debt management. My part was helping her streamline the work and make its calls with confidence. While we worked together, she was promoted to Expert — one level below Lead in Experian's design organization.
I won't claim the promotion was mine to give, but the environment we built together made it possible. That's the outcome I'm most proud of.
Debt management · Led by the senior designer
Senior designer growth arc
- Starting pointSenior DesignerStrong craft, no lead above her
- Under this structureExpanded ownershipThe practices, applied: lead-level calls, protected time, candid 1:1s
- Observable shiftIncreased confidenceMore decisive; owned Debt management's direction
- OutcomePromoted to Expert
Forward vision
What I'd do differently
“The cross-suite alignment we achieved was real — but it was achieved through influence, not structure. The next version needs both.”
That worked, but it's brittle. With formal authority, I'd make official what I had to advocate for: a named owner for cross-product workflows, with engineering counterparts, a cross-product design lead role, and a seat at the product strategy table before roadmaps are set — not after.


