Ttdfjt

In the end, both ways lead to the same result. Whether it's an inline error or maybe a bubble with feedback, the user gets to know why he can't proceed (which adheres to visibility of system status).

The point about disabled elements never having an action is understandable, but strictly clinging to this rule is not really of service to the user. If he could have a better UX with your product for the small price of not adhering to a rule 100%, I'd say it's worth it. You're not completely breaking it anyway, just slightly deviating from it.

With that being said, I personally think giving this feedback this way could be considered more modern or "cooler". So, especially if you're targeting a younger audience, I'd say it would be an improvement.

One drawback here can be that some users, who are very accustomed to the "old ways", could potentially find this unexpected and thus annoying. But that seems like a rather small chance.

Also another thing to consider: Users with visual impairment. Their screenreaders can catch inline error messages just fine (as far as I know), but a speech bubble might be tricky. At the very least, it should then simply grab system focus upon appearing.

Something like this seems to be a good way of doing it:

_Source

You can either show it on click of the button or have a smaller (?) button placed on top of it, which in turn doesn't break the disabled button rule anymore.

If this weren't mobile, I'd say it would be better to have a message shown next to the disabled button saying

Please fill in the remaining required fields (marked with *)

or some such (wordsmithing required).

But for mobile, where you don't have that real estate, having the button active (not disabled) and having it tell the user what fields they still need to fill in when clicked seems reasonable. I wouldn't make the button disabled but still responding to clicks, but perhaps it could say (Can't send yet) vs (when all required fields are filled in) Send.

Don't forget accessibility. There are various things you can do there. One of them is that you can make the "hint" the visually-impaired user hears for the button different, and longer, than what's shown visually, if the user is using the popular screen readers for mobile (VoiceOver for iOS, TalkBack for Android). Details here and here. For instance, the message could say "Please fill in the first name, lastname, and email fields." Be sure to test with screenreaders.

This is how the Google sign-up process does it. It should be very similar to your process. Note that the primary button is always enabled, it only changes its function!

1. You are presented with a pretty self-explanatory form

2. The Next button has the primary color and can be clicked. Note that the secondary button takes you to a completely different process (sign-in in this case.)

3. After submitting the invalid form via the Next button, you are scrolled to the first invalid form and all controls are validated (even when they are not dirty.)
   You will thus see all invalid controls on your way to the Next button.

The only difference to you is that you seem to have optional fields. You could mark these with (optional) or gather them in a completely optional form which, in addition to a Next, has a Skip button (This is very often used for phone numbers.)

If your form grows too big, think whether all required data is really needed at sign-up. If the user himself triggers actions that require more data – such as a purchase at an online store – it is better to only then require a payment method and address.

Going by the concept of 'informed decisions', it is always better to provide users with enough directions so that they do not make any mistakes instead of letting them find out that what they did was all wrong. If the form fields have required marked on them with an asterisk * or in some other way along with the other design intentions, the form will be filled correctly and there should be no need to disable the submit button. I recommend not using disabled buttons unless really required.

To me, it looks like you haven't actually disabled the "next" button, just toggled its behavior. So instead of

enabled (action a) ↔︎ disabled (no action)

you now have

enabled (action a) ↔︎ enabled (action b)

That in itself isn't necessarily a problem unless you render it as actually disabled. If you do, your users will expect other "disabled" buttons to have behavior. When they encounter an actually disabled button (i.e. with no behavior), they might get the impression that the button is broken, since the expectation is that "disabled" buttons shall give feedback (or at least have some action).

This is, as I understand it, your current solution:

The user doesn't get any indication of which of the two last buttons will react to interaction.

Consider instead a visual distinction between "enabled", "disabled-but-not-really" and "disabled-for-real", e.g:

This way you have a distinction between ordinary state, feedback state and actually disabled.

I think the way you have described it makes sense. I would include an asterisk on all the required fields, even though they are all required. You could even have a note at the top stating all fields are required. Anything to help the user understand what to do on a complex form is best.

Since in mobile vertical screenspace is (almost) unlimited, I would just add a permanent visible message just above the disabled button.

You need to fill out name, mobile number and agree to our T&C before you can continue.

Since the message will only appear if someone scrolls down to the Next-button, it will only be visible to users reaching for the button without having filled out all necessary fields. And you can leave the disabled = no reaction policy intact.

I would do some usability testing first to see if any of this even matters. You can't ensure a great user experience without including the user, right? Do some usability testing to see if users get confused as to why the button is disabled. Your particular users might understand why it's disabled and this could be a non-issue. Adding help bubbles or other stuff is just adding complexity to your interface that you don't know you need.

If your users are consistently clicking on the disabled button, then you have to determine why. Are they clicking because it doesn't look disabled? Maybe it's a visual affordance issue? Are they clicking because they are accidentally skipping one of the required fields? I had this happen once where the user had to check the box to agree to the terms and with all the other content on the screen, they didn't see it. Then when they got to the end of the form, they didn't understand why the button was disabled.