Alert types

• Documentation
  When to use

  • Use an alert banner when you need to prompt the users attention. Alerts are primarily used for holding additional information about questions as well as displaying validation errors.

  Guidance

  • When the applicant is required to do something in response to an alert, let them know what they need to do and make that task as easy as possible. Think about how much context to provide with your message. For example, a notification of a system change may require more contextual information than a validation message. Write the message in concise, human readable language; avoid jargon and computer code.
  • Be polite in error messages — don’t place blame on the applicant.
  • Applicants generally won’t read documentation but will read a message that helps them resolve an error; include some educational material in your error message.
  • But don’t overdo it — too many notifications will either overwhelm or annoy the applicant and are likely to be ignored.
  • Allow a applicant to dismiss a notification wherever appropriate.
  • Don’t include notifications that aren’t related to the applicant’s current goal.

Section review summary alert

• Documentation
  When to use

  • Use a section review summary alert block when showing an applicant each incomplete question on the section review page.

  Guidance

  • If an applicant clicks a link in the section review summary alert block the page should scroll to the selected question.
  • Links should dissappear from the summary alert block once the necessary field is valid and complete.
  • The entire summary alert block should dissappear once all fields indicated are valid and complete.

Form review summary alert

• Documentation
  When to use

  • Use a Form review summary alert block when showing an applicant each incomplete section when reviewing the entire form before submission

  Guidance

  • If an applicant clicks the "back to section" button they should be directed to the proper section of the form.
  • A formm review summary alert should dissappear once all fields within the necessary section are valid and complete.

Single/multi-line text inputs

• Documentation
  When to use

  • If you can’t reasonably predict a applicant’s answer to a prompt and there might be wide variability in applicants’ answers.
  • When using another type of input will make answering more difficult. For example, birthdays and other known dates are easier to type in than they are to select from a calendar picker.
  • When applicants want to be able to paste in a response.

  When to consider something else

  • When applicants are choosing from a specific set of options.

  Guidance

  • The length of the text input provides a hint to applicants as to how much text to write. Do not require applicants to write paragraphs of text into a single-line input box; use a text area instead.
  • Text inputs are among the easiest type of input for desktop applicants but are more difficult for mobile applicants.
  • Only show error validation messages or stylings after a applicant has interacted with a particular field.
  • Avoid using placeholder text that appears within a text field before a applicant starts typing. If placeholder text is no longer visible after a applicant clicks into the field, applicants will no longer have that text available when they need to review their entries. (People who have cognitive or visual disabilities have additional problems with placeholder text.)

Select input

• Documentation
  When to use

  • Use sparingly — only when a applicant needs to choose from about seven to 15 possible options and you have limited space to display the options.

  When to consider something else

  • If the list of options is very short. Use radio buttons instead.
  • If the list of options is very long. Let applicants type the same information into a text input that suggests possible options instead.
  • If you need to allow applicants to select more than one option at once. applicants often don’t understand how to select multiple items from dropdowns. Use checkboxes instead.

  Guidance

  • Avoid making options in one dropdown menu change based on the input to another. Applicants often don’t understand how selecting an item in one impacts another.

Email input

• Documentation
  When to use

  • Use only when collecting an email address from an applicant.
  • Email inputs are automatically validated to ensure properly formatted email addresses.

Dollar amount input

• Documentation
  When to use

  • Use when collecting dollar amounts from an applicant

  Guidance

  • Dollar amount inputs should use type="number" for proper fomatting.

Input modifiers

• Documentation
  When to use

  • Use input modifiers when you need to allow an applicant signify additional attributes for a field (e.g. initial only or no middle name).
  • Use input modifiers when allowing an applicant to disable a field if they don't know the information or the information is not applicable.

  When to consider something else

  • Don't use modifiers to ask an additional question.

  Guidance

  • When an applicant checks "Not applicable" or "I don't know" for a given input, the input should become disabled even if it already has information typed into it.
  • If stacking input fields with modifiers (e.g. full name inputs) use modifiers on the right so as not to interfere with input labels.

Alternate input label style

