Qatar Development Bank’s housing loan app served thousands of citizens navigating one of the most significant financial decisions of their lives. However, the app’s core service journeys - requesting milestone payments, managing repayments, and tracking loan progress - were impacted by high friction, weak information hierarchy, and limited status visibility, making essential tasks harder to complete with clarity and confidence.
This project was a ground-up redesign focused on three principles: visual clarity, process transparency, and bilingual accessibility. Every screen was rethought from the user's perspective - not the system's.
The existing housing loan app presented users with data-heavy screens that lacked clear visual hierarchy. Key actions were buried - making an already stressful financial process even more overwhelming.
Without formal user research sessions, discovery was grounded in three inputs: a structured audit of the existing app against established usability principles, conversations with QDB's internal product team about recurring user complaints, and a review of regional banking apps to benchmark how similar loan management flows were handled elsewhere. Three consistent themes emerged:
Each decision maps to a usability observation. Nothing changed arbitrarily.
Removed the decorative background in favour of a minimal white layout. Role selection simplified to a clear pill toggle.
Introduced personalised greeting and visual progress rings to make loan data feel human and scannable at a glance.
Rebuilt the milestone view with a clear progress bar and visual separation between completed and pending items.
Replaced the raw repayment table with a card-based schedule using colour and hierarchy to make payment status instantly clear.
Each decision grounded in what users needed, not what looked good on a spec sheet.
Every visual decision documented as a consistent, reusable system built to support both English (LTR) and Arabic (RTL) interfaces.
The disbursement and repayment flows are where users spend the most time - and where the old app failed hardest.
This project reinforced that in a financial context, reducing visual noise isn't just aesthetic - it directly reduces user anxiety and builds trust. Every removed element is a decision made on behalf of the user. The biggest shift wasn't in how the app looked, but in how confidently users could move through it.
Corporate clients accepting a QDB financing offer must submit a specific set of compliance and legal documents before funds can move - a process that previously ran entirely offline, through email and phone coordination with a Relationship Manager. This project digitized offer acceptance and document lodgement into a structured, trackable flow: from reviewing offer terms, to seeing exactly which documents this specific offer requires, to submission and multi-stage review.
This walkthrough follows a real submission pattern from the file - Offer Letter DL9997, term sheet TS-2025-04421 - through acceptance, document lodgement, and multi-stage review.
It's a conditional approval. The gap between acceptance and funding is closed by document submission, reviewed sequentially by a Relationship Manager, a Relationship Officer, and Credit Administration. Before this system existed, that gap was managed manually: no standard checklist per offer type, no visibility into submission status, and every correction cycle adding days through email back-and-forth. For a business waiting on approved financing, that delay has a direct cost.
Every document requested is scoped to the specific offer: named guarantors, specific pledge conditions, the exact facility being financed. Six categories make up a typical submission.
A single document submission moves through three sequential reviewers - Relationship Manager, Relationship Officer, and Credit Administration - each capable of independently returning it for correction. The client-facing design had to represent that pipeline honestly, not simplify it down to a single "submitted → approved" illusion.
This flow didn't replace an existing portal - it replaced an offline process. Document requirements were previously communicated through email and phone conversations with a Relationship Manager, with no standardized checklist, no shared visibility into status, and every correction cycle adding days.
This isn't a screen recording. It's a working simulation of the real flow. Let it run on its own, or click Accept, upload a document, and hit Submit yourself.
Insurance
Get support
Documents
Document upload functionality will be available after accepting the offer.
Activity will be available after completing the document upload process.
Status vocabulary, the hero checklist, the upload itself, transparency, and how a returned submission gets handled.
Each decision responds to a specific mechanic of how offer acceptance and document review actually work at QDB.
Formal usability testing wasn't run for this flow. Validation came from working directly against the real RM → RO → CAD review mechanics with QDB's product team, and from the specific compliance requirements each offer carries, rather than assuming a generic document-upload pattern would hold up.
In B2B financial workflows, the small moments - a warning before an irreversible action, a comments field carrying a reviewer's exact instructions - carry real weight. Digitizing this process didn't just add convenience; it added a structure and audit trail that didn't exist before, closing the gap between an approved offer and a client actually receiving their financing.
Corporate clients regularly need to pay several beneficiaries in one sitting - suppliers, partners, payroll-adjacent transfers. The existing fund transfer flow only supported one payment per journey: fill in the details, review a summary, verify with an OTP, get a confirmation - then start over for the next beneficiary. For a Maker paying five suppliers, that meant five full journeys and five separate OTP codes.
This project turned that single-transfer flow into a batch one: add several transfers in one sitting, review them together, verify once, and submit once - then track the whole batch through a Maker → Checker → Approver review pipeline.
None of the individual steps in the original flow were wrong on their own - the form was clear, the OTP step was fast, the confirmation was reassuring. The problem was multiplication. A business paying multiple beneficiaries had to absorb that friction once per payment, with no way to see the set of payments as a single unit of work. That's real cost for a Maker with a batch of invoices to clear, and it made the portal feel like it was designed around a single consumer transfer, not how a business actually pays people.
The fix lives entirely in the first step. Transfer Details stopped being a single form and became a running list: complete one transfer, and it collapses into a compact, numbered card - beneficiary, amount, bank, with edit and delete icons - while the same form stays open right below it for the next one. A Maker keeps adding until the batch is actually done, not until the system decides they're finished.
A submitted batch moves through the same governance structure as any corporate payment at QDB - a Maker who creates it, a Checker who validates it, and an Approver who gives final sign-off. Either reviewer can return an item for correction, and the Maker's fix-and-resubmit path had to be treated as a normal part of the flow, not an edge case.
The underlying transfer form barely changed. What changed is what happens around it - how many times a Maker has to go through it, and what the system remembers between one payment and the next.
Two working simulations, not screen recordings. Build a batch and submit it as the Maker, then switch roles and review it as the Checker - including returning one with a reason.
InsuranceGet support
Fund transfer
InsuranceGet support
Payment SolutionsThe repeater, the single verification, the reviewer queues, and how a returned batch gets corrected.
Each decision responds to a specific cost of the original one-at-a-time flow.
Formal usability testing wasn't run for this flow. Validation came from working directly against QDB's existing maker-checker-approver mechanics and the real fields a fund transfer requires, rather than assuming a single-transfer pattern would simply scale by repetition.
The instinct when a form needs to handle more volume is to add fields or steps. Here the fix was almost the opposite: keep the form exactly as it was, and change how many times a Maker has to walk through it. Batching didn't remove any of the governance - Checker and Approver still review every transfer - it just stopped charging the Maker for each one individually. The friction that mattered was repetition, not the form itself.
My background in Graphic Design, Creative Direction, and Digital Art Direction - shapes how I approach UX/UI today - bringing together visual craft, product thinking, and strategic perspective.
I'm a UX/UI Designer with a background in Graphic Design, Senior Creative Direction, and Digital Art Direction - a progression that shapes everything I do. I bring visual craft and product rigour to the same table, which means I think about hierarchy, emotion, and system logic all at once.
Currently a UX/UI designer at Qatar Development Bank, where I work on mobile banking and trade finance products serving citizens and businesses across Qatar.
