Forms

Our form guidance aims to reduce the complexity of a task to complete by providing a systematic layout of related elements.

Anatomy

The fundamentals are consistent to any form element within the Productboard UI, but are not always necessary to display together.

Anatomy
  1. Label: A title to describe its purpose.
  2. Input: The interactive element of a form component.
  3. helpMessage (optional): When a label is not required, longer helpful text can be added.
  4. Required (optional): Should a field require a value, it should be visibly marked as required.

 


Structure

Forms should have a structure that makes it easy for users to scan. A vertical rhythm to forms makes scanning its content much easier, a particular consideration for sighted users.

Elements should be given an appropriate amount of horizontal spacing in between them so they can be dentifiable more clearly, depending on their size.

Input fields typically need larger spacing as opposed to selection elements.

Input fields typically need larger spacing as opposed to selection elements.

 

Fieldsets and legends

Fieldsets (heading) and legends (description) help break up longer form content and add clarity to sections so users are able to process the inputs in an easier way.

Try not to elongate or over-emphasis heading and descriptions; their purpose is to assist in explaining a forms content. Consider linking or expanding explanations when appropriate.

Try not to elongate or over-emphasis heading and descriptions; their purpose is to assist in explaining a forms content. Consider linking or expanding explanations when appropriate.

 

Ordering of forms

When arranging a form, make sure the inputs are displayed in an intuitive order that makes the most sense for the content required.

  • Order a single Form per page. More on this on Form length.
  • Position inputs by their relative level of importance.
  • Group related inputs next or near to each other.
  • Forms should be ordered sequentially, depending on the user's language preference. This typically is top to bottom, and left to right for Latin-based languages.
  • As best practice, try to keep inputs that require keyboard entry near each other to avoid users having to switch back and forth froming keyboard and mouse usage.

 


 

Sizing considerations

Form controls should be sized accordingly to fit their value. It is important to provide adequate widths to individual inputs without under or over-estimating the desired content. A user is guided on the expected correct answer length by the width displayed.

When not possible, altenatively use a consistent width that provides enough room for correct answers.

Typically inputs such as email address or description would be longer that names as the answer required is typically longer.

Typically inputs such as email address or description would be longer that names as the answer required is typically longer.

 

Grouping controls

There may be instances where a collection of controls are more suited to one another and so should be placed together. In particular when doing this, these fields should be clearly labeled with placeholder text to reinforce this understanding where possible.

Grouping

 


 

Form length

Completing a form should be made as straighforward as possible for a user. We want to avoid over complication and presenting too many fields that are not necesssary. When constructing, evaluate all inputs added to generate a deeper sense of what is and isn't vital. There may be more valid cases for longer form lengths depending on the context, however they can be treated in a better way.

Form length

 

Multi-step forms

Consider breaking apart long form content so it becomes more managable to digest. Offering clear step guidance and additional page breadcrumbing means the user can navigate back and forth to amend whilst knowing the amount of steps they are along in the process.

When using this pattern, each screen should show fields that logically belong together. This pattern is also good for saving form progress along the way, with clear call to action labelling.

 

Form actions

Form actions can append a form within a page or page section. Having these actions helps the vertical alignment scanibility of the content.

Form actions

Always have the action active, even when there are inputs that have not been interactive with or there are errors visible. Disabled buttons are available but we suggest avoiding them here as they don't clearly communicate what actions a user should take to complete a form.

 


Validation

Validation and error messaging should be displayed when a form submission fails or further information is required. Browser-native validation messages are not accessible to screen readers and so we encourage the use of Nucleus instead for correct validation.

Examples of validation are inline on individual form elements or grouped together using our Alert component.

Examples of validation are inline on individual form elements or grouped together using our Alert component.

 

Validation on submit

As content in input into forms, the default web behavior is to validate this upon submission. This lets the user flow quickly through the form without interruption. Should the form fail validation, guide the user to the invalid inputs.

  • Error messaging should provide guidance on next steps and how to remedy the situation.
  • If the form has 3 or more errors, use our Alert above the content to summarize all errors.
  • For forms in Modals, any system error should be displayed within a Toast after the modal has been closed.

 

Inline validation

Inline validation offers immediate feedback, but when a screen reader user moves focus from the invalid input to the next form control, they will be interrupted by the validation message of the previous form control so check for syntax errors.

null

Should the validation fail, individual error messaging will display underneath the invalid input.

 

Help messaging remains in an error state if the content that has been input still doesn't fit the criteria. This disappears when the criteria is met.

null

A loading spinner is shown should the validation on a input takes longer than a second.

 


 

Best practice

  • Use the width of the text input to give users a hint about how long the value is expected to be.
  • Enable the form submission action, even when the form is empty or has an error.
  • Flow form elements vertically as these are easier to scan.

 

Do's and Don'ts

Do

Don't

✅ Use single column layouts as much as possible.

🚫 Rely on 2-column or multi-column form layoutsas they can be a distruption to a user's natural vertical scanning and may be interrupted incorrectly.

✅ Group related form elements. Consider breaking forms into sections when it makes sense for the content.

🚫 Make forms really long to avoid user drop off.

✅ Write explaination text to describe a group and their intended relationship together.

🚫 Group inputs together too tighterly as they can be difficult to distinguish from eachother.

✅ Use fieldsets when breaking a form into sections.

 

✅ Always include a visible label on every input. An acceptable exception to this would be when using SelectGroup.

 

✅ Implement the best field length needed for the design.

 

✅ Error text should explain how to resolve the error.

 

✅ Enable the form submission action, even when the form is empty or has an error.