When Your UX Only Fits Two Sizes

A few years ago, right before the pandemic hit, I was trying to buy clothes online. Nothing fancy, just basic stuff, trying to get rid of my old "nerdy" t-shirts and work on different styles. "Queer Eye" got me with all those tips, you know the drill.

And while I looked at the outfits, I started to notice a pattern across multiple stores: the navigation had "Men's Clothing" with dozens of subcategories, "Women's Clothing" with even more subcategories, and then, sitting there on the menu, separate from everything... "Plus Size."

Just "Plus Size". No gender. No subcategories. As if being above a certain weight, or having a body out of the norm, erased everything else about me. According to these stores, I could be a man, a woman, or just... fat.

Someone designed that. Someone coded that. Someone approved that. And probably nobody in the room thought twice about it.

The interface is the message

@jess recently wrote something that stuck with me:

as developers, we're responsible for the interfaces the world lives in, and we have the power to build systems that refuse to force people into categories that don't fit.

And.. she's right, I love it when someone finds the exact words for an idea I've been circling around but couldn't articulate. But I think the problem goes deeper than that: Most of the time, we're not actively forcing people into bad categories. We're just not thinking about them at all.

I wrote about this last year, where I talked about my own experience as a left-handed, neurodivergent person working in tech. How being outside the norm gave me a different lens on design and problem-solving. But that was about perspective. In this context, we are talking about something more concrete: the actual decisions we make every day when we build things.

Every dropdown menu can be a decision about who we believe has the right to exist and who is being seen by us. Every form field is a statement about what matters. Every category in a navigation bar is a tiny act of world-building, whether we actively thought about it or not.

The "default human" problem

More than a decade ago, while working as a Tech Lead at an agency, a client reported issues with their site. It worked for us, so I did the basic investigation, and he used Internet Explore on Windows. When reporting it to the team, they complained about having to fix the issue, saying, "Who still uses Windows these days?"

It was 2012. Windows and IE still dominated the browser landscape. In an agency loaded with MacBooks, they couldn't understand anything out of their reality.

I like to tell this story whenever a discussion about development and design decisions arises. Most developers don't think about it because they've never had to: when you design a system, you're designing for a default human. And that default human is usually someone who looks, thinks, and lives a lot like you.

If your team is mostly young, able-bodied, right-handed, neurotypical people from similar backgrounds, your "default human" is going to reflect that. Not exactly out of malice, but by blindness.

Color-blind users get crushed by red-green status indicators because someone on the team thought "red means bad, green means good" was universal.

Screen readers choke on websites because someone decided that a div with an onClick handler was "basically the same" as a button.

Neurodivergent users get overwhelmed by interfaces full of elements, or where the elements don't have clear precedence, and it isn't clear what to do next.

None of these are edge cases. Color vision deficiency alone affects roughly 8% of men worldwide. That's not a niche demographic. That's a significant chunk of your users that you're ignoring because you never tested with them.

It's not about good intentions

I've been building things for the web for over twenty years. Obviously, I've shipped code that was exclusionary without knowing it. We all have at some point in our lives. And the point of this text isn't to make you feel guilty about it.

The point is to stop treating inclusion as a feature request.

Accessibility isn't a sprint item you add after launch. Inclusive language in your UI isn't a "nice to have." These are architecture decisions. They belong at the start, in the planning phase, when you're sketching out user flows and database schemas. Not bolted on six months later when someone files a complaint.

My first job had more women than men, so I could better understand the differences in treatment. Smart women being judged by their looks when they could run whole departments if they had the chance. Me hearing "but will she be able to lift a printer if needed?" when I decided to hire a girl as an intern.

Also, I had a color-blind boss on my second job. Great developer, great guy. He couldn't tell red from green when they were next to each other. You know what happened? I started thinking about color as information design instead of decoration.

Those experiences, along with others, changed how I build interfaces and how I communicate with everyone.

But not everyone should need a personal connection to figure that out. And that's the part we need to start fixing.

Small decisions, real consequences

Let me go back to the clothing store for a second. That "Plus Size" category without gender isn't just lazy UX. It tells plus-size customers that they don't deserve the same browsing experience as everyone else. It tells them they're an exception, not a person.

And it compounds. A form that only offers "Male" or "Female." A name field that rejects special characters (sorry, anyone with an accent, a hyphen, or an apostrophe in their name). An age dropdown that starts at 18 and ends at 65, because apparently, people over 65 don't use the internet. Each one of these is a small nuisance. But each one of these tells "this wasn't built for you" to someone that isn't you.

I've seen Brazilian names rejected by international platforms because of the "ã" or "ç" in them. And sorry, this isn't a technical limitation in 2026. That's a choice someone made, or more likely, a choice someone never thought to question.

So what do we actually do?

This isn't an AI Slop article, so I'm not going to give you a five-step listicle with generic tips, sorry. But here's what I know from experience.

First: put different people in the room when you're making decisions. Not as a diversity exercise, but because they'll catch things you literally cannot see. My color-blind boss didn't need a diversity initiative to improve our interfaces. He just needed to be there. That's why I advocate for women in tech. That's why I advocate for teaching programming in public schools.

Second: test with real humans who aren't like you. Not your coworkers. Not your friends. Actual users who interact with your product from a completely different context than the one you imagined. Believe me, the results will humble you.

Third: question your defaults. Not just as an IT professional, but as a human being. Every time you create a dropdown, a category, a label, ask yourself: who am I leaving out? And if the answer is "I don't know," you might have a problem.

We build the systems the world runs on. Not metaphorically. People apply for jobs, access healthcare, manage their money, connect with others, all through interfaces we designed. When those interfaces exclude, they are not just creating an inconvenience, they are erasing people.

That clothing store didn't mean to dehumanize anyone. But in the end, the result is the same.