Skip to main content
Hennepin County Design System

Form basics

Forms allow users to submit data so they may receive information or a service. 

Well-designed forms give users confidence in how the county treats their information. 

Ethical considerations for forms

Only ask for the information you need from the user. For example, if you don’t need to know a person’s race, don’t ask for that information. 

Be clear about what fields are required and which are optional. For example, state if someone can opt in for getting updates on their application.

Structure and sequence

Order form in a logical way

Ask questions in a logical order from a user’s perspective. The form title and headings should follow a logical heading order (H1, H2, etc.).

Group related tasks

Chunking like information together gives users more manageable tasks without overwhelming them.

Use single-column layout

When possible, use a single-column layout. This gives users only one path to complete the form. It reduces the chance a user will miss a field. The single-column layout also performs better on mobile devices.

The multiple-column layout or Z patterns don’t provide as clear of a path, so they usually take longer for the user to understand.

Make all forms accessible

Accessible forms must: 

  • Be keyboard friendly 
  • Have correct code so screen readers and other assistive devices can read and display it 
  • Be mobile responsive 
  • Meet color contrast requirements 
  • Have appropriate sizes for tappable input fields and buttons
  • Have readable font sizes, usually between 16 and 18 pixels. For more detail about font sizes, visit Type scale.

Developer guidelines:

  • Divide long forms into more than one page, with shorter steps on each page. 
  • When possible, avoid adding a time out. 
  • Avoid using tables for form field layout. 
  • Avoid using color as the only characteristic that distinguishes an item. 

For help creating a form, contact the Web Forms team (must have network access). 

Interface elements of forms

Input fields

Input fields are the core component in any form. They include text fields, dropdowns, check boxes, radio buttons, and date pickers. 

For detailed information on input fields, visit text input

Buttons

Label buttons with words that describe the users’ action. Use words like Apply, Register, Search, Log in, Order, Submit, Request, or Create account.  

Avoid using a Reset or Clear button on forms. These create more drawbacks than benefits for users.  Reset or Clear button work well when search or filter are used in a form. 

Form pagination

We can display long forms on more than one page (pagination or progressive disclosure). Long forms can use a progress tracker to let the user know where they are in the process.

When using pagination:

  • Show which step the user is on. 
  • Show which steps the user has completed. 
  • Allow users to go back to previous steps.  
  • Consider a review step so users can see a summary of information before they submit the form. 

Field labels for forms

Every form field must have a label. Keep labels short. Keep them clear and meaningful. Use precise language so the user understands the information they should provide.

Required and optional fields

When all fields are required

  • Add an instruction near the top of the screen, for example, “All form questions are required.” 

When most fields are required

  • Add instructions near the top of the screen. For example, state that “All fields are required, unless marked (optional)."
  • Add “(optional)” to the end of the label for every optional field.
  • Don’t mark required fields.

When most fields are optional

  • Add an instruction near the top of the screen. For example, state that “All fields are optional, unless marked (required).”
  • Add “(required)” to the end of the label for every required field.
  • Avoid using only an asterisk for required fields. 
  • Don’t mark optional fields.

Help text and tooltips within forms

Help text

Help text clarifies the purpose of a field label. It also helps users find the information they need, to answer the question. 

Using help text:

  • Put help text under the field label.
  • Use help text only when necessary. When every field has help text, it adds distraction and makes it harder to complete. 
  • Use help text when you know users struggle with the question, and why.  

Tooltips

Tooltips help users learn a product, while they use it. Tooltips let users learn by displaying information on the screen only when they need it. They’re most helpful for information users will need only on occasion. They’re most effective in products users often return to. 

Users view tooltips by hovering or tabbing on active elements on screen, like a icon or button. The tooltip explains how to use a feature or function of the interface. For example, users could select a tooltip to explain the action that a button will trigger if they select it. Avoid hover-only tooltips. 

Feedback, error messaging, or validation for forms

Keep users informed. Provide appropriate feedback at the correct time and in the right place based on users’ input. 

When possible, use inline validation for user errors. Inline validation happens in real time once the user leaves the field. Inline validation lets users complete forms faster and with less frustration. 

Best practices for displaying errors: 

  • Display the message as soon as possible after the error happens. 
  • Make clear which field the error applies to.  
  • Display the error message close to the field where the error takes place. This ensures the user doesn’t miss the error message. A common place to display the message is right below the field. 
  • Style the error message in a different way than normal fields and help text. When possible, use icons and color to draw attention to the error message, such as red text and a red caution icon. The icon helps communicate to users who experience color blindness.  
  • Make the error message concise and meaningful. Communicate possible solutions to the error and never blame the user. 
  • Remove the error message once the user corrects the error. 

Avoid these things: 

  • Don’t validate fields before users’ input is complete. 
  • Don’t erase the user’s input when showing the error message. 
  • Don’t hide error messaging in tooltips. 

Success page of forms

Let users know when the form is complete. Show a success message on the screen. Also use a secondary method, like email, when necessary.

Confirmation reassures users they have filled out the form correctly. It also reduces doubt and builds trust in our services. 

Best practices for success messages: 

  • Make the message clear and succinct (for example, “We have received your submission."). 
  • Where relevant and possible, include next steps and wait time (for example, “We will call you in 2 to 3 business days.”). 
  • Where relevant, include a way for the user to contact someone if they have questions.