Reflecting on International Women’s Day, I’ve been thinking about how often “good design” quietly assumes a very specific kind of user — and how often women (among others) are expected to adapt instead.
That quiet adaptation is something many women are deeply familiar with.
In products.
In systems.
In workplaces.
When something doesn’t quite fit, doesn’t quite work, doesn’t quite consider you — you compensate. You adjust. You work around it. And eventually, you stop expecting it to change.
I’m a Solution Architect. I design systems for a living.
Which means I spend an unreasonable amount of my time noticing when things are badly designed.
Some of this is professional.
Some of it is personal.
Most of it is deeply irritating.
Packaging that can’t be opened without either brute force or sacrificing a nail.
Battery compartments where batteries go in easily… and then appear to become part of the product forever.
Websites that assume everyone can see, hear, read small text, and use a mouse with flawless coordination.
None of these are catastrophic failures. But they are constant. And they all point to the same underlying issue:
This was designed for “a user”.
Just not a very broad one.
Let’s talk about the everyday stuff.
Recessed buttons that require a paperclip, a pen tip, or a quiet moment of regret.
Power tools clearly designed for people with very large hands — where you physically cannot hold the tool and reach all the controls at the same time.
Kitchen handles that look stunning in a showroom, but become slippery, awkward, or mildly dangerous the moment you’re actually cooking.
These things weren’t designed badly.
They were designed narrowly.
Someone tested them. They just didn’t test them with anyone who ran into these problems — and nobody thought that absence might matter.
And that absence is rarely random.
Blind spots in design are often shaped by who is in the room — by gender, by physical ability, by cultural norms, by whose discomfort has historically been treated as “just the way it is.”
Cars are a particularly special case.
At some point, dashboards decided physical buttons were passé. Touchscreens were cleaner. Sleeker. More “modern.”
As an architect, I understand the appeal of simplification.
As a driver, I’d quite like to adjust the heating without taking my eyes off the road to navigate three layers of menus.
Removing tactile buttons means replacing muscle memory with visual attention — which is a bold choice in a fast-moving metal box.
It looks great in a demo.
It performs terribly in real conditions.
This is what happens when design optimises for aesthetics and trends instead of how things are actually used — and by whom.
Shoes are another good example.
Many heels used to include steel reinforcement for support. Now lighter, flimsier materials are common — which means heels flex, weaken, or snap. The wearer compensates. The failure is normalised. The design decision goes unquestioned.
The expectation to compensate becomes built in.
This pattern shows up everywhere, including software:
By the time these issues surface, they’re “edge cases.”
By the time they’re discussed, they’re expensive.
And by then, the people affected have usually been adapting quietly for years.
Most poor design choices aren’t made because someone doesn’t care.
They’re made because everyone in the room has similar assumptions, similar experiences, and similar blind spots.
So the product works — just not for everyone.
And the people it doesn’t work for?
They become friction.
Support tickets.
Exceptions.
“Outliers.”
Not users worth designing for.
When we talk about diversity in tech, this is part of what we mean. Not optics. Not slogans. But reducing the risk that entire groups of people are silently designing around limitations that never should have been there in the first place.
This is why diversity in product and software design actually matters.
Better representation leads to better questions.
Earlier challenges.
Fewer “how did we miss that?” moments.
Good architecture doesn’t just scale technically.
It scales across people, contexts, bodies, and real-world use.
It feels like a good moment to ask: