Asking a user for their date of birth isn’t something I take lightly! I always try to reduce the information required from users to a minimum.
For the purpose of this case study, I’ll not go into the reasons why and when to ask user’s for their date of birth but focus on how we ask them.
The date of birth field currently has 3 select menus for day, month and year. During our usability studies this has been highlighted as a frustration, having to pick 3 values from a multitude of options was causing friction - more commonly on mobile.
After a review of the application, we highlighted some areas where select menus had been misused. I defined the criteria for correct usage…
- Less than 5 options, should consider using radio buttons.
- More than 15 options, should consider a searchable drop-down with auto-complete.
With these rules in mind we decided to re-design the date of birth field.
We decided early on that the control should be consistent across devices for two reasons.
- We wanted a consistent experience for our users, knowing from our research that candidates were completing user-flows in a multi-device manner.
- Keeping maintenance low from a development perspective. Maintaining one control made sense.
There is also the cultural aspect. Different countries have different formats for the date, whether it be the order of day, month, year or the type of separator used. This control was going to be used globally.
After some research and prototyping we came up with 4 solutions.
Having 3 text inputs for day, month and year meant that we could have a consistent experience across devices and give them enough visual clues to get enter their date of birth easily enough. With some validation to prevent errors this isn’t a bad option. Although this solution tested well with users, moving between inputs on mobile was tedious.
Inputs and select menus
This solution was to offer a text input for both the day and year, with a select menu for the month. The thinking here is that the month select menu has a manageable (although on the high side) amount of options, 12. Where as the day and year inputs, have too many options for a select menu to be usable. As with the previous solution.
For sure we knew we needed to reduce 3 fields into 1. A date picker is a good way to guide the user to a specific date and also ensure standard formatting. The issue we found was the fact that our average demographic were in their early 30’s. Meaning the year on date picker would have to be rolled back 30 years from today’s date, not good. Of course, we could cater for that by defaulting the year to something that’s average. But for the non-average users, that’s very confusing.
This is where we found the most potential and ultimately, our final solution. We felt users should type their date of birth without a date picker. With a clear label, placeholder and supporting help text we should be able to guide the user through entering their date of birth without confusion.
But we still had to get over the hurdle outlined in the second constraint. The cultural aspect. How do we deal with differing formats? How do we define the correct separators?
We decided to use the user’s IP address to determine their local date format. This allows us to serve the user with a control that is asking for a date in a format they’re familiar with.
We also decided to introduce input masking, this prevents the user from making any typos and will also give us the standard separator and format that you can achieve with a date picker.
Here are the masking rules:
- Any non-numerical keystroke used in the day, month or year positions will be prevented.
- Any keystroke between the day month and year will produce the separator.
Here is the HTML prototype supporting British English, US English, Japanese and Spanish.