Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm part of a team working for a client on a business iPhone app that has an optional 'passcode lock' feature.

One of the screens shows a list of saved items that may contain sensitive information. If the user enables and sets a passcode lock elsewhere in the app, they will be prompted to enter the passcode when navigating to the list screen.

Once the user has entered their passcode correctly, they would expect not to have to re-enter it until ... when? What actions should trigger the need to re-enter their passcode if they navigate to the list screen again?

  • (a) Navigating to a different screen in the app?
  • (b) Switching to a different app?
  • (c) Locking the phone screen (with or without a device-level passcode lock)?
  • (d) Force-quitting the app?
  • (e) Restarting the phone?

My guess is that most users would expect all of the above except (a), and that this would represent a good compromise between convenience and security. However, I wondered whether there were any best practice guidelines or research around this kind of situation?

Background Info
Users who don't use the app for sensitive information won't want to lock the app at all, so the feature needs to be optional.

Users who already have a device-level passcode lock on their phone may or may not want an additional lock on the app.

The in-app lock feature has been requested by the client to cater for occasional app users for whom the only sensitive data on their phone would be in this app. Whilst they may want to protect the information in the app, they may not want to have to enter a passcode each time they pick up the phone to make a call or use the phone's web browser, so a device-level passcode lock may not be appropriate for them.

share|improve this question

4 Answers 4

up vote 1 down vote accepted

I suggest to let user to choose from:

  1. No lock
  2. Lock the view after a timeout. A carefully chosen list of predefined inactivity periods (1/5/10 mins) should be enough.

    I use a password storing app which has something similar (lock code for some of the views) and it's quite useful to be able to switch between this app and another app to verify some sensitive info, so I set this timeout to 5 mins.

  3. Or to lock immediately.

    It should be triggered as soon as another screen of the app was activated, app was minimised or the phone was locked, i.e. as soon as this view will be hidden.

I believe these options will cover most of the cases your users will need.

share|improve this answer

I believe b) through e) should always require a passcode lock (if passcodes are enabled for this user).

On the lock screen, have a checkbox that says 'Don't ask me again for this session' which will ensure they can decide on the fly how secure they want to be until scenarios b through e arise. If they want to re-enable their passcode lock after saying 'don't ask me again', they could force scenario C) and lock the device screen.

share|improve this answer

Give the user two options:

  • Require passcode every time.
  • Require passcode after 5 minutes of last use.

From a usability perspective, this choice would let people decide what kind of environment they are in, and how secure they want their data to be.

share|improve this answer

Please do not forget about locking on timeout. In some cases it may be solved by locking the screen, but some users may have it set to Never, which could lead to security problems.

Regarding the situations you mentioned - locking the application upon switching to another view within it looks a little bit odd to me, but it may be something app-specific. Possibly needs re-thinking. In the same time, you should also lock on incoming calls and showing the notification center.

BTW, there is a very nice example to follow in Appstore, called Stash: https://itunes.apple.com/us/app/stash-free-private-photos/id411134267?mt=8

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.