Date-Input Form Fields: UX Design Guidelines

Formatting a date-entry field may seem like a minor detail; however, even small interactions can draw a process to a standstill if implemented improperly. Poorly designed date input leads to distressed or annoyed users — risking the abandonment of the form altogether. Even worse, if the user specifies the wrong date, the entire transaction could be a disaster -- think, for example, how you'd feel if you showed up at the theater excited for a new show, only to discover that you bought tickets for a different day.

Considerations for users on mobile devices and for global audiences must be taken into account to improve this small, but fundamental input. This article discusses common input patterns, error handling, and international input for date fields.

Date-Input Patterns

Calendar pickers are control elements that display a full calendar month at one time. They typically show the days of the week across the top and match the metaphor of desk or wall calendars.

Calendar pickers should be used for events close to the present time — within less than a year. However, they can be frustrating for users who choose dates far in advance because they require too much navigation to get to the desired input; for these users, it would be faster to simply type the year.  

Calendar pickers are especially useful for selecting a date range. In those situations, they often display two months side by side.

• Scrolling date pickers on mobile devices are common, yet they can be annoying if the picker contains many dates. In those situations, scrolling in a small space is slow and unproductive; it’s better to allow users to type the date directly.
  
  In the Todoist app, users can enter the deadline for each task using an endless scrolling list. This is not an issue if the deadline occurs on that Friday or Saturday, as shown below, however, if the deadline is even a few weeks away it is easier for the user to type the date instead (a functionality that the app also provides).

   

  

• Split date fields with drop-downs for month, day, and year require a lot of unnecessary steps. This method increases interaction cost by adding additional clicks and scrolling. We advise against using this pattern.

  

• Typing the date is the most basic option for date input, yet in many cases it is the most efficient one, especially when the date is further away in the past (e.g., birthdate) or future. We recommend that you allow users to type the date even if other input methods are available.

Date-Input Design Guidelines

• For a limited number of date options, provide a list of the applicable dates.
  In some cases, users will have only few date choices. For example, Google Express, an online shopping service, makes it possible for customers to order groceries online and schedule a delivery time. Rather than offering blank date fields or a calendar picker of limitless options, Google Express provides a short list of date options. Any dates that are unavailable have been grayed out and disabled. (Alternatively, unavailable dates may not even be included in the list.)

  

  In general, we don't recommend this method when there are more than 10 dates available however, as it can become tedious for people to scan and scroll through the list of dates.

• Do not require users to enter special characters to format dates.

  Whatever format users chose for entering the date (dashes, spaces, slashes, dots between the month, day, and year components), their input should be recognized. Moreover, leftmost zeros should not affect the date. In the Priceline example below, the date 9-3-17 is rejected and 09/08/17 is accepted, although no format requirements were visible before submitting the form.

  

• Report errors appropriately.
  If a user enters a date that is obviously a mistake, such as 11/81/17, do not make any assumptions. Give the user feedback and provide suggestions on how to resolve the error.
• Remove illogical date options.
  Prevent users from selecting illogical dates. Obviously, what’s reasonable will depend from case to case: for example, dates older than 130 years will be unlikely for birthdates, but quite acceptable for document dates. Users should be prevented from entering a return date that takes place before the departure date or that is in the past. Make the choices clear by disabling and graying out options that are not available or are illogical pairs.

• Preserve users’ work.
  If the same date information is required in a separate part of the form or later during a task, then don’t make users enter that date twice.
• Keep date ranges consistent.
  Avoid shifting date ranges for departure and return pairs. For example, if November—December is shown for departure, do not shift and show December—January for the return date range. The change may go unnoticed and cause users to slip by clicking where the intended date used to be.

  

• If your site caters to international users, your date format should be clear and understandable.

  Date-entry fields are culture dependent, and can cause major problems for those users who are accustomed to a different format. “10/11/2016” could mean 11^th of October 2016 to an American, but November 10^th to someone from Europe. Follow these rules of thumb when designing date input for a global audience:

  • Add labels and separate the fields to make it clear which fields are for the month, day, and year.

    

  • Spell out the name of the month to distinguish it from the day.

    

    

  • Utilize calendar pickers with clearly spelled out names for months.

    Some frameworks, such as Bootstrap, provide calendar pickers to support unambiguous date selection.

    

    

Conclusion

Date-input patterns are not created equal. Implement design patterns that are appropriate for your context. When designing date-entry fields support text input and consider whether or not you have an international audience. Avoid designs that are ambiguous because they can cause people to become frustrated and annoyed with your site. Follow these guidelines to prevent form abandonment and catastrophic errors.