I restructured how Credit Karma ranked, grouped, and explained personal-loan offers, replacing a flat list and one overloaded tile with an architecture that could carry new products, survive changing inventory, and make materially different financial risks legible to members.


Credit card debt or none. An existing loan or not. It made little difference. Everyone landed on the same static list of look-alike offers, ranked the same way, with the same oversized tile on top. Nothing reflected why someone was borrowing, or how a secured loan differed from an unsecured one.
Internally, the big tile had grown into a patchwork of versions, none of it really helping members choose. The marketplace was missing its revenue goals and was fragile enough that small changes tended to break something and cost real money, so the organization had become cautious about touching it, for good reason. I took it on because the core issue looked like one problem, not a hundred: there was no model for how offers got ranked, grouped, explained, or extended, so every new need became another exception.
The visible problem was a hard-to-read list. The real problem was a marketplace with no operating model.
And four definitions of success that had to coexist:
A structural redesign needed more than a persuasive concept. The marketplace had to keep running while we changed it, and leadership needed evidence that the thesis, more contextual and member-centered shopping, could improve the experience without destabilizing revenue. So I started with releases narrow enough to test it safely.
Those releases did two things. They generated revenue, and they proved relevance beat a one-size-fits-all marketplace. They also exposed the ceiling: 65% of marketplace visitors are shopping for their first personal loan, and that audience drives roughly 45% of revenue. Curating for one segment couldn't reach them. The marketplace itself had to change.
I reframed the marketplace from one flat list into a grouped shopping feed: meaningful shelves a member could orient around, compare within, and decide from, instead of scroll and bounce.
That is where the name comes from. Dynamic because the feed adjusts, every member sees a version curated to their segment. Grouped because the work was the feed structure itself, not a single screen. Built right, other teams could add their own slot on top, and data science could rank the whole set of offers together instead of one at a time.
Before, presentation and ranking were welded together and everything landed in one list. After, the feed became the layer that decides where an offer can appear, so a new placement is a rule, not a rebuild.


Round after round of testing. Card sorts to learn what actually mattered, co-design sessions with members, the layout, the tile, all of it. Monthly payment and APR sit where they do because members told me they mattered most, and the analytics agreed.
What I heard: members mostly wanted to do their due diligence and be sure we were not screwing them. So I pulled their best offers onto a shelf instead of making them dig, and compacted the weaker offers at the bottom, still reachable, just out of the way.
I surfaced the origination fee, and renamed it, because the old term confused almost everyone. It is just a lender fee you pay when you take the loan. On an average loan of around $12,000, that kind of clarity is the product. I made the secured-versus-unsecured distinction explicit for the same reason: a secured personal loan can put a member's vehicle on the line, and that shouldn't be something you discover late.
It wasn't free. Showing the fee, and a “cash to you” number lower than what members asked for, made offers look worse. Click-through on the new tile came in below control, and that was our leading read as to why.
We made the loan look worse because the loan was worse than it appeared. I'd make the same call again. But it was a trust argument, not a conversion argument.
Card sorts, co-design sessions, round after round. Members were in the room for nearly every decision.

Grouping only works if the structure underneath holds together. A few of the feed structures I sketched before the four shipped variants. Scroll and tap each phone, the notes call out the trade-offs.
Both tile types to break the monotony. Top offers, limited-time and CKG ride in a carousel, two at a time. The rest are accordion tiles.
Only the compact tile, with a bottom take-over. The feed is an accordion split by term and loan amount, up to five offers per group.
Accordion tiles grouped into top offers, limited-time, CKG, and other. Educational content between the groups.
Secured and unsecured split into their own sections, each with filters, plus a plain explainer of collateral. Closest to what shipped.
User testing pointed to the same set every time. So the featured carousel pulls a member's genuinely best offers, and an explainer sits under each one, because plenty of people did not know what these terms meant.
The variant carrying the featured shelf was consistently a weaker version of the variant without it, with the highest abandonment rate of anything we tested. Our best read: it added another section above the feed, so there was more to load and more to scroll past before reaching offers. On a page where load time drives abandonment, that outweighed the benefit of the curation.
The member insight held up. The delivery mechanism didn't. I'd test these as filters on the existing feed instead, so surfacing value doesn't tax the thing that was hurting us.
The tile had been attempted before and had proven hard to move, and it is easy to see why. It is not just design. It is engineering, member research, business development, and legal all at once, and every lender had to approve how their brand appeared on the new tile. Moving it meant driving that alignment myself, holding one design direction steady while a dozen stakeholders pulled on it, and getting each partner to yes without watering down the work.
I audited every tile variant in production first, the same component stretched across badges, superlatives, and banners with no consistent hierarchy, then rebuilt it as one flexible architecture that could serve top offers, promos, and curated placements without forking again. APR, monthly payment, term, fees, cash received, and approval context became the comparison core; promotional and partner content had to arrange itself around that core without displacing it.
The hardest disagreement was about showing less. We wanted fees and “cash to you” on every offer, but several lenders were sending the disbursed amount in the loan-amount field, so the same number meant different things by partner. I pushed to ship a deliberately thinner tile for those offers rather than a number we couldn't trust. An inconsistent feed is a usability cost. A confidently wrong number is a trust failure. The system's rules should say which one we accept.








