The Default User Is Not Neutral!
Most product decisions rest on an assumption we rarely examine: that a “general” user is a neutral starting point. In practice, this default user often carries an implicit shape, one that research on product design and public health data tends to skew male, urban, and able-bodied, even when no one intended it that way.
Caroline Criado Perez mentions this in Invisible Women, tracing how data gaps across medicine, transport, and technology consistently under-represent women, not through malice but through habit. This is worth pausing on, because habits are harder to notice than decisions.
A decision gets reviewed. A habit gets repeated.
A small example with a larger pattern :
After an online health consultation, I received a notification: “Your prescription is ready. Tap to view.” Clear and practical, exactly what a notification is supposed to do.
Then it occurred to me: what if this were not my phone? In many households, devices are shared, and a lock screen can light up in a room with other people present. A notification about a prescription can reveal a pregnancy, an STI treatment, or a mental health diagnosis to someone who was never meant to see it.
The assumption here is not about gender directly. It is about privacy, and it assumes a user with full control over their device. That assumption holds more often for some users than others. A simple rewrite, “You have an update on your recent visit,” preserves the function while removing the exposure.
The fix is not complicated. Noticing the need for it is the harder part.
Get Aditi Deshpande’s stories in your inbox
Join Medium for free to get updates from this writer.
Why gender is not a separate category?
Gender-related concerns are often treated as a niche addition, something after the “real” requirements are settled. This misses the point. Gender is not a separate feature. Applying this lens doesn’t mean designing separate products for different genders. It means asking a consistent set of questions during design, the same way we already ask about accessibility or localisation.
A few proven useful in my own work:
Shared context: Could this screen expose sensitive information to someone other than the intended user?
Default body: Do our illustrations or questions assume one type of body as standard?
Consent clarity: Do we explain why we ask for sensitive data, rather than simply asking?
Necessity: Is this data point required, or collected out of habit?
Risk specificity: Does our privacy messaging address particular risks, rather than generic reassurance?
These questions require no additional budget or new personas, only a shift in what counts as a requirement.
Looking ahead
As products increasingly handle sensitive personal data in health, finance, and safety, the cost of unexamined defaults grows. The goal is not to design differently for different genders. It is to design with enough awareness that the people most affected by our blind spots are no longer invisible in the data we use to make decisions.
