Birthday Picker
Try this on your phone. Open a sign-up form that asks for your date of birth with a calendar widget, and enter a birthday from 1985. You'll tap the back arrow past this month, last month, the month before that, and keep going for a while. Roughly 480 taps if you're patient enough to do it one month at a time.
A tiny date field with a big drop-off: listen once, never design it the slow way again.
Listen to the full Birthday Picker course on DesignPath
Now do it with three dropdowns instead. One list of 31 days, one of 12 months, one of about 100 years, each opening a spinner that covers half the screen. Three separate hunts for a number you knew the whole time.
This is the field everyone assumes is trivial. It's the one that loses sign-ups, because it looks error-prone, so designers reach for the control that seems to prevent errors, and that control turns out to be the problem. As Vitaly Friedman puts it, a form input that is hard to use returns less accurate data and produces more errors. That is the exact opposite of what the fancy control was for.
The fix is almost disappointingly plain, and the interesting part is why it works. A birthday is a number people recall, while a booking date is one they discover, and those two jobs need completely different controls. Get that distinction right and this stops being a trap. Get it wrong and you've built a small maze in the middle of your form.
Anatomy of a Date Field
Before any control is chosen, a date field has a shape, and the shape is decided by what the product actually needs to know.
How Much Date You Need
Three answers, and they lead to three different fields.
A full date is needed for a legal record, a medical note or anything that has to match a document. A year alone answers most age questions and asks for a third of the information. A yes or no answers an age threshold without storing a date at all. Article 7 argues which of the three you are entitled to, and the point here is that the field cannot be designed until somebody has answered it.
The Four Candidate Controls
Every birthday field in existence is one of these.
A native date input, which the browser or phone renders. Three dropdowns for day, month and year. Three text inputs doing the same job. And a calendar widget, drawn by the product. Articles 3 and 4 take these apart and score them. The useful thing here is that the list is four long, and the argument is always between the same four.
The Parts of the Field
Six, and two of them are instructions to an engineer rather than pixels.
The question, which is one label rather than three. The three components, day, month and year. The format hint, showing what shape is wanted. The valid range, which is what stops next Tuesday being a birthday. The input mode, meaning which keyboard opens on a phone. And the autofill hint, which lets a browser that already knows the date fill it in one tap.
Recalled or Discovered
One property separates a birthday from every other date a product asks for.
A birthday is recalled: the person already knows it and only has to type it. A booking date is discovered: they are working it out, comparing options, checking what is available. That difference is what decides between typing and a calendar, and article 6 runs the test in full.
Pro tip: Ask the team what happens to the date after it is submitted. If the answer is that it is stored and never used, you have found the argument for article 7 before designing anything.