• Documentation
  When to use

  • Use only when the normal label style is not needed. For example, when an input is not part of a fieldset you will want the label style to match the fieldset legend for design consistency.
  • Hair color is a good example of this pattern.

Input sizing

• Documentation
  When to use

  • Varying input sizing gives the applicant a hint at the length of text to write for a particular question.
  • For example, you would use a small input size for collecting a weight from an applicant and a large input size for collectin a name of a school.

  Guidance

  • Inputs with size classes applied will be full width on mobile.

Validation

• Documentation
  When to use

  • Validation is used to signify to the applicant the state of the information they input into the form.

  Guidance

  • Untouched: fields that have not had any information added to them.
  • Incomplete: fields that hold invalid information and/or required fields that are empty.
  • Complete: fields that hold valid infomation and/or required fields that are filled in.
  • Validation should be triggered upon exiting a field. For fieldsets like addresses, this may apply to the fieldset as a whole.

Checkbox block

• Documentation
  When to use

  • When a user can select any number of choices from a set list.
  • When applicants need to see all the available options at a glance.

  When to consider something different

  • If there are too many options to display on a mobile screen.
  • If a user can only select one option from a list (use radio buttons instead).

  Guidance

  • Applicants should be able to tap on or click on either the text label or the checkbox to select or deselect an option.
  • Avoid using negative language in labels as they can be counterintuitive. For example, “I want to receive a promotional email” instead of “I don’t want to receive promotional email.”

Radio button block

• Documentation
  When to use

  • When applicants need to select only one option out of a set of mutually exclusive choices.
  • When the number of available options can fit onto a mobile screen.

  When to consider something different

  • Consider checkboxes if applicants need to select more than one option or if there is only one item to select.
  • Consider a dropdown if you don’t have enough space to list out all available options.
  • If applicants should be able to select zero of the options.

  Guidance

  • Applicants should be able to tap on or click on either the text label or the radio button to select or deselect an option.
  • Use caution if you decide to set a default value. Setting a default value can discourage applicants from making conscious decisions, seem pushy, or alienate applicants who don’t fit into your assumptions. If you are unsure, leave nothing selected by default.

Inline Radio Button Block

• Documentation
  When to use

  • When applicants need to choose “yes” or “no”
  • When the list of options is less than or equal to 3.

  When to consider something different

  • If the list of options is greater than 3

  Guidance

  • Applicants should be able to tap on or click on either the text label or the radio button to select or deselect an option.

Validation

• Documentation
  When to use

  • When an applicant has not selected any option in a list of radio buttons or checkboxes.

From/to date block

• Documentation
  When to use

  • The from/to date block is used to collect a date range from an applicant.

  When to consider something else

  • Use a month/day/year block when you are only collecting a single date from an applicant.

  Guidance

  • Don't auto tab between form fields. This could confuse applicants as they are trying to recall a date.
  • Error validation should be triggered if month entered doesn't exist
  • Error validation should be triggered if day entered doesn't exist in given month
  • Error validation should be triggered if year is too far in the past or future.
  • Error validation should be triggered if an applicant enters a "to" date that is before a "from" date in the same entry.

Month/Day/Year Block

• Documentation
  When to use

  • The month/day/year date block is used to collect a single date from an applicant.

  When to consider something else

  • Use a from/to date block if you are collecting a date range from an applicant.

  Guidance

  • Don't auto tab between form fields. This could confuse applicants as they are trying to recall a date.
  • Error validation should be triggered if month entered doesn't exist
  • Error validation should be triggered if day entered doesn't exist in given month
  • Error validation should be triggered if year is too far in the past or future.
  • Day input may be optionally ommited if only the monty and year is needed from an applicant.

Timeline Block

• Documentation
  When to use

  • Use a timeline block to show an applicant their progress when filling out information within a designated block of time (e.g. provide all the places you've lived over the past 10 years).

  Guidance

  • The timeline progress bar fill amount should be relative to the timespan given for each entry.
  • The timeline progress bar fill location should be relative to chronological order of entries.
    • Entries farther in the past should show up farther to the left in the progress bar.
    • Entries closer to the present should show up farther to the right in the progress bar.

Counter Block