Quickpay Case Study

Fintech | 2023 | Product Designer

Overview

For many Nigerian workers, the month ends before the salary does. With wages as low as ₦70,000 and food inflation at 16.87%, the gap is often filled by predatory loan apps that charge exorbitant fees and exploit the desperation they claim to solve. QuickPay was built as the ethical alternative — giving employees access to a portion of their earned wages before payday, without the debt trap.

I joined as the sole designer and took on a significant share of the product thinking, shaping both the employee mobile app and the employer web dashboard over a three month engagement. The users QuickPay was designed for weren't just financially stretched — many had never had access to financial education, and most existing tools weren't built with them in mind.

That shaped every decision. The home screen was designed to give employees their most critical information at a glance — wages accessed, salary remaining, days to payday — so the app felt reassuring rather than overwhelming. The learn feature, which I introduced as a product decision, went further. Rather than generic financial advice pitched at the wrong income level, it met users where they actually were — breaking down complex terms simply, surfacing articles relevant to their circumstances, and showing them how to improve their financial health score step by step. The goal was that even if a user eventually outgrew QuickPay, they'd leave in a better financial position than when they arrived.

Problem

Existing loan apps in Nigeria are often predatory, invasive, and exploit financial desperation. Workers need a safe, transparent way to borrow from their own income, not from lenders with exorbitant fees and unethical practices.

Constraints

The design constraint was simple to state and harder to hold: nothing in the app could mimic the patterns it was built against. No urgency theater. No fee labyrinths. No content pitched at a user with disposable income. No "engagement nudges" that translate to "borrow more than you need."

Predatory fintech patterns dominate the category precisely because they work in the short term. Designing against them meant designing against habits users had been trained to expect, against the reflexes of category competitors, and against the default patterns most fintech designers reach for first.

Role and collaboration

I joined as the sole designer on a three-month freelance engagement, with significant influence on product direction. I worked closely with Samuel (backend) and Emmanuel (frontend), translating constraints from payroll reality into screens both sides could ship within the timeline. The Learn feature was a product decision I proposed and pushed, rather than something on the spec when I arrived.

The three-month window kept scope ruthless. Every screen needed a reason to exist or it didn't make it in.

Key decisions

Home screen optimized for calm clarity, not feature density. The reflex in fintech is to load the dashboard with information: balances, transactions, charts, offers, nudges, badges. For users in financial stress, that density is part of the problem. The home screen ships three numbers (wages accessed, salary remaining, days to payday) and one primary action. Everything else lives one tap away. The tradeoff was feature visibility, since competitors look more capable on a screenshot. The outcome was an app that reads as stabilizing rather than as another complex finance product.

Introducing Learn as a first-class journey, not a marketing add-on. Earned-wage access without financial literacy can keep users in the same cycle, just with friendlier branding. Learn was designed to meet users at their actual income level: breaking down terms in plain language, surfacing articles tied to their circumstances, and connecting each lesson to a step in their financial health score. The tradeoff was a larger content surface to maintain. The rationale was that without literacy work, "ethical" access alone doesn't change anyone's trajectory.

Security as a confidence builder, not admin overhead. Fintech security usually shows up as friction: another password, another verification, another permission screen. For an employer dashboard, that friction can read as either professionalism or as suspicion. The 2FA and permission patterns were designed to read as protection, with copy that explained what the user was protecting and why. The tradeoff was a slightly longer setup flow. The outcome was a dashboard that reads as professional protection rather than bureaucratic overhead.

Reflection

If a fintech product can't explain itself in one calm glance, it becomes part of the anxiety it claims to solve. That principle ended up underneath every layout decision I made, and it's the one I'd carry to any product designed for users in financial stress.

Designing for users with limited financial literacy taught me that "accessible" isn't a checklist; it's a question of whether someone in distress can understand what they're seeing in the first five seconds. Learn became the most ambitious part of the work because it pushed past access into education, but it also raised the bar for everything else: if the rest of the app couldn't be understood without Learn explaining it, the rest of the app was failing.