Ask users for…

Most pattern libraries are keyed by screen: onboarding, checkout, settings. That works until you notice that the hard part is never the screen. It is the question. A date of birth is difficult in the same way whether it appears in signup, in a booking flow or in a hand-off to a clinic, and every team that meets it solves it again from scratch, usually with a date picker.

This family is keyed by the data being requested. Each page is one field: whether to ask for it at all, what shape the answer really has, what the edge cases are, and what the product owes the reader for having asked.

When to use

Open the page for the field you are about to add. Every page answers the same five questions in the same order:

1. Should you ask at all? Each page opens with the test, because the cheapest field is the one you do not collect.
2. What is the real shape of the answer? Almost always messier than the data model wants. Names are not two fields. Sex is not gender. A medication is not a string.
3. How should the control behave? Input type, autofill token, validation.
4. What do you say? The label, the hint, and the reason. In health, "why are you asking" is a reasonable question, and a refusal to answer it is a trust cost.
5. What does it exclude? Every field design excludes somebody. The pages say who.

When not to use

• You want the general behaviour of a form. How many questions per page, when validation runs, where errors go: Form design.
• You want the sequence. Where in the journey to ask is Onboarding and first run.
• You want the phrasing rules. Tone, reading level and sensitive wording are Content & language, and specifically Asking sensitive questions.
• The data is a reading rather than an attribute. A blood-pressure entry taken every morning is Daily logging.
• You want a legal answer. Nothing here is legal advice. Lawfulness of processing, retention and special-category data are your organisation's responsibility; see Regulatory context.

How it works

Every page runs the same gate before anything else.

flowchart TD
A["We want to ask for X"] --> B{"What decision changes if we know it?"}
B -->|"none we can name"| C["Do not ask"]
B -->|"a named one"| D{"Is a coarser answer enough?"}
D -->|"yes"| E["Ask for the coarser thing: an age band, not a birth date"]
D -->|"no"| F{"Can we get it later, in context?"}
F -->|"yes"| G["Defer to the surface that needs it"]
F -->|"no"| H["Ask now, explain why, and say what skipping costs"]

The second branch is the one teams skip. A great deal of health personalisation needs an age band and asks for an exact date of birth; needs a rough weight range and asks to the tenth of a kilogram; needs "does this person menstruate" and asks for a gender identity. Collecting the coarser thing is less intrusive, less sensitive to store, easier to answer, and usually more accurate.

Content

Three rules apply across every page in this family, and each page assumes them:

• Say why, next to the question. Not in a privacy policy, not in a tooltip. One sentence, at the field.
• Say what skipping costs. "Optional" with no consequence is not a real choice; see Required and optional.
• Never explain a sensitive question with a benefit claim. "To give you a more personalised experience" is what a product says when it does not want to say what it is doing with the answer.

Wording is owned by Content & language. Any clinical or administrative term the reader may not know is wrapped in Term, resolving against Plain-English A to Z.

Accessibility

Field-level accessibility is specified per page. What is common to all of them:

• A visible label on every control (WCAG 2.2 SC 3.3.2), never a placeholder.
• The correct autofill token where the HTML specification defines one (WCAG 2.2 SC 1.3.5). Do not invent one where it does not. See Autocomplete and input types.
• Errors in text, with a suggested correction where one is knowable (WCAG 2.2 SC 3.3.1 and 3.3.3).
• No re-entry of anything already given in the same process (WCAG 2.2 SC 3.3.7).
• Free-text escape hatches wherever a fixed list will not fit somebody's real answer. That is most of these fields.

Research

Updates to this page

Last read through against the system on 2026-09-20. Due for review every 12 months; expiry is reported by pnpm run check:freshness.