You may be of the opinion that you don’t need to think about how people will log into your app, but it turns out… you do.
I wasn’t going to do a video on this, but I’m in Starbucks, I’m tired, I haven’t slept, I don’t want to be here, and I’ve just wasted five minutes of my life having to log back into the Starbucks app.
There are certain types of apps where the login experience is particularly important, ironically because the risk of abandoning is LOW, not HIGH. We all want customers to be able to log in to our solutions, but LOW abandonment means HIGH frustration because the user will keep fighting a bad login solution.
Consider for example parking at the train station and not being able to get into your Apcoa, Ringgo, or whichever bazillionth parking app you need to use. You are already running late, and now you can’t pay for the parking. You are going to go through that process no matter how angry is makes you.
Similarly, if I know I have a Nando’s Red reward and some free chicken behind a paywall, you better believe I’m going to see them put the chairs on the table and start Hoovering the floow before I’m giving that up.
For context, we’ve been logging in for nearly 30 years. Windows 95 is 30 years old in 2025, and that’s regarded as being the thing that kicked off the internet revolution. You can’t have an internet revolution without authentication, yet we’re still doing it wrong despite the fact there are only two activity flows we have to consider – a) logging in, and b) resetting a password.
A big part of the issue is that developers don’t put themselves in context when using these solutions. Software is built in comfy offices and chairs – but it’s used in hospital wards, or car parks in the pouring rain, or with the kids screaming, or when you don’t have your glasses and can’t see the screen properly. It was always ever thus about developers though – we’re always working in a bubble.
The problem I had this morning was that Starbucks had updated their app, and as part of that process they had junked my cached login and I had to sign in again. This is an unforgivable crime in user experience. The user is right to think that whatever you have going on in your backend is your problem – you need to “grandfather” in any old sessions, unless you have a very solid cybersecurity hygiene reason not to do so. Any updates should be transparent.
Secondly, users are supposed to using password managers, and there’s a solid chance (like me) that I have a password manager on my desktop, but not on my phone. As such the whole principle of passwords on mobile apps is broken. The correct way to log in on a mobile app is to use a magic link, and seeing as the user is probably on a phone, a magic link over SMS is better.
Anyway, if I do have to reset my password (which I will do, because I’m not going to get out my laptop to find my old password in the pouring rain in St Albans’ station at 5am), two things – a) hiding passwords (masking with the little dots) is pointless theatre, and b) if you give me the option to show my password as I type it DO NOT ASK ME TO DO IT TWICE. I can read it, I can see it there.
Once I have reset my password – and this one has forever blown my mind – don’t ask me to log in again! I’ve already given you the password, almost certainly twice, I do not need to give it you a third time. If I’ve proven myself by being able to access a reset link, there is no need to get me to log in after a reset.
If you do insist on sending a one time code over SMS – which is cool – make sure you read that code from my messages, don’t make me have to go and find my glasses to
Finally, if you’re on a phone, give me biometrics. Let’s me just kerthunk in my credentials and obviate the whole problem.
That’s it – that’s today’s rant dressed up as a lesson in user experience.