Design a Date-of-Birth Collection Flow for Meta's Apps

Meta wants to capture each user's date of birth. Walk through how you would design and roll out that capability. ```hint Start from the purpose The reason Meta wants the date shapes everything else: who has to be asked, when, how accurate the answer must be, and what happens when someone declines or gives a false date. Settle the purpose before sketching any screens. ``` ### Clarifying Questions - Is this only for new sign-ups, or must existing accounts that never gave a reliable birth date be covered too? - Which apps are in scope: Facebook, Instagram, Messenger and Threads through a shared account layer, or a single app first? - What will the date be used for: legal minimum ages and teen protections, age-restricted advertising, birthday features, or all of these? - Is a self-declared date good enough, or must some users' ages be verified? ### What a Strong Answer Covers - The purposes behind collecting a birth date and how each one sets requirements for coverage, accuracy and precision. - Capture flows for new sign-ups and existing accounts, including input design, handling refusals and spotting obviously false dates. - Age assurance beyond self-declaration for high-risk cases, and the privacy cost of each method. - How the date is stored, shared with other systems, shown to other people and changed later, consistently across apps. - A rollout plan and metrics that weigh coverage and accuracy against sign-up friction and drop-off. ### Follow-up Questions - Some users pick the first option in each dropdown or an implausible year just to get through. How would you detect and handle inaccurate dates at scale? - An account that claimed to be an adult is later flagged as probably a young teen. What happens to it, step by step? - How does the design change in a country where teens below a certain age need parental consent to sign up?