I learned this from a waitlist

Years ago, while working with a housing organization, I encountered a pattern that did not make sense at first. The average person on the waitlist had been waiting for years, yet much of the available housing was going to people who had entered the process far more recently.

No one had designed a rule that said ‘serve the most privileged applicant first.’ The eligibility rules were still being followed. The bias lived somewhere else: in the path through the system.

Applicants who already had the expected documents, could navigate the online process, understood the institutional language, and could respond quickly were easier to move through. People who needed translation, had nontraditional documentation, or needed more help were technically eligible but carried a much higher navigation cost.

That experience eventually shaped software I built to reduce the burden the process itself was creating. More importantly, it changed where I look for bias.

The default path is not neutral

Every system has a person for whom it works especially well. Usually we do not call this person anything. They simply have the right documents, understand the language, know which questions to ask, can use the technology, and have enough time to complete the steps in order.

When that person moves through the system, the system feels straightforward. When someone else enters, we discover how many assumptions were embedded in the design.

I am interested in exception paths because they reveal the boundary of the system’s imagination. What happens when someone cannot produce the expected documentation? When they communicate differently? When their family, work history, body, finances, or circumstances do not fit the categories?

Does the system contain another path, or does the person have to find someone willing to improvise one? A system that works only when people conform to its assumptions has not eliminated complexity. It has transferred complexity to the people least able to use the default path.

Accommodation can preserve the burden

Translation may be available. An accommodation can be requested. A staff member can help. An exception can be escalated. Those things matter, but notice where the burden remains.

Who has to know support exists? Who has to request it? How many additional steps are required? How much longer does the alternate path take? The presence of an exception path does not tell us whether the system is accessible. We have to look at the cost of using it.

Design shapes who appears capable

Systems help produce behaviors we later attribute to people. Someone who navigates the process quickly appears prepared. Someone with the expected documentation appears organized. Someone who understands the institution’s language appears competent.

Those interpretations may be accurate. They may also be artifacts of fit. People who share the system’s assumptions spend less capacity navigating the system itself. Others have to do both.

The easiest path through a system tells us something about whom the system expected. The harder question is what the system does when someone else arrives.

The concept of legally mandated accommodations forced me to reckon with the possibility that I had not been operating on a level playing field. It took years to accept that I could need an accommodation even when I was capable of forcing myself through the default.

That changed the way I look at organizational design. A system can call itself flexible while requiring people to continually request exceptions from a norm built around someone else. The cost of the mismatch is then assigned to the person who differs: explain yourself, disclose enough, ask correctly, wait for approval, absorb the social cost of needing something different.

A more interesting question is what becomes possible when the default itself contains more ways to participate.