Cancel button
Cancel button

Fields

Content at Intuit

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

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…).

go to top
Link copied