Learn about the advantages and disadvantages of different treatments of the date of birth field.

Date of birth is a ubiquitous part of many registration and age verification processes. There are many valid date formats (“MM/DD/YYYY”, “YYYY/MM/DD”, “Month DD, YYYY”, etc.) and all of them can be entered through seemingly endless combinations of form elements. We wanted to find out which combinations of these resulted in the lowest user effort, fewest number of avoidable corrections, and highest level of data consistency.

This round of testing is also our first time using Mixpanel to gather analytics on user behavior in our form. We weren’t satisfied with the unreliable accuracy of the Mouseflow data we were seeing, so we’re taking the screen recording and heat-mapping functionality of Mouseflow and combining it with customizable, accurate event tracking from Mixpanel. In the tests below we set up custom Mixpanel events to track all of the time spent in the date of birth field(s).

Test A

9/19/2016

A single text field with no input restrictions other than character count which was limited to ten (numbers, letters, and symbols are allowed).

Methods
Date 10/05/2016
Sample Size 50
Recruiting mTurk
Analytics Mouseflow + Mixpanel
Demographics
Location United States
Average Age 34
Gender 50% Male, 50% Female
Tech Savvy 0% Strongly Disagree, 2% Disagree,17% Neither, 40% Agree, 40% Strongly Agree
WHAT WE TESTED

A single text field with no input restrictions (other than character count) or validation.

Responsive image
TEST RESULTS

We wanted to start by finding out what participants submitted without any formatting or data restrictions. The only rules they have to go off of are the MM/DD/YYYY formatting hints in the field label and the field placeholder.

Average time spent in this field was 7.59 seconds per user. Even though there was no validation on this field, 88% of participants submitted dates correctly formatted as MM/DD/YYYY. These are the invalid responses we saw in this test:

  • 0623/1970 (missed the slash between month and day)
  • 12-31-1970 (used dashes instead of slashes)
  • .2/07/1959 (probably mistyped “02”?)
  • 07/20/77 (left out the first two digits of 1977, probably)
  • 01121988, and 01121988 (no separator used)

Test B

10/07/2016

Automatic date formatting with input restricted to numbers only.

Methods
Date 10/07/2016
Sample Size 50
Recruiting mTurk
Analytics Mouseflow + Mixpanel
Demographics
Location United States
Average Age 35.3
Gender 36% Male, 64% Female
Tech Savvy 2% Strongly Disagree, 2% Disagree, 10% Neither, 54% Agree, 32% Strongly Agree
WHAT WE TESTED

After completing MM, DD, or YYYY, slashes are added automatically. Deleting a slash also deletes the character that came before it. Only numbers are allowed.

Responsive image
TEST RESULTS

Average time in the field dropped by about a second from 7.59 to 6.57 seconds. Unsurprisingly the accuracy of the data was also much improved with only one incorrect input of “19/69/”. This type of error could easily be fixed by adjusting the data validation that occurs at form submission, making it impossible to enter an incorrectly formatted date.

Using a single text field for date input like in this test has some pretty huge advantages in mobile browsers. By just declaring the type of data we’re asking for in our html by using type=”date” we can tell the browser to use the device's native date picker for this field.

Responsive image

Personally, this is our favorite way of entering dates on mobile devices, and we think supporting standards like thi—that provide shortcuts to consistent and performant user experience—is a responsible thing for designers to do. The combination of custom autocompletion/formatting behavior on desktop browsers, combined with the ease of use of native UI controls on mobile devices, make this option especially appealing. But we have a few other things that we want to try.

Test C

10/10/2016

Changed the month field to a dropdown with months listed by name as options. The “day” and “year” inputs each have a dedicated text field with input limited to numbers with a minimum and maximum character count of two and four respectively.

Methods
Date 10/10/2016
Sample Size 50
Recruiting mTurk
Analytics Mouseflow + Mixpanel
Demographics
Location United States
Average Age 35.39
Gender 42% Male, 58% Female
Tech Savvy 4% Strongly Disagree, 0% Disagree, 8% Neither, 54% Agree, 34% Strongly Agree
WHAT WE TESTED

A dropdown with months listed by name, and separate dropdowns for day and year.

Responsive image
TEST RESULTS

Separating each field into its own input element slowed down input a little bit (combined average time rose to 7.83 seconds), but this tradeoff in raw completion speed came with the benefit of data accuracy. We think the formatting requirements for this layout are much easier to communicate to the user without having to use placeholder hints like “MM/DD/YYYY.” We saw formatting accuracy of 100% to support this hypothesis.

This treatment of the date of birth field is much more similar to how someone (in America at least) would speak their birthdate. By using a dropdown with the names of each month in the first field, we’re communicated to participants that we’re interested in a natural month, day, year format without having to use coded language like MM/DD/YYYY.