One component, stretched across every promo and ranking need, with no consistent hierarchy. That was the case for rebuilding it as a single flexible tile.
Every screen opens the same on purpose. The differences live further down, so scroll each phone to watch the feed change from a flat list into grouped sections and a featured shelf.




Revenue was down four to five percent and clicks were soft. At the exposure we were running, that dip was worth over a million dollars a month, so the pressure to roll it back was the responsible instinct, not a timid one.
But the losses didn't behave like a design problem. They were uniform across variants that changed very different things, and they tracked load time, not layout. So I argued against the conclusion rather than for my design: we defined a new abandonment metric to catch members dropping during load, ramped down to cap the risk while engineering worked, and added a fifth variant with identical UI on the old serving API to separate ranking from design.
Once that noise was out of the read, Variant 3 came through above baseline and held. The win wasn't that I defended the work. It was that the team didn't make a seven-figure call on contaminated evidence.

When we looked into why Variant 3 won, most of the lift traced to one thing: splitting the feed pushed secured offers out of the default path. Secured loans put a member's car on the line, and we'd made that call for member-risk reasons: those products shouldn't get the same real estate just because they convert. It turned out to be the revenue decision too. Members who weren't being funneled toward collateralized debt converted better on the loans that actually fit them. The redesigned tile carried the rest, tighter and clearer, so more members read the offers.
The complication worth naming: the winning variant showed declining clicks and applications alongside strong conversion and revenue. Fewer clicks, better ones. Since clicks per user was our declared success metric, we had a variant that lost on the success metric and won on the guardrail, which forced a real conversation about whether we were measuring shopping activity or shopping outcomes.
This is the shipped design, rebuilt here as a faithful, interactive recreation, coded by me in Claude rather than Figma, the way I prototype every flow so engineering can see exactly how it should move and reprice. It went live to all members; the production surface keeps evolving as new tests run on top of it, so what's in market today reads close to this rather than frozen to it. Drag the loan amount to reprice offers, switch the featured shelf, filter, and open an offer. The notes on the side call out the decisions as you scroll.
Live and playable, right here. Drag the loan amount, switch the featured shelf, and open an offer.
Since DGM shipped to all members, personal loans became one of Credit Karma's top growth drivers, per Intuit's public earnings. It was never a one-time redesign. It became the foundation everything else builds on.
The revenue lift got the attention, but the durable win was the pattern underneath it: contextualization, building the experience around each member's own data and intent instead of a flat list everyone sees. Personal loans was where it was risky enough, and measurable enough, to prove.
Once it held up on the revenue engine, it stopped being a personal-loans decision and became a model other teams adopted. The same contextualization framework carried into credit cards, HELOC, and insurance, and became part of a cross-team initiative called Snipes. That is the leverage I optimize for: prove a pattern on the hardest surface, then hand it to the rest of the org so the work outlives the project and the team keeps compounding it after I have moved on.
This one never shipped. It is my own concept for where the marketplace goes next, built in a newer design system and coded the same way I prototype everything else. Everything above it is real work with real experiment data behind it. This is the argument for what comes after.
The shipped marketplace still asks members to shop. The next version should be willing to recommend, and then show its work. One offer chosen for the goal you actually have, with the reasoning visible: your blended APR on existing debt against the new rate, and the interest saved calculated in the open. A recommendation a member can audit is a recommendation they can trust.
Your context moves into sticky pills at the top, loan amount, purpose, income, housing, so changing your mind is one tap from anywhere on the page instead of a trip back to a form. And the rest of the market stays directly underneath in compact tiles that expand in place, because committing to a recommendation should never mean losing access to the alternatives. That was the lesson from the featured shelf: surface value without taxing the path to everything else.
Live and playable, and it goes deeper than the screen you land on. Change the loan amount or purpose and everything reprices. Sort and filter the market, or over-filter it to see the empty state. Open any offer for the full cost breakdown and an amortisation view, then take it through to the lender handoff. Sample data throughout.
Looking back, the decisions that mattered most were structural. A few things I would carry into the next problem like this:
What I'd do differently: instrument performance before ramping, not after. We couldn't tell a design problem from a load-time problem because we hadn't built the metric that distinguished them. That would have saved us a quarter.