When you create a QR code which contains a URL, it is vital that the code is not only as small as possible, but also as user friendly as possible.
I’m not a massive fan of short URL services like bit.ly – but for shrinking the text you want to fit in a QR code, they are invaluable.
I want to take a look at a particularly interesting example from Nat West Bank.
Despite having the QR too close to the ground (more of that in a later blog post) this seems like quite a good campaign.
The QR code is large and clear, it’s not too dense, and the copy shows the app is available on Android, iOS, and BlackBerry. A single scan on any device should redirect the user to the correct destination.
This is where things start to fall apart.
I know some of the guys behind ScanBuy. It’s a good service, but I don’t think it’s suited to this usage.
- No “https”. Users are being trained not to trust banking URLs unless they go via SSL. I wonder if people will notice on QR codes?
- It’s not a Nat West domain. How does a user know that this goes to the real app and not some mobile-malware?
- Nonsensical path. At the very least, ScanBuy should let this be customised to scn.by/NatWestApp or similar. That way, people looking through their history will know what the URL is meant to go to. (See scanning while underground).
That said, the code does successfully redirect users to the correct app store to download the app.
What I Would Do
I would use a url like
It’s the same length as the previous, is human readable, and is secure. If Nat West can’t run the redirection and analytics service themselves, it could easily redirect to ScanBuy to do the heavy lifting.
One thing to say, if a non-compatible device scans the code, they get taken to Nat West’s mobile friendly site.