What is being submitted?
A pattern for form level validation.
Rules and rationale for 2 validation patterns
Option 1: always enable the primary button (e.g. “Next”, “Submit”, “Send”) and trigger validation when clicked to display error messages.
Option 2: disable primary button until all mandatory fields are entered.
Verdict: Both options should be available, and the designer should choose the best option for the given situation. Need to provide some guidance to define which option should be used.
Why are you submitting?
What evidence do you have that it’s needed by multiple services across government?
What evidence do you have that it meets the needs of the users of those services?
Have you checked that it doesn’t already exist in the DIO Design System?
Examples, links, and research
Additional comments:
Khean: Enabling actions to proceed, only after everything is filled out, is ok. It requires some form of inline error messaging if someone touches a required field.You either have to deal with a never-ending loop of submit and deal with invalid fields, or a continuous looking for what is actually required to proceed. It depends on where the potential for frustration rises.A good A/B test candidate, for sure.
If only required fields are presented, or it is a very guided experience with few options
Zion: A/B Test
Dave V: How will the user know what to do to enable a disabled button?Unless it’s obvious I think option 1 makes sense.
Tim: I think context is key to get the users in a guided direction and I agree with everything said above. I always try to think back to the 10 usability heuristics as an audit of the design and this one speaks to #5 - Error Prevention. What I would audit for the user flow is, by enabling a button and an action to move forward within a process, am I opening the door for error where the user will have to double back eventually because they will miss something and need to come back to it or do I make sure that they finish what they need to fill out before moving forward to prevent that rework from happening: #5: Error prevention
Good error messages are important, but the best designs carefully prevent problems from occurring in the first place. Either eliminate error-prone conditions, or check for them and present users with a confirmation option before they commit to the action.With the said, options 1 or 2 may work depending on the length of the form (context). If the user can see in a single view port what fields are available to them then 2 isn't a bad option. If it’s along scrollable list of form fields then 1 is better because a user may not be able to identify what field was missed to enable the next button so if the next button was enabled and triggers a modal that says “you missed required fields ABC…” then that’s a better option for a longer form
Spark450
commented
5 hours ago
Issue needs re-write
What is being submitted? A pattern for form level validation.
Rules and rationale for 2 validation patterns
Option 1: always enable the primary button (e.g. “Next”, “Submit”, “Send”) and trigger validation when clicked to display error messages.
Option 2: disable primary button until all mandatory fields are entered.
Verdict: Both options should be available, and the designer should choose the best option for the given situation. Need to provide some guidance to define which option should be used.
Why are you submitting?
What evidence do you have that it’s needed by multiple services across government?
What evidence do you have that it meets the needs of the users of those services?
Have you checked that it doesn’t already exist in the DIO Design System?
Examples, links, and research
Additional comments:
Khean: Enabling actions to proceed, only after everything is filled out, is ok. It requires some form of inline error messaging if someone touches a required field.You either have to deal with a never-ending loop of submit and deal with invalid fields, or a continuous looking for what is actually required to proceed. It depends on where the potential for frustration rises.A good A/B test candidate, for sure. If only required fields are presented, or it is a very guided experience with few options
Zion: A/B Test
Dave V: How will the user know what to do to enable a disabled button?Unless it’s obvious I think option 1 makes sense.
Tim: I think context is key to get the users in a guided direction and I agree with everything said above. I always try to think back to the 10 usability heuristics as an audit of the design and this one speaks to #5 - Error Prevention. What I would audit for the user flow is, by enabling a button and an action to move forward within a process, am I opening the door for error where the user will have to double back eventually because they will miss something and need to come back to it or do I make sure that they finish what they need to fill out before moving forward to prevent that rework from happening: #5: Error prevention Good error messages are important, but the best designs carefully prevent problems from occurring in the first place. Either eliminate error-prone conditions, or check for them and present users with a confirmation option before they commit to the action.With the said, options 1 or 2 may work depending on the length of the form (context). If the user can see in a single view port what fields are available to them then 2 isn't a bad option. If it’s along scrollable list of form fields then 1 is better because a user may not be able to identify what field was missed to enable the next button so if the next button was enabled and triggers a modal that says “you missed required fields ABC…” then that’s a better option for a longer form