Etisalat Business · B2B self-service
Quick Pay & Recharge
A single-page redesign of a working but slow payment flow, built to make a "quick" payment actually feel quick.
Where I started
Quick Pay exists so business customers can pay and recharge in seconds without logging in or calling anyone. Every extra step works against the only reason the page exists: keeping payment volume fast, self-served, and off the call center.
Etisalat Business already had a Quick Pay & Recharge flow in production, covering bill payment and recharge, with batching built in. The trouble was simple: for a flow sold as a fast, no-login guest payment, it wasn't quick.
- It still required signing in, even though the page was positioned as a no-login guest payment.
- It ran page after page, moving users through accounts, confirm, contact, terms and payment as separate screens.
- It used styling that no longer matched the brand, so it felt dated next to the rest of the product.
The existing flow: a single account field to start, total at zero until a bill is entered.
The brief
The mandate from my manager was specific: audit the UX of the existing flow and update its components. Quick Pay & Recharge was a special case, with no dedicated components of its own, so a real part of the job was adapting our design system to fit it.
- Audit the UX of the live flow, end to end.
- Update the components, adapting the design system to a flow it was never built for, and bringing the dated styling back in line with the brand.
That was the ask. In parallel, I explored whether the flow itself could be revamped to genuinely save customers time, not just refreshed.
How I worked
Six steps, from understanding the live flow to iterating with the team. Tap any step to jump to it.
Audit
I mapped every screen and path, bill payment and recharge, each by single account, bulk upload or status check, and marked where the friction sat. One finding shaped everything after: Quick Pay had no components of its own, it was stitched together from generic ones, so any redesign also meant giving it a proper home in the design system.
Benchmark
Before redesigning, I tore down the no-login Quick Pay flow of seven telecom operators: e& as the baseline and six competitors, read against the same five dimensions, entry, pay-versus-recharge model, amount, payment methods and confirmation. The short version: e&'s batch payment is genuinely ahead, but the market wins on two things e& does not do, a true one-field start and auto-fetching the amount due. Both target the same moment, where a payer hesitates, mistypes the amount, or gives up and calls instead. That is where payments are won or lost.
The question, across seven operators: can you pay a bill without logging in, and how much friction stands in the way.
Ideation
With the two gaps named, I explored on paper: how few fields a payment really needs, where the amount could be fetched instead of typed, and how much of the journey could live in one place. The aim was never a prettier screen, it was fewer moments to stall, mistype, or give up and call.
Two versions
I deliberately designed two directions rather than one, so the product owner had a real choice instead of a single take-it-or-leave-it:
- Version one: same logic, new skin. The existing multi-step structure kept intact, but rebuilt on updated components and brought fully back in line with the brand. Low risk, close to the original mandate.
- Version two: the one-page concept. The whole journey collapsed onto a single page, type, method, accounts, contact, terms and payment in one place, each step confirming inline, a persistent order summary in view, and the batch-payment strength carried over. Higher ambition, bigger time saving.
Final design
The shipped flow, end to end: the existing logic rebuilt on refreshed components and realigned to the e& brand.
Enter accounts with no login: add up to ten, with the total tallying live.
Version two, the one-page concept. The walkthrough below puts the whole journey on a single screen. The more ambitious option, and the one that was not taken.
Present findings to the PO
I brought the whole story to the product owner in one readout: where our flow loses people, what the market does better, and the two versions side by side. Anchored on competitors and completed payments rather than taste, the conversation stayed concrete. The PO backed the one-page direction and asked me to take it further.
Iteration loop
From there it was a loop, not a handoff: I iterated against the PO and management on scope, and engineering on what was buildable. Their read was decisive: the full single-page model was more than the platform could deliver in six weeks. Better to surface that inside the loop than after committing.
Where it stands
The multi-page flow stays in production for now, and the one-page version is the direction I would push to ship next.
If I carried it forward, I would sequence the ambition rather than drop it: prove the consolidated confirm-and-pay step first, then fold in the rest.
The bet is straightforward: fewer steps and no forced login should raise the share of payments completed in self-service, which is exactly what a guest payment page is measured on.
A few decisions behind it
- Confirm inline, not at the end. Showing each step resolve as you go replaces the anxiety of a long form with a sense of progress.
- Keep what works. The existing batching was solid, so the redesign preserved it rather than reinventing it.
- Scope the vision to reality. When build complexity is the blocker, the answer is to sequence the work so it can ship, not to abandon the better experience.
This work was done at Etisalat Business. The screens under "Where I started" are the existing production flow; account numbers and figures are anonymized.
