User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I am currently working on an app. This app has some features that the user can unlock by entering a numeric code. I was considering putting an automatic validation as soon as the user types the last number of the code.
I see this pattern more and more but I was wondering if validating without having an explicit input by the user, for example by clicking on a continue button, has some usability/user experience related problems.
The main issue for me is not whether or not the validation can be done automatically but that the user has explicit control over the action the interface is offering. Users should have explicit control over the interactions the application offers to them. If they don't have explicit control they may find themselves unsure of what the application did and what triggered it. Sometimes they may not know exactly when something happened because they may have looked away from the screen.
You haven't shared the interface but the action in the interface is something like continue or unlock. The validation of the code is an internal process that your app needs to do before giving the user access but it's not something the user expects to be in control of. So I think the actual UX question here is whether or not the feature should be unlocked without the user's control.
However, control doesn't require explicit confirmation. Some interfaces allow the user to have control without giving them a confirmation action. For example, passcode entry on iOS doesn't give the user a confirmation button but the fixed length input and real time progress indication lets the user remain in control. In this case, the absence of the confirmation button lets the user know that entering the passcode is all they need to do to satisfy the unlock action.
Since an automatic validation is possible I assume that you are using a fixed length code. In that case the iOS passcode interface is one you can emulate.
The problem is that the user might enter the wrong number and then they get a validation error before they’ve had time to fix it.
Here’s a whole bunch of reasons why validating as the user types is problematic: https://adamsilver.io/articles/live-validation-is-problematic/
While I agree with Adam Silver's comments in principle, there are ways to optimize live validations for some(!) situations that work just fine.
For example, when unlocking your phone with a numeric passcode, chances are that the device will validate the code as soon as you've entered the final digit.
For more traditional form validation, displaying a checklist with the field's requirements, which is updated in real-time, provides a very user-friendly approach:
(Please do make sure, though, that the differences between the checked vs. not-checked appearances are easier to see than what Apple does here! sigh)
In your particular case, your question implies that the length of the code always is the same, so you have a well-defined trigger for the validation.
A design that I'd play around with, is displaying a gray — think, "neutral" — icon next to the input field, maybe just a gray circle. Once the user has entered the entire code, replace it with a green checkmark or red "x" in a circle (similar to Apple's icons above) to indidate whether the code is valid, or not.
To help the user avoid mistakes, give 'em a helping by including hint text:
Your code will look like this: 123-456-789
Also, make sure that you validate in a way that's human-friendly. E.g., if your code contains letters, but only upper-case ones, don't punish your users if they enter lower-case characters, instead.
P.S.: As so often, ;) Nielsen Norman Group has a detailed article on the topic with some great advice: How to Report Errors in Forms: 10 Design Guidelines.
If you can do it fast and securely, then it is nice to have the feedback as you type, rather than clicking the button. (Note: your app should probably also re-validate on button click too anyway.)
What does fast mean:
It means it happens almost instantaneously. The logic for it should not rely on any time-consuming process, such as querying a web service, etc. The user needs the feedback straight away, if it takes a second or more - wait until the button click to handle it.
What does securely mean:
Well, can the user abuse the feature by quickly trying lots of different codes? Maybe even automated? This isn't really a UX concern, but certainly a consideration for your application design.
Bottom line: It's good to give instant feedback, as long as you don't slow the process down.
Additional information:
Sometimes the decision is a technical one, rather than about the UX.
Take a credit card input field for example. Often the user will get the impression that the card number is validated once they type the last digit. This is only partially true. What happens here is that the card is validated in format alone (i.e. there is only a certain subset of valid starting digits, and also you can run a checksum on the number too). The benefit here is you don't waste server processing on a card number that has no chance of being valid.
Once you submit the form, then the actual data is processed server-side and fully validate.
It all depends on what you're validating and what feedback you give.
Live (or inline) validation can be very helpful if done right.
See it as the first step in a multiple step validation process. Its validation doesn't have to be definitive. The second validation step can be done server side when the form is submitted. A third step, for example, can be validating if an e-mail address exists by sending a confirmation e-mail.
Only use them for formatting validation, and keep formatting as simple as possible. Also be flexible in the format to allow, and don't let people guess how to format it by using clear labels and examples.
It should not depend on server side validation because it has to be immediate.
Don't use them to show errors, only show success messages or an indicator when the input becomes valid. Keep it subtle, you can't guarantee the input is deemed valid after submit, so you don't want users to think that.
Use them for all fields or none. If some fields have live validation and others don't, it can be confusing or look like something is broken.
Check if you really need it. It can help users to quickly see if all fields are filled in and the form can be send for example. But this only works well when all fields are mandatory. Like for passwords, a more complex type of live validation can become handy, but then you have to use it for all fields (see #5)
An example:
The user is typing but mistakenly puts in a 2 instead of @. While other form fields did have a checkmark, this one doesn't get one, why? It helps the user seeing he/she has made a mistake:
Corrected the @ and the input becomes valid, but it doesn't have to be a correct e-mail address. As long as the input has focus, make the success message/indicator very subtle:
When the user moves on to the next field (thus after the input lost focus), there is no guarantee that the input is correct, only its format. So be careful how you communicate this "correctness". This shows a bit "brighter" indicator:
But a green checkmark can give the wrong message:
