Who Wasn’t in the Room?

AI, Design Blind Spots, and Why Diversity Is Not a “Nice to Have”

Most failures in AI and digital products aren’t technical failures. They are representation failures.

The system technically “works,” but only for the people who built it, tested it, and defined what success looks like. Everyone else is left with friction, confusion, workarounds, and a quiet sense that the tool is fighting them.

That is the cost of not having the right people in the room early enough. And in a moment when the word diversity is politicized, misunderstood, or deliberately avoided, the work still has to get done.

The Myth of “Neutral” Technology

AI and software are not neutral. They inherit priorities, assumptions, and blind spots whether anyone intends that or not.

When development teams share similar backgrounds, thinking styles, abilities, and lived experiences, their design decisions will reflect that sameness. Not because they’re careless. Because humans normalize what feels familiar.

That’s how blind spots form. Quietly. Rationally. With confidence.

Bias does not require malicious intent. Most of it is structural:

• What gets measured

• Who gets consulted

• What gets prioritized

• What is labeled “normal”

• What gets dismissed as “user error”

When a tool consistently fails the same groups of people, it’s not random. It’s a signal.

The Blind Spot Pattern

Here’s what representation failure looks like in practice:

• A feature is designed for “typical users,” without defining who “typical” actually is.

• Edge cases are treated as exceptions instead of design requirements.

• Feedback arrives late, usually from the people most affected.

• Fixes become expensive because they require architectural changes, not cosmetic ones.

• Teams respond with “users will adapt,” instead of asking why the system demands adaptation in the first place.

Small blind spots don’t stay small. They compound.

A Practical Example: Image Organization

Consider a simple example: image organization.

An app saves images chronologically with no tagging, filtering, search, or grouping. Technically functional. You can scroll. Eventually.

But that design quietly excludes how many people actually work:

• Visual thinkers who iterate and revisit ideas

• Creators who work in versions and collections

• People with limited time or cognitive bandwidth

• Anyone who needs retrieval, not just creation

The app didn’t fail. It succeeded according to the assumptions used to define “done.”

Now scale that same logic into AI systems that classify, rank, route, summarize, or deny access. A minor inconvenience becomes a systemic exclusion problem.

If retrieval time increases, workarounds multiply. If workarounds multiply, trust erodes.

That’s not a UX issue. That’s a design failure with operational consequences.

Diversity is Not Charity. It’s Risk Management.

Organizations often treat diversity as an HR initiative or a values statement. In design and AI development, diversity is a risk-control mechanism. And it goes far beyond race or gender.

Dimensions of diversity that directly affect design outcomes include:

• Experience levels (novice, intermediate, expert)

• Roles and contexts (creators, reviewers, administrators, end users)

• Learning and interaction styles

• Cognitive diversity, including neurodivergent perspectives

• Functional and accessibility needs

• Cultural and linguistic background

• Generational perspective

• Socioeconomic and geographic context

When these dimensions are missing from the room, risk is silently baked into the system.

Diversity in background and cognition does three things immediately:

1.       Expands the problem space so teams see what they’re actually building.

2.      Forces assumptions into the open before they harden into architecture.

3.      Reduces rework by surfacing flaws while they’re still cheap to fix.

If everyone in the room solves problems the same way, the problem space shrinks. That isn’t efficiency. It’s fragility.

The Hidden Cost of “We’ll Fix It Later”

Fixing representation failures late is exponentially more expensive than preventing them early.

Late-stage consequences include:

• Architectural redesigns instead of simple adjustments

• Increased training hours to compensate for poor usability

• Higher workaround frequency, often outside the system

• Slower adoption and higher resistance

• Trust erosion when users feel the system was never built for them

• Internal burnout as teams defend avoidable problems

Metrics make this visible:

• Workaround rate: How often users step outside the tool to complete tasks

• Time-to-retrieval: How long it takes users to find what they need

• Training burden: Hours required to teach p

  eople how to work around the system

• Error attribution: How often “user error” masks design failure

If adoption depends on teaching people to bypass your system, you don’t have adoption. You have compliance. “We’ll fix it in version 2” is rarely a plan. It’s a delay of accountability.

What Better Looks Like

You don’t fix this with slogans. You fix it with process.

Practical moves that consistently change outcomes:

• Design for retrieval, not just creationSearch, tagging, grouping, filtering, versioning. Ask how people will find and reuse what they create.

• Pilot with the people most likely to struggleEdge cases are early warnings, not inconveniences. If they fail, others will eventually follow.

• Reward dissent earlyConsensus feels good. It also hides landmines, especially under time and budget pressure.

• Define success with real-world outcomesAdoption is not usability. Compliance is not trust. A workaround that becomes standard is not a solution.

• Document assumptionsMake them visible so they can be challenged before they calcify into the product.

Hiding issues does not make them go away. It just makes them more expensive.

Where STAR Comes In

This is exactly the kind of quiet failure the STAR Framework was built to address, starting with the first stage: Shift Your Thinking.

Not “think positive.” Not “be resilient.”

Shift your thinking the way leaders, designers, and operators must:

• From “Does this work?” to “Who does this not work for?”

• From “Users will adapt” to “What did we design that forces adaptation?”

• From “It’s an edge case” to “It’s a prediction of future failure.”

In the next article, I’ll break down what Shift Your Thinking looks like in practice:

• How to spot early warning signs

• How to name what’s happening without starting a war

• How to course-correct before the cost curve explodes

Because you can’t fix what you refuse to see. And most organizations refuse to see it until it’s expensive.