Should you always confirm sign-out in a mobile app?

Question

Is this necessary as it's not a critical action but I see it in a few apps. If so, what are the reasons behind it?

Answer 1

Yes! You should always confirm sign-out in mobile apps.

Here's why:

1. Mobile is a personal device: When we mean personal - really personal.. others can have limited to no access to someone's mobile.

2. Account Safety: In order to keep user accounts safe, users generally opt for strong passwords and when you have more than 10 signed-in apps it becomes difficult to remember all passwords.

3. Security: If a user is signed-out by mistake, signing-in again might involve multiple steps (OTP, email confirmation etc) to get into the app again particularly when you don't remember your password.

4. Emergency of use: Mostly we use mobile apps when we need them (excluding games to some extent) such as; to perform a money transaction. Imagine a situation - you're buying something and at the same time you have to board a plane but you accidentally signed-out of Apple Pay and have to go through the tiring process of authentication again.

This happened to me recently -

I booked UBER with an intention of using PAYTM as payment method. I opened the app and because of slow internet connection in that area I tapped on the profile icon multiple times - suddenly PAYTM signed me out and asked to sign-in again. I didn't know the password of it - I chose forgot password option - PAYTM sent me an email - it took a lot of time for the email to arrive in my inbox (because of the slow internet) - then there was OTP too. Finally I gave up and paid hard cash.

Answer 2

Although the action can be "undone" (signing in again), sign in is not the most convenient process as you have to enter the email and password (considering you find out the correct password).

I guess in Mobile it is easy to tap somewhere by accident, the screen is smaller than a desktop and a tap can happen accidentally.

So combine the above arguments and you have a good reason to include a confirmation dialog for the sign out. I guess if the sign in is done easily through a Social Network or similar you might consider not concluding a confirmation.

Answer 3

It's to make the user "think twice" or to prevent mistake since sign-outs increase churn rate.

More information about confirmation messages can be seen here: http://www.uxdesignedge.com/2010/06/are-you-sure-how-to-write-effective-confirmations/

According to that article, the confirmation for sign-out can work on these scenarios:

1. Prevent the error
2. Provide feedback
3. Provide undo
4. Make results easy to change

Answer 4

You should really question why you are providing a sign-out feature to the User. Most of the time, the justifications are better served by better mechanisms.

Part of the consideration should cover:

A) Push-notifications and other authenticated experiences that are very beneficial to maintain a relationship to the app's business/org/purpose and the User. Logout done right should see push-notifications cease (room for advancements here, e.g. moving the device onto an unauthenticated set of tokens to continue "public messages" type push-notifications), so it typically hurts the business. If you provide logout so Users can take a break from your spam, UX is not important to you.

B) The unauthenticated state relies on surrounding features such as Forgotten Password, if they suck or are broken then you are forcing the User into a bad experience. They probably suck BTW. All of those interactions are points where your loser can lose interest in your product/business and abandon the whole thing - why invite that?

C) The cost to both the User and the business in terms of data usage (radio usage, time spent, cloud services costs) to re-download content upon re-authentication.

Typical (half-baked) justifications (or pain points) for providing a sign-out feature:

1. Because a User might lose their device.
2. Because a User might need to sell their device.
3. Because a User needs to share their device with someone.
4. Because IT Support need to be able to say "Did you try turning it off and on again?".
5. Because Bank XYZ's app has a logout feature.
6. Because there is no app in existence that doesn't provide a sign-out feature!
7. Need it to be compliant.
8. ?? (please comment if you think other popular justifications exist)

Better mechanisms to mitigate the risks associated with the above:

1. More than your app is at stake here, much more. If the OS provides remote tracking, remote wiping, or similar features those are the features to leverage. Logout in this scenario is an attempt for the user to pre-empt the theft or loss of their device - why not also help them pre-empt their device catching fire and providing them a fire-extinguisher to carry around too??

2. Factory reset. If the users doesn't factory reset the device before selling it, they just shared it with a stranger forever and should look at (1). User education is the right thing to do to mitigate against the risks of this scenario.

3. OK. That lacks a ton of detail. Are they sharing with someone who is overseas and the sharing is going to be for years? Is that the scenario we should prepare for here? That would be better treated as a sold device. Practically, sharing may be at worst handing your device to a stranger who needs to make a phone call, if you don't monitor that person closely while that is happening, well you probably need to refer to (1) because they ran away with your phone. Guest accounts, multi-accounts, and app-pinning in combination with screen lock on Android are better solutions for this. The best mitigation here is User education, similar to mitigating against Phishing attacks.

4. If you rely on a User self-unauthenticating to deal with problems/bugs, put more focus on architecting and implementing quality software before wasting time on UX forums. This is similar to (1), preparing for potential future situations with the wrong, archaic controls.

5. Bank XYZ's app is probably vulnerable to something, are you looking for parity there too? Bank's tend to be very slow moving in the uptake of new technology, partly due to the cost of security team engagements, it turns out that most banks weren't pioneers in the mobile app space and their security team will insist that the mobile app has a logout feature because the website has a logout feature. Also there is a much greater risk, I imagine, compared to your app/system and banks typically not only provide logout - they forcibly log you out when the short-lived session ends - they are timeboxing any open connection into your account to mitigate against the high risks (and mostly to save themselves losing money not the user).

6. E.g. both the Dialer app and Google Play app do not provide a means to sign-out. Google Design advocates even discussed this topic, questioned whether sign-out needs to always exist (unfortunately I can't cite that, I recall it was Nick Butcher).

7. Your hands may be tied, but I can assure you that the compliance mandate is ill-thought-out when it comes to mobile. PCI-DSS is, OWASP Top 10 upon which PCI-DSS relies is, and OWASP Mobile Top 10 is 10 years overdue. While we're at it, NN Group is extremely late to the game too.

When an option comes with many drawbacks and there are better options available, why spend time polishing the bad option? Sometimes by stepping back and rethinking the approach one can get out of a "local maximum" and go on to find the actual best solution.

Direct answer to the OP's Question: No. You ideally never have to. Don't make the sign-out button a CTA, make it the lowest priority action in the app, hidden behind menus in a way where one would have to intentionally seek it out to action it.