UX Issue: Alert or Deactivate?
It’s a common UX issue: you want users to enter all the required information into a form before clicking a Continue (or Submit) button, but you aren’t sure of the best way to prevent them from doing otherwise.
a) Deactivate (or hide) the Submit button, lighting it up once all the necessary fields have been completed, or
b) Leave the Submit button as is, but use inline or popup error messages to describe what’s still needed from the user.
Back in 2012, Chuck McQuilkin at UX Booth argued “both have their shortcomings. Each disrupts the user and has the capability to break their flow. Online, where distraction is high (and time and attention are scarce) interfaces that lack inactive states can help designers minimize errors with less interruption.”
He continued, “Inactive states seem harmless, but they pose a(n often infuriating) problem to users who can’t readily figure out why they’re presented the way they are. Inactive elements cannot “speak” for themselves and can therefore never explain why they’re inactive. This introduces a real potential for confusion into our designs.”
Three years later, the answer may seem obvious to some readers, but the idea provides a general rule of UX: Never remove functionality without making its purpose (or absence) apparent to the user. Disrupting users and breaking their flow remains all but inevitable. Some might argue that in the case of the deactivated Continue button, a rollover tooltip could be used to explain why the button is inactive (e.g. “Please complete all fields before clicking Continue”) but again, this is no guarantee the user will ever get the message. Nor does it offer any feedback as to which fields still need to be addressed.
While it’s probably safe to assume that by now the vast majority of users are familiar with the deactivated Submit button—and with its function—there is still the chance some users may not realize the button is in an inactive state to begin with and may simply assume something has gone wrong with their browser, website, or application. Therefore, even clicking a deactivated Submit button should produce some result and offer feedback to the user.
A third option used occasionally is removing the Submit button altogether, making it visible only once the user has completed all necessary tasks. This, however, is the worst option of the three and should be avoided entirely as it is the most likely to cause user confusion. Users may be put-off by the missing button from the onset, and abandon the form altogether, assuming something went wrong with the page. Or they may begin entering data and then go searching for the missing button, not realizing they left a field unfilled.
But the most compelling argument against simply hiding or inactivating the continue button is this: doing so never gives users the opportunity to be told which fields they’ve left blank. Since they never click a continue button to begin with, they never see any error messages, inline or otherwise. So this is clearly the worst way to go.
The wrong way to do things: feedback long after the fact.
Generally speaking, it’s always best to play to the lowest common denominator. That is, always err on the side of offering the user too much information. The worst this can do is cause minor irritation for users for whom such instruction seems obvious. But this pales in comparison to the frustration or lost responses that will undoubtedly occur when less experienced users can’t figure out how to successfully complete a form.
The best possible solution, then, is a combination of the above. Go ahead and deactivate the Submit button, but if possible offer some error feedback and data-validation—either upon button-click or even sooner, say, when a user skips a field and clicks into a field that follows.
Remember, even a deactivated Submit button should always do something. When fields have been left unfilled, clicking Submit should still direct the user’s attention towards the fields that need addressing, as Twitter does in this example.
Every so often, however, a long form extends beyond the immediately visible screen such that a user needs to scroll up and down in order to figure out which fields were empty. In this case, consider providing immediate validation and feedback (as described above) or try presenting the unfinished fields within an error popup, such that the user can complete the form right then and there and doesn’t have to go hunting around looking for inline error messages and blank text fields. While this may require additional development time, it is a suitable solution for any form, regardless of its level of complexity.
BoA employs an acceptable option: immediate feedback upon button-click.
Is your company ready to take on the unique, complicated task of testing its apps for usability? If you’re suffering under the ever-increasing weight of devices, systems, apps or test-cases your company must support, now you can break-free of the mobile-testing quagmire. Propelics’ Testing Strategy for Mobile Kickstart will ensure your team has the tools, processes, controls, and talents to confidently meet the challenges of testing for mobile devices. Check it out now!