Test D

10/11/2016

Using dropdown elements for the month, day, and year fields.

Methods
Date 10/11/2016
Sample Size 50
Recruiting mTurk
Analytics Mouseflow + Mixpanel
Demographics
Location United States
Average Age 34.25
Gender 38% Male, 64% Female
Tech Savvy 4% Strongly Disagree, 2% Disagree, 2% Neither, 50% Agree, 46% Strongly Agree
WHAT WE TESTED

Dropdown elements on each input with months listed by name, day options of 01-31, and year options from 1900-2016.

Responsive image
TEST RESULTS

The most immediately obvious benefit of this design is that the submission becomes extremely predictable. It’s now impossible for users to submit anything other than a date formatted as MM/DD/YYYY. Even better than that is that we’ve relieved the user of the burden of having to translate combination of M, D, and Y. Now users can just fill the required fields without having the think about formatting. The result of this is that the only way to get an error in these fields is to leave it blank.

The downside to this layout is that it takes a bit of time and effort to navigate in and out of each dropdown, which is reflected in increase in average interaction time to 10.8 seconds.

This test is the most extreme example of separating input elements for the sake of data consistency/validity but at the expense of usability. In test D we went in a different direction and experimented with a solution with minimal interactions but with minimal data gathered.

Test E

10/12/2016

A simple age field.

Methods
Date 10/12/2016
Sample Size 50
Recruiting mTurk
Analytics Mouseflow + Mixpanel
Demographics
Location United States
Average Age 34.04
Gender 36% Male, 64% Female
Tech Savvy 2% Strongly Disagree, 4% Disagree, 9% Neither, 51% Agree, 34% Strongly Agree
WHAT WE TESTED

A simple field asking for the user’s age.

Responsive image
TEST RESULTS

Unsurprisingly, we saw the lowest average time yet at 3.07 seconds on this test. The next fastest was test B (the single date field with auto formatting) which at 6.57 seconds took users an average of about 3.5 seconds longer to complete.

While we’re pretty satisfied to see that we were able to achieve such a low average time on this question, asking for a user’s age in this way does have a few drawbacks. For one, in a lot of instances it’s necessary to know the user’s actual date of birth (a service with age restrictions would need to know exactly when you turn a certain age, or they even may want to simply wish you a happy birthday when the time comes). Additionally, it’s hard to measure the validity or accuracy of the data entered in this field. We’re basically changing the question from, “Enter a valid date and show us that you’re being serious by following formatting rules,” to, “Enter any number.” It’s easy to see that someone is intentionally entering false information when they submit something like 11/11/1111, but it’s a lot harder when your data is simply “11.”

What we learned

Speed isn’t everything. The real goal is consistently high throughput with maximum data accuracy.

It’s tempting to conclude that we should champion test E’s design because it had the fastest completion time, but the tradeoffs in data accuracy and validity are too big to ignore. When asking for a user’s date of birth, we need to make sure we clearly communicate the format we’re looking for so that they can format and submit their information as quickly and accurately as possible. Asking for age doesn’t require coding or translation like date formatting does (MM/DD/YYYY vs. YYYY/MM/DD etc.), but we sacrifice confidence in our data validity and aren’t setting ourselves up with valuable long-term data.

For these reasons, we’re much more satisfied with the results from test B where we use a single text field with assistive formating on desktop browsers and the native date picker on mobile devices. This gives us the most control when it comes to input validation and is a familiar, ideal experience on both desktop and mobile devices.

Considerations

WEIGH EASE OF INPUT AGAINST INPUT VALUE

Asking for a user’s age is an opportunity to better understand the user now and into the future. By collecting only the user’s age we learn their age at that instant, and it doesn’t set us up well for knowing them in the future. For all we know they could be a year older tomorrow. In short, in Test E we asked an easier question which lead to reduced interaction times, but the value of the data we were getting from each user was drastically reduced. Test B did a much better job of balancing ease-of-use with high-value data.

LEVERAGE NATIVE CONVENTIONS

“Native” isn’t always sexy. It’s been done before and it may not compliment your design language, but in a lot of cases, it’s the first solution designers should consider. Rather than asking, “How can I make this interaction clever, memorable, or unique?” we should start by asking, “Is there a native pattern that does what I’m trying to do?” Native UI elements like the ones provided in iOS are, in many cases, a chance for free UX performance points. Designers should leverage them when we can, or be prepared to rationalize our decision to bypass them.

MORE FIELDS IS MORE WORK

This is more obvious, but in all of our tests so far we see that breaking one element into many adds time for processing and interaction on the user end. It’s not necessarily about the number of clicks but the level of effort associated with focusing on an escaping multiple fields.

Next steps

Stay tuned…