The user you designed for was never real

Somewhere in your process, there's an assumed user. Average height. Average grip. Average day, no crisis, no caregiver, no roadblock. That person keeps showing up in your specs, and they were never real to begin with.

Four projects this month, spread across hospitals, toys, safety gear, and public bathrooms, all point at the same gap. Different fields, same blind spot. Let me catch you up on what they expose and what to check in your own work.

The average person is nobody

The cleanest proof comes from a 1950 Air Force study. Lieutenant Gilbert Daniels measured over 4,000 airmen to find the average pilot so cockpits could fit him. Not one of them matched the average. Zero. His conclusion: "Any system designed around the average person is doomed to fail."

Designer Karen Korellis Reuther, formerly of Nike and Reebok, traces the damage this default causes. Female firefighters tape oversized gloves to their wrists. Their breathing gear sits wrong on their hips, knocks their helmets forward, and blocks their vision. They get injured at four times the rate of men. The old rule of using the 5th-to-95th male percentile still leaves out about 65 percent of women.

When you write "designed for the average user" in a spec, you're describing someone who doesn't exist. The margin where real people land is where the harm shows up.

A toy that stops telling kids what to do

Enzo Mari built the opposite instinct into a puzzle in 1957. His 16 Animali is sixteen wooden animals cut from one block, every edge shared with the next creature. There's a right way to fit them back in the frame. But once the pieces are out, a kid can stack them, scatter them, or turn them into a herd.

Mari watched how children actually learn, by handling things and repeating until it makes sense. So he gave the puzzle a fixed problem and then let the child walk away from it. The toy doesn't decide when play is done. The child does.

That's a design that trusts the person using it to have their own goal. Compare that to a product that assumes it knows exactly what the user came to do.

When the context is the emergency

Some users show up mid-crisis, and the design has to hold up there. Joud Abuhomos built Mesh-89 for Palestinian bus drivers who face 89 permanent West Bank checkpoints, only three of which show up on Google Maps. Her device shares checkpoint status over radio waves, so it still works when cell signals are jammed.

She designed the case as a glittery star to blend in with the keychains and gifts on a driver's dashboard. She calls it "cultural camouflage." It hides the device from confiscation, and it means the tech doesn't "arrive as something foreign." She built it because she lived it, waiting at those checkpoints herself in Ramallah until 2024.

The same lesson runs through Ukraine's first new modular children's hospital in Brody, built after a 100 percent surge in patients from wartime migration. Prefab modules cut build time by up to half, and rooms fit whole families. The user was a scared kid and a displaced parent, and the plan named them.

Small fixtures decide who can show up

Accessibility often lives or dies in the boring hardware. Koala Kare is designing fixtures for assisted care in public spaces, the adult changing tables and support gear that decide whether a caregiver and the person they help can use a public restroom at all.

That's the same edge Reuther keeps pointing to. The person who needs the fixture isn't rare. They're just outside the assumed user, so the building acts like they don't exist. A missing table is a closed door.

Check the equivalent in your product. The setting nobody QAs. The flow that assumes one able-bodied person acting alone. That's where you're quietly locking people out.

The deep cut

Here's the part that changes your Monday. The auto industry knows women are 73 percent more likely to be injured in a crash. Humanetics built the THOR-5F crash-test dummy based on a small woman's body. The industry is slow to adopt it, Reuther says, partly out of "unwillingness to admit past shortcomings" and the cost of fixing them.

So the block isn't data. You probably already have the data, or could get it cheap. The block is that fixing the default means admitting the old one hurt people, and rework costs money. Naming your real users is a decision your team keeps ducking because it's expensive, not because it's unknown.

Three questions for your team

1. Who is the "average user" in our current specs, and what real percentage of our actual users do they leave out? Put a number on it.
2. Which of our flows assumes one able-bodied person, alone, on a calm day? Name the setting we never test.
3. Where do we already have data showing a group gets hurt or shut out, and what's the actual reason we haven't acted on it yet?