Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I am building a form that requires users to enter in their DOB. What is the best practice for this? I have identified 3 basic options:

  • Free Text Field Users are able to enter day, month and year in a free text field. During UT, I noticed that this caused some minor issues with users entering "81" instead of "1981" or users tended to look at the keyboard when entering data and not the screen so tended to enter in all fields then look up and notice that only the day field has been entered.

  • Drop down menu Users can select the day, month and year from a series of drop down menus. So drop down one is a list of 1 to 31, dropdown two is January through to December. This seems easier although the number of years in the final drop down is very long - 1920 to 1994

  • Date Picker Not really an option but I could present a date picker with a calendar icon where users can scroll through the months and years to select their date of birth.

So, which one is the best approach or are their any other ideas?

share|improve this question
3  
What's wrong with people entering 81 as their year of birth? It's unambiguous! –  Bennett McElwee Apr 22 '10 at 23:05
    
Thats a good point: do you want to know their DAY of birth or just how old they are to the nearest year ? –  PhillipW Dec 13 '13 at 19:02

11 Answers 11

When using a datepicker, you can tune it a bit based on your users. If your site requires at least age 18, you could have the datepicker start a [currentyear-18], making it easier for a good percentage to choose the right year.

If you use a single textfield (maybe combined with a datepicker), you can apply a mask to help the user enter the right format. Something like the masked input plugin: http://digitalbush.com/projects/masked-input-plugin/

share|improve this answer
    
This looks like a great solution, although I've yet to see good examples of it in the wild. –  Sam Murray-Sutton Nov 13 '12 at 13:46

The problem with free text fields is they are very easy for users to make mistakes with. Like you say, they may enter 81 instead of 1981. If your site is being used in different countries, then some users will write the day first, others the month first, etc.

I would think a date picker would require way too much navigation for the user to find their dob and would take too long (most frustrating). Date pickers work best for finding recent dates.

Drop down menus are what you see most often on web registration forms. They are generally less error prone as the user is limited by the available options in the drop down list. They take slightly longer to complete than free text fields but prevent more errors from being made. Remember that if you go with this option, it is best to state something like 'day' 'month' and 'year' within each field.

share|improve this answer
7  
I would disagree with your comment that free-text fields are easy for users to make mistakes with. Entering '81' as their year isn't a mistake, it is their version of the requested answer. In an ideal world the system should be able to interpret 81 as 1981. 81 would only qualify as a user mistake if they meant to enter 18. We should trust that the user knows their own date-of-birth and then let the system deal with the formatting of their answer when it actually writes to the database. Perhaps after a user enters their 10\02\81 we could display below the field as "10th Feburary 1981"? –  JonW Apr 23 '10 at 10:25
    
I agree with Jon, but I also wanted to add that I disagree with your last paragraph. I see ordinary text boxes for birth dates nearly as much as I see drop downs. Plus, a drop down for birth year is hardly user-friendly - you've got to have well over 50 values in that drop down, which is not a good experience at all. –  Charles Boyung Apr 28 '10 at 13:34

One more way is the text field which is smart enough to understand different formats. User may type in "21 apr 1981" or "4/21/1981" or "21.04.81" or something else. Usually it's not so hard to parse. As an example WolframAlpha understands all this correctly. Of course sometimes you may face an ambiguity (like 01.02.1981 -- is it February 1 or January 2?). In this case you may give user options to choose from or automatically choose one and display a warning.

And I'd recommend to take a look at some other questions about date picking:

share|improve this answer

A free text field with an example is clear, and quick and easy for people to use.

               ________
Date of birth |________| (example: 31/5/1970)

Dropdowns could be all right for day and month, but not year. It's probably easier to type a four-digit year rather than scroll all the way down to 1950-whatever. The only real benefit of dropdowns is that they enforce the ordering of day and month. But they are a little clunky to use compared to typing.

share|improve this answer
3  
I would expect more user typos with this method. You're assuming the user will look at the example, rather than assuming that whatever they usually use at their locale will work. –  Cyrena Jun 2 '11 at 15:34
    
My idea is to make the entry process as simple as possible for most users. I don't mean to assume they will look at the example, but if they do then it may help. If the application caters to users with different date conventions then we could detect their location and adjust the date format and example appropriately. Apart from the format, I would expect people to rarely make mistakes typing their own birthdate. (You'd want to test this if accuracy is critical.) It's not foolproof, but it will offer a quick and simple experience to the vast majority of users. –  Bennett McElwee Jun 7 '11 at 5:39
    
Shortly after text entry, parrot the date back to the user in parsed form. This confirms understanding. –  Alex Feinman Aug 15 '12 at 13:27
1  
@AlexFeinman: or even instantly while user is typing –  peterchen Dec 12 '13 at 15:26

