Making everyday payments feel effortless

Designing a clearer, more reassuring way to pay bills in the Naranja X mobile app.

Product Design

Fintech

UX Strategy

Making everyday payments feel effortless

Designing a clearer, more reassuring way to pay bills in the Naranja X mobile app.

Product Design

Fintech

UX Strategy

Spoiler

People needed a clearer, more reassuring way to pay bills digitally. I led product design from discovery to launch, testing and refining scan and search journeys, customer-number guidance, and error recovery. In the first eight days, customers paid 2,610 bills through the app.

Spoiler

People needed a clearer, more reassuring way to pay bills digitally. I led product design from discovery to launch, testing and refining scan and search journeys, customer-number guidance, and error recovery. In the first eight days, customers paid 2,610 bills through the app.

Spoiler

People needed a clearer, more reassuring way to pay bills digitally. I led product design from discovery to launch, testing and refining scan and search journeys, customer-number guidance, and error recovery. In the first eight days, customers paid 2,610 bills through the app.

2,610

Bills paid in the first 8 days

ARS 12.3M

Payment volume at launch

2,610

Bills paid in the first 8 days

ARS 12.3M

Payment volume at launch

Problem

In Argentina, most people paid their bills and taxes in cash at Rapipago or Pago Fácil, and a smaller group used their bank's homebanking. When the pandemic closed or limited those counters, many had to pay digitally for the first time.

That's where it got hard. First, finding the right provider in a long list of similar names. Then, finding the bill itself, which arrives on paper by mail for some services and by email for others. Finally, finding the exact number each one asks for, which changes by provider: a customer number, an account number, a payment code. And after all that, trusting the payment actually went through.

Problem

In Argentina, most people paid their bills and taxes in cash at Rapipago or Pago Fácil, and a smaller group used their bank's homebanking. When the pandemic closed or limited those counters, many had to pay digitally for the first time.

That's where it got hard. First, finding the right provider in a long list of similar names. Then, finding the bill itself, which arrives on paper by mail for some services and by email for others. Finally, finding the exact number each one asks for, which changes by provider: a customer number, an account number, a payment code. And after all that, trusting the payment actually went through.

Problem

In Argentina, most people paid their bills and taxes in cash at Rapipago or Pago Fácil, and a smaller group used their bank's homebanking. When the pandemic closed or limited those counters, many had to pay digitally for the first time.

That's where it got hard. First, finding the right provider in a long list of similar names. Then, finding the bill itself, which arrives on paper by mail for some services and by email for others. Finally, finding the exact number each one asks for, which changes by provider: a customer number, an account number, a payment code. And after all that, trusting the payment actually went through.

My Role

I led product design from discovery to launch, partnering with a product manager, UX researcher, and iOS and Android engineers. Over a nine-week delivery cycle, I owned journey mapping, interaction design, prototyping, usability testing, error states, and developer handoff.

My Role

I led product design from discovery to launch, partnering with a product manager, UX researcher, and iOS and Android engineers. Over a nine-week delivery cycle, I owned journey mapping, interaction design, prototyping, usability testing, error states, and developer handoff.

My Role

I led product design from discovery to launch, partnering with a product manager, UX researcher, and iOS and Android engineers. Over a nine-week delivery cycle, I owned journey mapping, interaction design, prototyping, usability testing, error states, and developer handoff.

Process

The project started with desk research and a competitive review of how people in Argentina paid their bills. From there, we mapped the user journey around the main pain points, sketched ideas with the team, and turned them into wireframes for the core flows. Testing, handoff, and launch measurement followed, as the timeline below shows.

From discovery to delivery: research, prototypes, validation, and launch measurement.

Design and user testing

Naranja X already had a mature design system, so I prototyped in Figma with real components and skipped low-fidelity testing. With the UX research team, we ran moderated sessions in Lookback. What we found:

  • The customer number was the hardest thing to find on the bill

  • Keeping track of due dates across several bills was hard

  • People left the payment flow to check their balance

  • They expected a warning before paying without enough balance

  • The email receipt worked as proof of payment and built trust

That shaped the product: a scan flow that mirrors paying at the counter, a helper that shows where the number sits on each bill, the balance visible throughout, and an email receipt after every payment. Saved services and reminders moved to the next version.

Screens shown during testing

Handoff and launch readiness

I handed off to the iOS and Android teams with specs for every state, including each error and edge case. New components were built on the existing design system and reviewed with the team that maintained it. Before launch, we set up tracking in Amplitude with the analytics team: bills paid, conversion by entry point, errors by type, and first-time vs. returning payers. Tracking every error from day one is what later revealed the biggest problem.

Solution

The final experience offers two clear entry points: scan a barcode or search for a provider. A contextual guide helps people find their customer number, while a review step makes the amount and available balance explicit. Every failure state explains what happened and gives the customer a useful next step.

Solution

The final experience offers two clear entry points: scan a barcode or search for a provider. A contextual guide helps people find their customer number, while a review step makes the amount and available balance explicit. Every failure state explains what happened and gives the customer a useful next step.

Solution

The final experience offers two clear entry points: scan a barcode or search for a provider. A contextual guide helps people find their customer number, while a review step makes the amount and available balance explicit. Every failure state explains what happened and gives the customer a useful next step.

Two ways in: scan the barcode on the bill or search for the provider by name.

The "Where do I find it?" helper shows where the customer number sits on each provider's bill.

A review step shows the amount, due date, and available balance before paying.

Version two: "Your service is up to date" replaced the "no debt" error, and saved services and payment history were added.

Every error gets its own screen, message, and next step, from expired bills to insufficient funds.

Outcome

On the busiest day, 719 of 731 people paying a bill were doing it in the app for the first time. The data also showed where the flow failed: search drove about 70% of payments, but only 14% of people who started a search completed one. The scanner converted 36%.

The most common error was "no debt," shown about 2,300 times in the first week, close to the number of successful payments. The same screen covered both a mistyped code and an account with nothing due, so people couldn't tell whether they had made a mistake.

About three months after launch, we shipped a second version. "No debt" became "Your service is up to date" with the last payment, separate from a wrong code, and we added payment history and saved services. The lesson: error states are product, not polish.

Outcome

On the busiest day, 719 of 731 people paying a bill were doing it in the app for the first time. The data also showed where the flow failed: search drove about 70% of payments, but only 14% of people who started a search completed one. The scanner converted 36%.

The most common error was "no debt," shown about 2,300 times in the first week, close to the number of successful payments. The same screen covered both a mistyped code and an account with nothing due, so people couldn't tell whether they had made a mistake.

About three months after launch, we shipped a second version. "No debt" became "Your service is up to date" with the last payment, separate from a wrong code, and we added payment history and saved services. The lesson: error states are product, not polish.

Outcome

On the busiest day, 719 of 731 people paying a bill were doing it in the app for the first time. The data also showed where the flow failed: search drove about 70% of payments, but only 14% of people who started a search completed one. The scanner converted 36%.

The most common error was "no debt," shown about 2,300 times in the first week, close to the number of successful payments. The same screen covered both a mistyped code and an account with nothing due, so people couldn't tell whether they had made a mistake.

About three months after launch, we shipped a second version. "No debt" became "Your service is up to date" with the last payment, separate from a wrong code, and we added payment history and saved services. The lesson: error states are product, not polish.

Process

Process

Google Play ↗

App stpre ↗

Naranja X website ↗

Back

Next project