Inclusive design should target the specific ability or context, not use gender as the design variable

What it is

When a design needs to accommodate a difference in ability or context, the correct variable is the specific ability or context itself — hand size, color-vision type, available time-on-task, domain experience — not gender used as a proxy for those differences to branch the design. Even where a measurement shows a genuine physiological mean difference between the sexes (average hand length does have a measurable sex-based mean gap), measuring or offering an adjustable option along that dimension directly is still more accurate than guessing from gender: the variance within a gender group on that ability is typically far larger than the between-group mean gap, and designing by gender will systematically misfit the large number of users sitting in the "exception within their gender" position.

Why it happens

The statistical basis for this principle is that gender, as a binary variable, explains only a small share of total variance on almost every cognitive or preference measure — usually far less than the variance explained by the ability or experience variable itself. When the variable that actually determines the experience — hand length, color-vision type, experience level, current use context — is continuous or multi-valued but gets compressed into a crude binary label, predictive power is lost, and the true extreme users on that variable (a man with unusually small hands, a woman with unusually deep domain experience) get systematically misclassified, creating new usability problems. Designing accommodations directly against the underlying variable — adjustable target sizes, an optional color-vision-friendly palette, onboarding depth tiered by experience — covers the real distribution of that variable, instead of a crude and frequently wrong gender approximation.

Where it stops holding

This principle doesn't apply where the content itself is directly tied to biological sex — menstrual cycle tracking, prostate health reminders, and similar health-information contexts. There, biological sex is the direct referent of the content, not an intermediate variable standing in for some other ability or preference, so it falls outside the design-branching problem discussed here.

Applying it

• Replace any design specification that conditions an accommodation on "gender" with the ability or context variable it actually refers to: write target-size accommodation as a hand-size tier rather than gender, write color-palette accommodation as a color-vision-type option rather than a default palette assigned by gender, write onboarding-depth accommodation as a domain-experience level rather than assuming one gender needs more guidance.
• Prioritize user-customizable options (font size, color scheme, onboarding depth) over automatic branching by demographic attribute — customizable options cover a wider range, including transgender and non-binary users, in a way demographic branching logic cannot.
• Verification: audit the product's segmentation or feature-flag rules; if a "gender" field is found directly driving interface presentation or feature activation, identify the ability or context variable it's actually standing in for and replace it. Re-test key metrics after regrouping by that ability or context variable to confirm the design benefit genuinely comes from that variable rather than a coincidental correlation with the gender label.

Related

• Same group: A11.11.1 Between-group mean differences are far smaller than within-group individual variation, and cannot predict a single user · A11.11.2 Experience differences produced by social role division explain behavior better than biological sex itself · A11.11.3 Design decisions premised on gender stereotypes are often falsified on testing
• Adjacent: A11.06.2 Hand length, finger width, and grip dimensions
• Search terms: ability-based design · inclusive design · gender as proxy variable