QR Payment UX Redesign

Where it started

QR payment is everywhere in Thailand. But next to Apple Pay it feels slow — and I'd felt that gap myself. In the UK, a double-click and Face ID could clear a transaction in a busy queue. Back in Bangkok, paying by QR meant opening an app, re-authenticating, hunting for the scan button, scanning, entering an amount, and confirming — sometimes twice — while people waited behind me.

That everyday frustration became the starting question: why does it feel slower, and can usability improvements meaningfully reduce friction without sacrificing the security and trust a financial app has to hold onto?

The constraint that changed the project

Early on, the obvious move was to chase Apple Pay's speed. Mapping both flows showed why that was the wrong goal.

Apple Pay is fast because it uses a hardware shortcut, minimises on-screen decisions, and never makes you navigate an app at all. Thai QR payment operates under fundamentally different constraints: it needs internet access, supports peer-to-peer transfers, lives across many separate banking apps, and is shaped by banking security regulation. These aren't UX failures — they're the product's actual conditions.

That distinction became the spine of the whole project. QR payment couldn't replicate Apple Pay's interaction model. But it could still be improved within its own constraints. Once I stopped comparing the two as equivalents, the real problem got much clearer.

What the journey maps revealed

I mapped the full QR payment flow across five major Thai banking apps — SCB Easy, KBank, BBL, TTB, and KTB — using as-is journey mapping, pain-point severity analysis, and heuristic evaluation against Nielsen's 10 principles. Mapping the decision tree made the problem structure concrete: the mandatory confirmation loops, the error paths that send users back several steps, the places where the flow branches and rejoins.

The finding was consistent across all five apps: most friction came from inconsistent implementation, not the core flow itself. Scan buttons buried in menus. Labels that said "Scan" instead of "Scan QR." Confirmation screens that added steps without adding trust. All of it fixable without touching the parts that regulation and security actually require.

Testing specific assumptions

I built a prototype to test whether targeted changes improved perceived ease — not to propose a full redesign. Three questions:

• Would a clearly labelled Scan QR button be easier to find?
• Would reducing confirmation taps improve the experience?
• Would visual guidance reduce scanning errors?

The wireframes stayed close to existing QR payment patterns — deliberately. In a financial context, familiarity is a feature. The goal wasn't a new interaction model; it was a cleaner version of the one people already knew.

What usability testing found

I ran think-aloud sessions with three internal participants using one realistic scenario: paying 100 baht at a busy food stall. What came back:

• All three found the labelled Scan QR button immediately — the labelling change worked
• Two of three were confused by a second confirmation screen before reaching the receipt
• Two of three didn't understand how to switch between accounts during the flow
• Two of three preferred a number pad over a free-text field for entering amounts

Three participants is a small sample — these are directional signals, not validated findings. But the pattern aligned with what the journey maps and heuristic evaluation had already surfaced, which gave the recommendations more weight than they'd have had from testing alone.

Reflection

The thing I'd do differently is test with real users paying their own money in actual queues. Lab conditions compress the pressure that makes slow payments feel slow. But as a self-directed internship study, the methodology was rigorous given the constraints.

What this project taught me that stayed: understanding a constraint is more valuable than working around it. The reframe from "why can't QR be like Apple Pay" to "what can QR realistically improve within its own conditions" was a research move, and it's the kind of thinking I want to keep doing.