The situation I walked into
IremboPay had just been launched to process payments for government services. But it had been built by engineers working from templates, with no designer involved. The interface was functional in the loosest sense. There was no design system, no prototype, no documented IA. When the product team wanted to propose a new feature, there was nothing to build the conversation around.
More significantly: the product's own mental model was limiting its growth. IremboPay only served merchants who had existing technical systems they could integrate with. If you were a small business, a school, a clinic, anyone without a developer on staff couldn't use IremboPay at all.
I joined as the first dedicated designer on the product. The mandate was to turn a backend utility into a product someone would choose.
The problem within 3 layers
The checkout experience was losing payers: The payment page had accumulated complexity over time. Multiple payment methods, unclear hierarchy, no trust signals, unfamiliar language. Payers, many of them encountering digital payments for the first time were dropping off. Session replay research later confirmed what we suspected: users would hit a wall on the main payment method and stop. Not because they didn't want to pay, not because they don't want options. Because the screen didn't make the next step obvious.
An entire merchant segment was invisible to us: The integration-only model meant IremboPay was structurally inaccessible to most private merchants. A merchant needed a developer, an existing system, and technical capacity to integrate before they could collect a single payment through us. Most small and medium businesses in Rwanda have none of those things. We were leaving an entire market segment on the table and nobody had named it yet.
Merchants had no visibility into their own business: Once a merchant was live, they had almost no data. No transaction summaries, no trend views, no way to understand their payment performance without downloading dense CSV reports.
The complaints were consistent: merchants were downloading full reports just to get a single total. The data existed, it just wasn't surfaced in any usable way.
Process
Payment Page Redesign
The funnel analysis data told a specific story. The drop-off wasn't about confusion with the payment method selection screen, it was about what happened after a payment failed. Users who hit a failure were retrying the same method over and over. Not because it was their only option. Because they didn't know the other options existed, or didn't trust that switching would work.
The redesign wasn't about simplifying choice. It was about making choice visible at the moment it mattered most, especially at the point of failure.
Three principles shaped it:
Surface options before the user needs them: payment methods presented with equal weight and clear differentiation, not buried below the primary option
Make failure a decision point, not a dead end: after a failed attempt, the screen actively surfaced alternative methods rather than defaulting back to retry
Add trust at the moment of commitment: full fee breakdown visible before confirmation, not after
Payment Link, naming a problem that existed but had no solution
The merchant segment gap wasn't something anyone had formally identified as a product problem. It emerged from conversations, sales telling us about leads they couldn't convert, support tickets from businesses asking how to get started without a developer.
We asked ourselves a product question: what would it take for a merchant with no technical setup to start collecting payments by end of day?
The answer was Payment Link, a no-code flow where a merchant creates an invoice directly in the IremboPay portal and shares a link. The payer opens the link, sees a clean checkout page, pays. No integration. No developer. No waiting.
The design challenge was making the merchant-side flow simple enough that a non-technical user could complete it in under two minutes on first use. We ran moderated testing with merchants who had never used IremboPay before. Everything that took longer than a moment of hesitation got simplified or cut.
Merchant Dashboard, answering the five questions
For the dashboard, I started with a different kind of research. Instead of asking merchants what they wanted, I asked: what are the top questions you download reports to answer?
- How much did I make?
- How much am I expecting from clients?
- How much did I spend while collecting?
- what is my net revenue?
Every dashboard element maps to one of those questions. Nothing else made the cut. The result wasn't a data room, it was a morning briefing. Merchants could open the dashboard, get their answers, and get on with their day.
Key design decisions
Plain language throughout: Every label, instruction, and error message was rewritten from scratch. Payment method names that users didn't recognise were replaced with the names they actually use day to day.
Logos at the point of choice. We added recognisable logos to each payment method rather than relying on text names alone. For users who are newer to digital payments, a logo they recognise from their phone or their wallet is faster to process than a label. Recognition beats reading.
Contextual "how to" at the moment of hesitation. A common drop-off point was payment methods users perceived as complicated, we added lightweight inline guidance, a few steps showing what it actually looked like. The goal was to shift the perception from "this might be hard" to "I can do this."
The dashboard has no "view all" trap: Many dashboards solve information overload by hiding things behind "view all" links. We didn't build any. If something needed a "view all" to be useful, it wasn't the right thing to surface at the top level. The constraint forced sharper decisions about what actually mattered.
Outcomes
Checkout redesign
The behaviour change was the real result. Before the redesign, 24% of users who hit a payment failure would retry the same method over and over before abandoning. After launch, that number dropped to 16% and something new appeared in the data, 10% of users who encountered a failure now switched to a different payment method and completed the transaction. That's a behaviour that didn't exist before. Users weren't switching because they were told to. They switched because the design finally showed them they could.
The downstream numbers reflect it: the three alternative payment methods grew by 258%, 118%, and 59% respectively in the months following launch, not because we promoted them, but because users discovered them through the redesign.
Payment Link
Opened an entirely new merchant segment; private merchants with no technical infrastructure. Within months of launch, new merchant onboarding included a material proportion of Payment Link clients who would previously have been turned away.
Merchant Dashboard
Report download complaints, previously a consistent support theme dropped after launch and all merchants in usability testing validated the design and were eager for it to go live
