Bill Reporting is a 0→1 product experience I designed at Kikoff to help users turn eligible recurring bills into credit-building progress. By driving measurable growth through iterations, the improvements increased signup conversion from 1.68% to 23.2%.

Background

What is Bill Reporting?

Many users already pay recurring bills, but those payments often do not contribute to their credit history. Bill Reporting created an opportunity to turn an existing behavior into a meaningful credit-building action. For Kikoff, it also opened up a new product surface within the Bills ecosystem—one with strong user value, growth potential, and room to scale.

What did I do?

I led the end-to-end product design for Bill Reporting, from shaping the initial MVP to iterating on the post-launch funnel. My work included defining the core onboarding experience, designing verification and edge cases, improving landing and re-engagement surfaces, and partnering closely with PM, engineering, data, and content to balance launch constraints with long-term scalability.

The challenge

A. Product challenge
We were designing a new product category, not just a flow.

B. User challenge
Users needed to quickly understand why this mattered and whether they could trust it.

C. Operational challenge
Real-world verification introduced friction.

Shipping the MVP

What the MVP needed to prove?

The first release had one goal: make Bill Reporting real and usable. Users needed to discover the feature, connect a valid bank account, confirm at least one eligible bill, and understand what would happen next.

Designing under real-world constraints

This MVP had to work within strict external requirements. We relied on Plaid-connected bank data, direct transaction detection, and TransUnion rules like name/address matching and limited bill categories.

Key MVP design decisions

Because Bill Reporting was a new product area, the first step was not to design the most comprehensive experience possible—it was to define an MVP that could bring the concept to market, make the value understandable, and give us a real baseline for learning. I focused on designing the minimum end-to-end journey needed for users to discover the feature, understand the benefit, and complete signup with enough confidence to move forward.

Why the MVP mattered

The value of v1 was not perfection—it was making the product real. By launching the first end-to-end Bill Reporting and core tradeline experience, we created a new credit-building surface inside Kikoff and established the foundation for future growth and iteration.

Streamlining the happy path

What the MVP taught us?

Launching v1 gave us our first real baseline for how users moved through Bill Reporting signup. While the MVP proved the concept, post-launch data showed that key parts of the journey—from plan expectations to bank connection to bill setup—still created too much friction.

Personalize the upsell

Not every user entered Bill Reporting with the same level of context. For users who had already connected Plaid through another Kikoff feature, I introduced a more personalized upsell with existing bill payments from Plaid that made the experience feel more immediate and actionable. For users who haven’t connected Plaid, I introduced a new copy which tied with their credit score.

Simplify the landing page and set expectations

The original landing page explained the feature, but it still asked users to do too much interpretation on their own. I redesigned it to front-load the most important signals—value, eligibility, and setup expectations—and to create a stronger sense of momentum by showing detected bill payments when available. Also by adding a “Premium & Ultimate” banner to increase the take rate and upgrade rate.

Make the Plaid connection more transparent

The Plaid connection step carried both functional and trust risk: users needed to connect the right account, understand why it was required, and feel comfortable granting access. I redesigned this moment to make account eligibility clearer, guide users toward the account most likely to contain their bill payments, and frame data access in a way that reduced hesitation without adding unnecessary complexity.

Compress bill setup into one instant step

This was the most structural change in the redesign. Rather than treating the 30+ setup and transaction-detection screens as fixed, I challenged the premise behind them. By partnering closely with PM to unpack the TransUnion requirements line by line, I found that the true requirement was much narrower: users only needed to confirm each tradeline they wanted Kikoff to report.

That gave me room to redesign the experience from the ground up. I replaced a fragmented 30+ page flow with a single confirmation surface where users could review auto-detected payments, make edits, add missing providers, and submit their reporting choices in one place. The result was not just a cleaner UI—it was a major product simplification that cut unnecessary steps while keeping the required user consent intact.

Designing for the messy moments

Simplifying the happy path improved the core signup journey, but Bill Reporting still depended on messy real-world inputs: bank data, provider matching, address verification, unsupported payment methods, even the long loading screen while pulling transactions. To make the product usable beyond the ideal flow, I also designed fallback paths that helped users recover, troubleshoot, and continue setup when automation fell short.

Recover when automatic detection fails

Because bill detection relied on live bank data and provider matching, failure was inevitable in some cases. Instead of ending the flow at “no transactions found,” I designed recovery paths that give users visibility of connected accounts, correct the provider, or get contextual help—turning a dead end into a decision point.

Address verification failed

Address verification wasn’t just a technical edge case—it was a compliance blocker. I designed this flow to explain the mismatch in plain language, show users exactly what data was conflicting, and give them clear next steps instead of a vague failure message.

Handle session timeout without losing users momentum

Because bill detection could outlast a single session, the experience needed to work across interruption—not just within a perfect linear flow. I designed a re-entry system that preserved user momentum: users could leave while detection was running, receive a clear signal once eligible bills were ready by homepage banner or email notification. User can return directly to finish setup without starting over. While users are waiting, we surface the 5-star review from App store to build trust.

Turning activation into deeper value

Once the Bill Reporting signup journey was in a much stronger place, I started looking beyond activation and asking how the product could create more value after setup. Back reporting became a natural next step: it made the credit-building benefit more immediate for users while opening up a meaningful new revenue opportunity for the business.

After introducing Back Reporting to Bill Reporting users, the feature drove strong enrollment, high upsell engagement, and significant incremental revenue.

Make the value concrete before asking users to pay

Back reporting was designed around three product principles:

Make the value concrete before asking users to pay
Ground the purchase in detected historical payments, so users could understand the benefit in terms of real payment history rather than abstract credit-building claims.

Introduce the upsell at a moment of high intent
Surface back reporting when users had enough context to understand its value—such as right after setup or within the dashboard—so it felt like a natural next step, not a disconnected paywall.

Design it as part of the product, not just a checkout flow
Extend the experience beyond purchase through confirmation, dashboard visibility, payment history, and follow-up communications, reinforcing that users were unlocking meaningful credit-building progress.

What this project taught me

Reflection

This project changed how I think about product design. Improving conversion wasn’t just about polishing individual screens—it required questioning underlying assumptions, understanding real constraints like compliance and data limitations, and reshaping the product around what actually mattered.

From collapsing a 30+ step setup into a single confirmation, to designing for messy real-world cases, to introducing back reporting as a growth lever, the work evolved from improving flows to defining how the product creates value over time. It pushed me to think beyond the happy path and consider how users experience the product across uncertainty, interruption, and long-term engagement.

It also reinforced that meaningful impact often comes from product decisions, not just interface improvements—whether that’s simplifying the system model, choosing when and where to surface value, or aligning user experience with business outcomes.

Looking ahead

Looking ahead, I see the next phase of this product in two parts: improving precision and improving flexibility. On the product side, there’s room to make bill detection and categorization more accurate, reducing the amount of manual intervention required from users. On the experience side, there’s an opportunity to make the value of reporting more legible by connecting reported payments more directly to visible credit-building progress.

For Back Reporting specifically, I’d be interested in exploring a more dynamic pricing model. Instead of a single flat fee, pricing could better reflect the amount of historical payment data available to report. This could create a stronger value-to-price fit, make the feature feel fairer across different user situations, and potentially increase adoption among users who may not be ready to pay the same amount for a smaller reporting opportunity.