Following one of our geekier team debates, I recently did a deep-dive into the most usable UX and UI design pattern for a date-of-birth form field and was really surprised to find that existing research and best practice is not, apparently, reflected in the UI toolkits put forward by Material Design or iOS 14.

What is the problem we’re trying to solve?

Date of birth. We only really want to capture three pieces of data; day, month, year — what can the problem be?

Simples. There are too many different form field and data capture options available to designers, not to mention those designers or devs who are not into following accepted design patterns and prefer to make up new and exciting things out of thin air. As a result, one can easily encounter products that have entirely new Frankenstein UI or interaction formats, for seemingly non evidence-based Reasons.

This is unfortunate when we know that following patterns creates a sense of familiarity for users, which improves usability and decreases user error, stress and inaccurate data capture.

Design patterns and problems encountered

As described above, we are capturing consistent data points in the DOB form fields . Though admittedly, those are captured in different ways depending on the country.

Day (DD), Month (MM), Year (YYYY)

Month (MM), Day (DD),Year (YYYY)

If anyone’s ever done local market adaptation of an existing interface, you know this is one of the first things you fix.

Date picker

In this example, the user is presented with MM/DD/YYYY (or local market variant). How can we be sure that the user is going to know what these letters stand for? Yes we know it’s an “accepted” design pattern.. but do the users know this?

Humans always surprise us. Never assume. That’s why user testing exists.

Material Design — Mobile date pickerMaterial Design — Standard text form field

And.. do users know that they need a leading 0 at the beginning of a single digit entry? I’ve seen plenty of “user error” in testing to suggest.. maybe they don’t. Sure, they’ll get there eventually if you’ve set your error states correctly, but is that really the best user experience?

Drop downs

Drop downs are great when there are a limited number of options to choose from, but for DOB it’s challenging. The oldest living person is 117 years old (at time of writing).. that’s a lot of scrolling and interaction cost on that “year” drop down.

Also FYI, for those of you too young to have experienced this yet, scrolling back through more than 30 years starts to make you feel REALLY old.

Form field + drop down

If you feel drop downs are wrong for “year”, you could decide to use text field for year, and drop downs for the other two.. but what genuine benefit is it bringing to the user? Remember, having two different interaction styles in the same form item adds to cognitive load and increases likelihood of user error.

This is a great example of solving part of the problem at a micro-level, only to create a new one in terms of overall design pattern comprehension.

Such an example was tested as part of an iterative research study by Gov.uk. As you can imagine, it was not the winning variant. And as expected, findings showed that having two interaction patterns as part of the same component confused users and increased the likelihood of user error. As was seen in this study. Yay science.

Incredibly helpful that they tested this for us however! 🙏

Pattern tested as part of Gov.uk research (https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/)

Calendar picker

Most people (literally) weren’t born yesterday, so using a calendar date picker for DOB may involve lots of tapping back through previous decades (see also reference to contemplation of your impending demise described above).

Calendar-based date picker — best for ranges and dates close to the current

So the calendar picker pattern is generally recommended for events close to the current time, and for a date range. For example, you’ll see them a lot on flight ticket and holiday booking sites.

Select menus — bad

Both of these are “select” menus. Advice seems to be not to use select menus if the user knows the data already — i.e. they don’t need to be provided with a list of available options.

Extract of Google Material Design (https://material.io/components/date-pickers#mobile-pickers)

Scrolling increments of insanity

The other design pattern I’ve seen in the wild is a native scrolling UI to select options. This however can result in some quite bizarre options and increments depending on who is making those decisions on behalf of the user, such as this example of the Sleep Cycle app.

Sleep Cycle. Scroll through every day, 5 minutes.. at a time..

False assumption

All of the above are based on the false assumption that it will be more effort for the user to type the date, than if we provide useful pickers for them.

As a designer I get it, you are trying to be helpful. But the user only needs to choose from prompted options if there is a) more than one option per field and b) they don’t know off the top of their head what it could be.

In this case, the original assumption was wrong, therefore no matter which pattern you choose, you’re still going to be wrong.

Side note: Although humans generally only have one date of birth to input, there are exceptions. When I worked on a car insurance comparison website, one of the key users behaviours was ‘running multiple searches with different dates of birth’. See.. humans are odd. Do primary research.

So what is the best solution?

Fortunately, various other clever UX bods have done the research for us and we have an answer.

And this answer is backed up by gov.uk research and in fact the only date component listed on the U.S. Web Design System (USWDS).

Separate number fields with full labels

The research which tested a number of iterations with a range of actual live users concluded that just having three separate number fields, with text labels assigned was the most usable pattern for humans.

Why was this?

In this case, desktop users were able to tab easily between form fields and enter the knowledge that is already in their brains, and mobile users could tap and do the same. There was no additional interaction cost for this as users did not have to search and interface for a number they already knew.

Additionally, this pattern reduces potential for user error and increases accuracy of data capture. Because without additional menus or scrolling, users are less likely to accidentally select a wrong number. Also, with a small difference in form-field width, we’re layering on an additional signifier that “year” is more than 2 characters in length.

Interestingly, this is a pattern that doesn’t seem to exist in Material Design or iOS 14 as standard. Material Design offers calendar picker or a date picker with DD/MM/YYYY format, which as above, though better than a drop down, can still cause confusion.

Evidence helps

This is a nice example of where best practice is directly based on documented research for this exact use case.

This is not to say you shouldn’t keep an eye out for new ways of designing (and testing) DOB patterns, or still user test your form with your users (because your audience and your product will have unique and unpredictable attributes) but you can at least remove the assumptions and guesswork from this component for your first iteration.

Resources:

Gov.uk research https://designnotes.blog.gov.uk/2013/12/05/asking-for-a-date-of-birth/

Nielsen Norman Group on form fields

US Government component library on DOB fields

Material Design date pickers guidance