---
title: "Ask users for height and weight"
description: "Compound units, a reader who may find the question difficult, and a derived number a design system should be very careful about showing. That number is BMI."
url: "https://opsinjs.pensievelabs.org/patterns/ask-users-for/height-and-weight"
source: "https://opsinjs.pensievelabs.org/patterns/ask-users-for/height-and-weight.md"
section: "Patterns"
kind: "pattern"
reviewed: "2026-09-20"
reviewer: "clinical"
aliases: ["height field", "weight field", "stones and pounds", "feet and inches", "BMI input"]
implements: ["reading-input", "value", "field", "disclaimer-note", "log-sheet"]
---
> Elements written as `` below are opsinjs documentation
> components. Their attributes are the content: the values they render are
> generated from `tokens/*.json` and `registry/catalogue.ts` and are
> published separately at https://opsinjs.pensievelabs.org/r/index.json and under the Reference
> section.
> Nothing is missing from this page. The data simply does not live in
> the prose.
## When to use [#when-to-use]
Ask for height and weight when a named calculation or a named piece of guidance
depends on them, such as a dose, a body-surface-area calculation, an eligibility
threshold, a chart the reader has asked to see.
Two things make this field harder than it looks. First, **the units are
compound and regionally split**: a British reader is likely to think in feet and
inches and in stones and pounds, an American reader in feet and inches and
pounds, and much of the rest of the world in centimetres and kilograms.
Handling only one of these is a correctness failure, not a localisation nicety.
Second, **this question is difficult for some readers**. Weight is the field
most likely to be abandoned, most likely to be answered inaccurately, and most
likely to cause distress to someone with a history of disordered eating. That is
a design constraint, not a footnote.
## When not to use [#when-not-to-use]
* **You want it for a chart the reader did not ask for.** A weight trend on a
home screen is a decision, and for some readers it is the wrong one. Make it
something the reader opts into and can turn off without losing the data.
* **You need a category, not a number.** If a dose band or an eligibility check
needs "over or under X", ask that.
* **Height for an adult, more than once.** Adult height does not change
meaningfully. Ask once, store it, allow editing, and never re-ask.
* **You want display rules.** Rounding and precision for the stored value are
[Numbers, units and precision](../../health/numbers-units-precision.mdx); the
unit systems themselves are [Unit systems](../../health/unit-systems.mdx).
## How it works [#how-it-works]
{`flowchart TD
A["We need height or weight"] --> B{"Adult height, already known?"}
B -->|"yes"| C["Do not ask again; show it with an edit control"]
B -->|"no"| D["Ask, with the reader's unit system defaulted and switchable"]
D --> E{"Compound unit?"}
E -->|"feet and inches, stones and pounds"| F["Separate fields under one legend"]
E -->|"cm or kg"| G["Single field, unit shown beside it"]
F --> H{"Physically possible?"}
G --> H
H -->|"no"| I["Reject, naming the accepted range"]
H -->|"yes"| J["Accept; store canonically, display in the reader's unit"]
J --> K{"Are we deriving BMI?"}
K -->|"yes"| L["Show its limits with it, or do not show it"]
K -->|"no"| M["Done"]`}
* **Both unit systems, always, with the switch adjacent to the field.** Not
buried in settings. A reader who has to leave the form to change units will
guess instead.
* **Compound entry is separate fields under one legend**, such as
"Height: Feet, Inches". Never use one field expecting `5'11"`. See
[Units and numeric entry](../forms/units-and-numeric-entry.mdx).
* **Switching units converts what was entered**, visibly. 12 st becomes 76.2 kg,
not 12 kg.
* **Bounds are physical, not typical.** Human height and weight span a much
wider range than a designer's intuition; rejecting a genuine value is worse
than accepting an implausible one, which can be confirmed rather than blocked.
* **Never require a weight to proceed** unless a calculation genuinely cannot
run without it, and if it cannot, say which calculation.
* **Do not congratulate, compare or editorialise.** No "great progress", no
target lines the reader did not set, no comparison to a population average.
See [Daily logging](../daily-logging.mdx).
### About BMI [#about-bmi]
If you derive BMI, three rules apply, and they are the reason this section
exists:
1. **Never show a BMI category as a clinical status.** "Obese" as a red pill is
the status axis being used to deliver a judgement about a person, which is
exactly what [The two colour axes](../../health/two-colour-axes.mdx)
prohibits.
2. **Show the limits alongside the number.** BMI is a population-level screening
measure derived from height and weight alone. It does not distinguish muscle
from fat, and its standard cut-offs are not equally applicable across all
populations. A number presented without that context will be read as a
verdict.
3. **Let the reader turn it off.** A reader who does not want to see it should
not have to see it to use the rest of the product.
If your product cannot follow all three, do not derive BMI.
## Content [#content]
"Your height" with Feet and Inches fields and a "use centimetres" switch
beside them. Reason: "We use this to work out your dose."
A single "Height (cm)\*" field with no alternative, so a reader who knows
they are 5 foot 9 has to look up a conversion.
"Your BMI is 27.4. BMI is a rough screening measure based only on height and
weight. It can't tell muscle from fat, and it isn't equally accurate for
everyone. Your clinician can tell you what it means for you."
A large "27.4 OVERWEIGHT" in the status palette, on the home screen, with
no context and no way to hide it.
## Accessibility [#accessibility]
* **No autofill token exists** for height or weight. `autocomplete="off"`;
prefill from the reader's own previous entry instead. See
[Autocomplete and input types](../forms/autocomplete-and-input-types.mdx).
* **`type="text"` with `inputmode="decimal"`**, never `type="number"` with a
spinner. The scroll wheel silently altering a weight is a real failure.
* **Compound fields are a `fieldset` with a `legend`**, so each part is
announced as "Height, feet".
* **Units are spelled out in the accessible name**: "Weight in kilograms".
* **A unit switch announces the converted value** as a polite status message
(WCAG 2.2 SC 4.1.3).
* **Errors name the bound**: "Enter a weight between 20 and 400 kg" (WCAG 2.2 SC
3.3.3).
* **Do not re-ask height.** WCAG 2.2 SC 3.3.7, and it is also simply rude.
## Research [#research]
The BMI rules are the substantive content of this page and they are stated as
design policy rather than as clinical guidance. What is not in dispute is the
mechanics: BMI is computed from height and weight alone, so it cannot
distinguish tissue types, and its conventional cut-offs derive from
particular reference populations. What is our opinion is the conclusion that
a design system should refuse to render a BMI category in the clinical status
palette, and that a product unable to show the limits should not show the
number.
Unit handling is not opinion. A product that accepts only metric or only
imperial will collect wrong numbers from readers who convert badly, and the
failure is silent.
What would change our mind on BMI: clinical review concluding that a specific
product's population and purpose make categorical display appropriate. In
that case a named clinician owns it, as with any threshold. See
[Reference ranges](../../health/reference-ranges.mdx).
## Updates to this page [#updates-to-this-page]