The one that I consider to be most accurate (i.e. no user mistakes but still easy to complete) is: - Date free text - Month drop down (January, February...) - Year free text (accepting either 2 or 4 digits)

Now, I realise this flies in the face of "don't mix your mouse and keyboard" but honestly after years of testing web forms with users this works best. And that old rule becomes less relevant anyway as people move away from mouses. Date pickers are great for dates close to today; full drop downs are an ugly compromise; full free text leaves you open to user error.

share|improve this answer

We use a simple, single text field with an example instruction, just like Bennett suggests.

Date of birth |________| (example: 31/5/1970)

However, we also add another element onto the page, which we call a Field Reflection pattern. The form takes whatever they entered into the field, and then dynamically parses and interprets it, and reflects the information back in a slightly different form. For dates, this means taking "31/5/70" and displaying "Sunday, 31st May, 1970".

Calculating the day of week is a small delighter we add in there just for fun. We have found that putting the day of week did result in more people paying attention to the display, and thus catching any errors more often.

share|improve this answer
1  
I really like this idea. There's no reason it couldn't be used with the calander picker or any other existing date entry suggested in this thread, but by displaying the date as you're entering it is a really nice touch and gets around the whole UK/US format issues. –  JonW Dec 1 '11 at 17:20
    
Thanks. We also use the Field Reflection pattern for Biller Code or Bank SWIFT codes. –  Erics Dec 2 '11 at 0:01

From what I've experienced, it depends on the project. I've had projects where the users had no issue with a standard textbox with a hint or example while I've had projects that tested better with 3 dropdown lists despite the length of the year options.

So ultimately, test if you can.

Beyond that I have came the following starting rules:

  1. If data accuracy is critical to the system - dropdown boxes lead to better accuracy at the expense of usability due to long option lists.

  2. If users are wary of providing date of birth - use a single textbox with an accessible hint that masks on blur. Alternatively, question the requirement to see month and day are truly required.

  3. All others - single textbox with an accessible hint.

share|improve this answer

I'm constantly impressed with the date entry field on the www.rememberthemilk.com site. It's a single field, you can enter the date in almost any method you can think of and it translates it for you. (15/12/2011, "15th December 2011", 12/15/2011, "next friday", "fri 15th december"...) and on entering it will translate what you've entered into a readable format "Fri 16 Dec 11" so you can confirm it's correct.

If the date you enter isn't valid (such as entering Friday 15th December) it will take a stab at it for you (in this case setting it to "Thur 15 Dec 11") and you can easily amend it.

It also detects if you've entered it in an obvious US format (12/15/11) and chooses the correct date of 15th December 2011.

It's a really impressive piece of coding there, you actually have to go out of your way to get it to pick a wrong date.

share|improve this answer

In our application, we wend for this solution:

The date widget is normal, free-form line edit widget. You can enter anything you want. As soon as what you have typed is somehow recognizable as a date, the found interprettation(s) of the data are displayed in a dropdown-like list under the widget. These interprettations are displayed using full years and full month names, and ordered in order of likelyness. The widget can be constrainded to only suggest specific date ranges. That way if you type 31 as the year for a birthday, 1931 is suggested instead of 2031. The user can click any of the suggestions to choose that interprettation. Inversely, in a widget used to plan a future appointment, the dates in the immediate future would become the likely interprettation.

Of course, the system locale is used to determine what the most likely interprettation of the entered date is, what month names and abbreviations are used and what the acceptable format for displaying the interpretted dates is.

When the focus leaves the date widget, whatever was entered by the user is replaced by the most likely interpretted date, or a cursive message like "No date selected" or "Invalid date". When the focus returns to the widget, the text is again what the user entered there in the first place.

Of course, the rules for interpretting the date are quite loose. Different separators are accepted, as well as not using separators at all. Clues to what field is what are used if they are available (like abbreviating the date to two digits, but using a ' for the century part would hint that that part is a year, or using 'th' 'st' 'nd' or 'rd' behind a number would hint that that part is likely a day number). Months may be given as a number or as a name, optionally abreviated to the shortest unique abbreviation for it.

All in all, this makes for a date entry widget that is very flexible from the users point of view, and is fast to use.

share|improve this answer

Use inline inputs or drop-down date ranges over calendar UI widgets.

Our eye-tracking UX sessions quickly identified how users don't know how to interact with date pickers.

share|improve this answer

Actually there are three valid options, and you can choose the right one for your audience by a simple AB/C Test. (it really depends only on your users)

I saw many tests in which results pointed to one of the three options below, and as long as you remember to keep the dd/yyyy as simple input fields (any other solution will bring up challenges and problems for your users) you can't go wrong.

Date of Birth Chooser

This example illustrates the right order of fields only for some countries*

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.