Fields make up a large part of our ecosystem. Customers are asked to fill them out in multiple flows and products. Because of this, it’s important to have consistency throughout the ecosystem to help set expectations and make it an easier, quicker, and accessible experience for our customers.
Labels
Field labels are names given to the fields themselves, like First name, Bank account, etc. They provide clear context and can include instruction and formatting (like Full name or mm/dd/yyyy). Labels typically appear outside the field itself. Some labels appear in the field and pop outside of the field as a user types. This interaction is fine, as long as it’s accessible.
Have a label. A label anchors the field and the form itself.
Don’t use labels in the fields themselves if they disappear when a customer selects or starts typing in the field.
Keep the label short.
Don’t use all caps. They’re hard to read.
- Why would you like a loan?
Be clear and jargon-free.
Don’t be vague or use jargon. It’s confusing, frustrating, and can increase cognitive efforts needed to understand what’s being asked.
- How much would you like to borrow?
Ask questions sparingly. Questions increase cognitive load but are helpful in certain situations, like step flows.
- Show fields if you have fewer than 6 inputs.
Placeholder text
Placeholder text, also called ghost text, is text inside a field that provides additional guidance, clarity, or examples. Placeholder text should never be the only context for our customers. Field labels should be descriptive enough to guide users, so only use placeholder text when a bit of additional guidance is useful.
Use placeholder text in some, but not all, form fields. Not every field in a form needs placeholder text.
Don’t use placeholder text in place of a field label or to echo the field label.
Add formatting to the label or under the field, where it’s persistent.
Don’t use placeholder text to show formatting. It disappears when a customer starts typing in the field.
The default field content is no placeholder text. Otherwise, we train users to ignore our content.
In general, placeholder text guidance should be minimal. In cases where we want a customer to include detailed information in a field (in a review, for instance), studies show that the more placeholder text that’s in that field, the more likely it is that a user will also include a lot of content.
Learn more about placeholder text
- Placeholders in form fields are harmful (Nielsen Norman Group)
- Form instructions (W3 Web Accessibility Initiative)
Required info
How to indicate required info
When possible, only ask for info you need.
The exception to this is forms where customers need flexibility. An example of this is a contact form with multiple fields for an address (for example, “Address line 1” and “Address line 2”).
In cases where there’s a mix of required and optional fields, clearly indicate what’s required and what’s optional.
Set expectations at the start of an experience. Use a brief description if space allows.
See also: Inclusive content
If most info is required
If all fields are required, you don’t need to label individual fields. Indicate at the start of the form:
Examples
- Complete all fields.
- All fields are required.
When some fields are optional, indicate at the start of the form:
Examples
- All fields are required unless marked optional.
At the field level, use a text label:
Examples
- Middle name (optional)
- Company name (optional)
When there are multiple steps or screens to complete, use Skip, Not now, or Maybe later to indicate optional fields.
If most info is optional
Call attention to what’s required. At the start of an experience, describe how required fields are marked:
Examples
- * indicates required info
- * Required info
Use an asterisk after the field label to indicate required info:
Examples
- Social Security number*
- Display name*
According to the Nielsen Norman Group, customers recognize the asterisk as meaning “required,” regardless of whether they use assistive technology.
Be mindful that the asterisk symbolizes different things depending on the context. To learn more about asterisks, see our punctuation guidelines.
While we use the asterisk to mark required fields, we also use it to point to comments at the end of a page, such as disclaimers.
Avoid using the asterisk for both purposes in the same experience. If there’s an overlapping use, use a text label instead:
Examples
- Social Security number (required)
- Display name (required)
Don’t use placeholder text or tooltips to indicate required info. Assistive technologies don’t universally support these as text labels, so a screen reader might not read the message.
See also: Placeholder text, tooltips
Make an accessibility plan
Plan early on how your team will account for accessibility. These steps help ensure that required info is clear to customers who use assistive technologies to navigate our products.
If you take these steps, you don’t need to provide special documentation to make your content accessible for assistive devices.
When designing
Work with your product design and developer partners to use Intuit Design System components. This applies to controls, including fields, checkboxes, radio buttons, and more. These elements support indicating “required.”
When developing
Request that your developer partners use a “required” attribute in the HTML for required fields:
Examples
<input type=”text” required />
This way the screen reader will announce that the field is required without the need for a visual indicator like an asterisk or text label.
See also: Make it accessible
Give error feedback
If a customer skips a required field, provide an error message. Show the error after a customer tabs through a required field or attempts to save a page with incomplete required fields. Make sure to retain the info in the fields that the customer has already filled out.
Highlight incomplete fields. If there are multiple missing fields in a long form, use a page-level message to call out specific fields:
Examples
Enter required info:
- First name
- City
- State
Resources
- Web accessibility criteria – required fields (California State University, Northridge)
- ARIA-2: Identifying a required field with the aria-required property (W3.org)
- U.S. Web Design System form guidelines
- Marking Required Fields in Forms (Nielsen Norman Group)
For Intuit employees
Field-level errors
Field-level errors appear beneath a form field component after a customer has attempted to submit info that doesn’t quite fit the bill (there are a lot of different reasons why that could be). Here are some common use cases:
Examples
- Required field is empty
- Too many characters
- Info might be wrong based on internal calculations (tax form entry)
- Character entry required (can’t leave blank, enter 0)
- Leave blank (don’t enter 0)
- Incorrect format (such as a number in a letter section)
- Not enough characters
- Enter a phone number.
- Enter an amount.
- Enter fewer than 20 characters.
Use command-oriented language. Tell them what to do to keep moving.
- Oops, something went wrong.
- You experienced a login error.
- Too many characters.
Don’t just point out what’s wrong.
- Enter an email with an @ symbol.
- Use numbers only.
Choose functionality over tone. Be specific about what needs to happen in order for them to complete their task.
- Hmm, looks like your email isn’t right.
- Please use numbers only.
- Please enter a value for this required field
Don’t use fillers words like hmm or please. Keep it short, and follow our guidelines for delivering bad news.
- Enter a five-digit ZIP code.
- We couldn’t process your payment. Double check your card info or try a different one.
Add as many details as needed to complete the task correctly.
- Enter a complete ZIP code
In this example, it’s not clear what a “complete” ZIP code really is.
Keep a field label as short as possible to avoid line breaks. The maximum character length depends on the component. Explore your options directly in the design file.
Don’t repeat the field name in the error message, if possible (consider space constraints)
Put periods after full sentences.
Names are never wrong
Names are important. We don’t want to invalidate anyone by flagging their name as an error in a field.
Don’t blame or shame the customer with error messages such as Your name is invalid, Use your real name, or Enter your real info. Instead, refocus the message on the system (Our system is unable to…).
