Consider a world where all buttons are deactivated by default. It’s usually drab, muted, and little out of focus, with poor contrast and a subdued text label that’s a little hard to see. However, it isn’t doomed to be deactivated indefinitely. Once a well-formed input is provided, it finally becomes active. But, before it can use its full colour gradient extravaganza to bring life to the page, it just sits there calmly and quietly, minding its own business. Do you want to be a part of this world?
To be fair, there could be compelling reasons to make buttons disabled by default. After all, we aim to make it more difficult for our users to make mistakes as designers and developers. We don’t want to waste time switching back and forth between error messages. Before the data is transferred to the server, we want to make sure that the input is perfect. Before users move on to the next phase, we want to let them know that something vital is missing.
Users’ Reactions to Disabled Interfaces #
When something in the UI is disabled, it’s a sign that something isn’t quite right. However, that seemingly straightforward remark may not be apparent at first inspection. What if you wanted to uncheck a checkbox but couldn’t because the interface wouldn’t let you? So, what exactly is the issue? Is your Internet connection having problems? Besides, is there anything wrong with the user privileges? Is it better to wait and hope for the best or to simply refresh the page? Will all the data you’ve so carefully and painstakingly filled in remain in the form if you reload the page, or will it be lost forever?
The scenario isn’t much different when we come across a disabled button. We’ve been blocked, but we’re not sure why. It’s possible that something else is needed in order for us to move forward. Or we’ve missed something in the fine print. Maybe we made a mistake in one of the entry fields. Or we didn’t fill in the information correctly. Or maybe there’s no mistake on our end at all, and it’s just a system bug outside our control.
There are a plethora of reasons why the button may be blocked, and users are frequently left in the dark trying to figure out what the missing piece of the puzzle is. They frequently exhibit two types of slightly different behaviours in these situations, and these behaviours are dependent on what is inaccessible in the UI.
WHEN LARGE AREAS OF THE INTERFACE ARE OFF #
The interaction of customers with disabled states indicates a few prevalent usability trends. Most clients will assume that the system is busy and that something is occurring in the background on the website when substantial portions of the interface are disabled. And, because something is going on, they normally exercise a great deal of patience at first. They’ll just sit there and wait for a spinner to appear or for the page to return. The more precious the information, the longer they will have to wait.
You’ll probably act the same way. What is the reason for this? As it turns out, we do so just to avoid any potential disturbances to the ongoing process. We won’t know if Schoredinger’s cat is alive or not unless we look into the box, and we won’t know if the booking was successful unless we look into the system or speak with someone who does.
If something unexpected happens throughout the booking process, or if we mistakenly press the incorrect button at the wrong time, we are simply left in the dark. We may feel more secure if we receive a confirmation email, but we won’t know for sure until we log into the system and confirm our reservation. And we won’t be much smarter if the email doesn’t arrive.
WHEN ONLY A SINGLE BUTTON IS DISABLED #
The behaviour described above may seem reasonable for pages that completely prevent user input, but surely it should be different when only a small portion of the interface — say, a simple “Continue” button — is disabled? Ironically, the same problems may be found with isolated buttons as well, but to a lesser extent.
Users appear to have more trust that there is an issue directly related to their input when buttons are blocked because the rest of the interface is accessible. That’s why it’s unusual to see people sitting and waiting for the “Continue” button to mysteriously come back to life or change.
One issue that does arise, especially on mobile, is when users come across a disabled button late in the process. Many people are unaware if the button was disabled from the start or if something in their input caused it to be disabled. Some folks will even open the identical page in a new tab to see what it was like before.
Validation in the browser is never foolproof #
Everything we’ve discussed in the previous parts should, in theory, never happen. Isn’t that what inline validation was supposed to help with in the first place? Instead of displaying error messages after all of the input has been completed, we display them one by one as users make errors – usually after leaving the input area. But how many times did it let you down?
Have you ever had your delivery address rejected by an address validator, perhaps because the building was newly constructed? Perhaps you used totally legitimate but slightly convoluted syntax to avoid spam, such as k.giraudel+smashing@bmx.de, but the email validator assumed the + character couldn’t be in the email?
What if you don’t have a business email account yet, but the provider won’t let you use your Gmail address? Maybe there’s some information you don’t want to supply — like your age, gender, birthday, or phone number — and even though it’s marked as optional, the interface won’t accept an empty value?
Source: website builder
