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 ...
I'd like to suggest Option 1.and also you can show information without clicking the icon. Also, each and every field do not need information icon in my opinion. such as Genter, Birthday. Try to put an information icon where the user will get confused.
And these are my suggestions
First of all, if possible provide labels clear enough that additional info is not necessary. In some cases this is not possible, an in this cases such a info icon (i suppose they will open a tool tip) can be helpful.
The overall layout will have an impact where to place the icon. Having the info icon close to the label gives the user context.
Option 2 ...
I think you should check the answers here:
Is there a difference of meaning between “edit” and “modify” in this
To me modify is more extensive than edit. You could do both by
changing the contents, but if you simply changed the properties then
you might be said to be modifying but not editing. / Every edit is a
modification, but not ...
Short answer is no, but long answer is that you need to look at the big picture.
When it comes to copy text or labels for your application, it is good to take into consideration the broader picture for a consistency of writing style.
In most design systems, the hierarchy would probably go something like this:
Tone of voice from branding guidelines
As mentioned in other answers, I agree it can depend on the context of what you want to edit or modify. There are idioms to take into account for edit, modify and also change.
Yet since we're talking about user experience here, it's also a matter of end result from the user's point of view:
Edit: the user can access something and may alter it. But they may ...
what about this compact approach for a yes/no/neither filter input
taking a cue from sort buttons in column headers which switch from off/up/down/off per click
one button that changes values per click, showing the current filter selection:
| filter by gender | (gender filter is off)
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!
You are presented with a pretty self-explanatory form
The Next button has the primary color and can be clicked. Note that the secondary button takes you to a completely different process (...
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 ...
At first: Use the feedback of the users! (not necessarily the stakeholders if they do not use the form by themselves).
I think both navigation Models are equal. The most important thing is, that the steps are clear to the users. In your example there are multiple steps per major step. This might be confusing. Also the major steps have quite long forms which ...
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 ...
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 ...
The short answer is yes.
The reason for this, and a good example, the create account form you see on many popular websites, many UX evangelists have argued over the years to simply get people registered and into your application THEN pry the additional information from them once registered.
This way you avoid annoying people by asking endless questions, ...
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.
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 ...
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 ...
I know we talk about platform agnostic design, but it's not really true. Touch-screen and reach are an integral part of the usability of a mobile device application.
The reason this is important is because, keeping a 'Next' button in view is important, but making access to that button as easy as possible is equally so.
This may come down to aesthetics, so ...
Great question, I partly agree with @BrunoH here.
The 'Recognition rather than recall' heuristic makes it easier for the users to remember what they did wrong. However, there is a 'bad' side to this. If the user is interrupted during the error correction process, for instance: They get a phone call, the doorbell rings etc. they might think the current input ...
The error message should stay.
There is a design principle 'recognition rather than recall'. Meaning the user should not be forced to remember things but rather give the information (or options) needed to complete the task.
Someone could argue that often the error is quite easy to understand like 'insert a valid email address' or the like. But it can also ...
I think better to let the system listen to your keyboard, the moment you start filling the field it starts to check. For example, you need to fill your email, when you start to type it will keep the outline red around the field until you type "@" sign and after. This way already in use and you can apply it. Please check the images:
Before the @ sign
That NN/g article is correct, and the answer to your question is, Yes! :)
As also stated in, say, the Switch section of the Material Design Guidelines, the key behavior of a switch is that "[w]hen a user toggles a switch, its corresponding action takes effect immediately."
Every time I've discussed this aspect with fellow Ix designers, we agreed that "...
Madalina, a general minimum width for buttons, as stated in the Material Design Guidelines, is important, because it ensures that all buttons are reasonably easy to click or tap even for very short labels such as OK. Think "Fitts's Law."
And while same-width buttons may look more aesthetically pleasing, I've yet to see research that shows any usability ...
If I am understanding your question, there are some fields on your form that when information is entered, override some other fields that are no longer needed (for example, use saved phone number vs. enter a new one)
First the field should be disabled (visually, that is usually achieved by reducing opacity or graying out)
Second if the user has already ...
I believe your idea is correct regarding the use of checkbox when a Submit button is required. Toggle ON/OFF switch do not need a separate Submit button.
By 'immediate', as iOS guidelines describe, there should be some sort of visual feedback that the effect is now turned on or off, usually dependent fields are hidden/displayed/activated/deactivated. The ...
Is it possible to combine the fields into one input, and figure out which they used server side? That way, you can eliminate half the fields, and the user doesn't have to make a decision or remember whether they login with their email or username.
Pragmatically this isn't a form that needs to be validated.
Technically, yes, but it's just one field and 1 simple issue: is there text entered? There's no check for date formatting, if an email works, if a password is safe enough or anything commonly done with a form. So there's not the same cognitive load.
As the other thread mentions, users have two ...
I recently worked on a similar multi-step wizard that helped medical practitioners find the right medical licences to apply for.
TL/DR: we went with deactivated button option.
Since we followed a progressive step-by-step approach where the response to each question guided the subsequent questions, the 'Continue' CTA needed to be after each response. ...
It is an anti-pattern to visually disable affordances, functionally disable affordances, or hide affordances. PLEASE don’t do it. I will make a case for all three.
Disabling or hiding affordances is one of my biggest pet peeves, especially since it is a case of over-engineering the solution:
It’s always extra engineering and design effort to hide or ...