1

We are building an app that is financial in nature and as per client requirement, there are certain actions that 'touch id or face id' is required to proceed. Therefore, users who are using phones that are not Touch ID-capable cannot do those functions.

My question is, when should we start informing the users that certain actions require Touch ID?

Also, should we even display to them those actions or do we just hide them if the app detects that their phone is not Touch ID-capable?

I see this as a double-edged sword though because on one hand, it's less frustrating for them to just don't see the action buttons if they aren't able to use them anyway. On the other hand, they wouldn't know that those functions actually exist, just that they're using a very old phone hence those functions are disabled for them.

How should I approach this?

  • 1
    I'll leave this as a comment: There's another significant percentage of users whose phone technically supports this technology, but they—for whatever reason—cannot use it (e.g. Touch ID sensor is broken, I've suffered severe injuries to my hands, I'm wearing gloves, my hands are wet/dirty, I don't trust Touch ID). These features would still show up for them, because the OS says it's supported, but the users won't be able to use it. Additionally, it goes against Apple guidelines. – maxathousand Dec 5 '17 at 21:25
2

It probably depends on how viable the app is without Touch-ID-only features.

  • Fully Viable Without Touch-ID
    If an "average user" can get "full satisfaction" from the app without even realising there are extra features that are Touch-ID-only, then you probably want to remove the clutter and only show the features they have access to.

    On first install you should probably tell them about the extra stuff available if they were to get a 'phone with Touch-ID; and you might have an item in the main menu (alongside things like Settings or About) that repeats the benefits of Touch-ID.

  • Usable Without Touch-ID (but not ideal)
    If the app can be used without the Touch-ID-only features, but means users have to carefully pick their way around, or can only do half the things they would normally like/expect to do, then it is probably best to show the Touch-ID-only features (with suitable UI/UX elements so users know why they can't access them).

The main reason for showing the disabled options in the second case and not the first is to manage user-satisfaction/-expectation. For a "fully viable" app, a non-Touch-ID user can be completely happy with what they do have access to; they won't necessarily be "missing" the extra features, and consequently won't think less of the app for not offering them.

However, if an app is only "usable" without Touch-ID, a user is likely to be frustrated if there are no options for many of the things they want to do. Showing a disabled option for these things won't wipe out this frustration, but it will at least let them know that it's not because the writer of the app never thought such an option was needed, but because their 'phone lacks the ability to use it (but see note below).

  • Not Usable Without Touch-ID
    If the app essentially cannot be used without Touch-ID then there's no point users even installing it. If the app-store lets you, mark the app as requiring Touch-ID so it shouldn't even show up as available to users of 'phones without that feature.

Final Note: Although you say it is "as per client requirement" that certain features are Touch-ID-only, if at all possible I would push-back against that. My online banking app used to not support Touch-ID: certain operations had to be confirmed by entering a PIN or other such "old-school" measures. The app now has Touch-ID support and lets you use that (if you wish) in place of the old methods.

However, on a 'phone without Touch-ID, those old methods are all still available: everything that can be done with Touch-ID can still be done without it. (Also handy on a modern 'phone if your finger and/or the sensor is dirty/wet and Touch-ID is not working).

0

If functions requiring biometric authentication, render application useless to the task or impair functionality, the user should know before using/accessing the application.

Here are some crude examples:

  • application requires Face ID to log in
  • an invoicing app requires Touch ID to authorise payment

In most cases when the hardware limits application functionality, the good practice will be, to notify the user and show affected functions as disabled.

0

Tell people in the app store, before they buy/download the app. Or, better yet, in the promotional materials people see before clicking through to the app store.

Even if it's free, I'd be pretty upset if I searched for the app, waited for it to download, launched it, created a user account (which is often a hassle on a phone UI), sync'd it with my financial accounts, etc., only to realize later, when trying to actually accomplish something, that I can't use it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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