The hidden tax of hard-to-use systems

With a truly good human interface, almost no change management is needed. That claim sounds bold until you look at what most change programs actually do.

Much of their effort goes to teaching people how to use the tool: where the button is, which screen comes next, what the error means. That work is a tax on design. It is paid because the system works one way and people expect another.

The evidence for this is everywhere:

• Consumer software proves it. Nobody runs a change program to roll out a phone app to millions of people. Consumer products live or die on usability, because there is no mandate to fall back on.
• The adoption research agrees. Everett Rogers found that complexity slows adoption. Fred Davis's Technology Acceptance Model ranks perceived ease of use as a primary predictor of whether people adopt a system.
• Friction beats motivation. BJ Fogg and Chip and Dan Heath both find that making a behavior easier works better than making people want it more. Change management mostly works on motivation. Design works on friction.
• Blame the door, not the person pushing it. Don Norman reframes "user resistance" as feedback about the design.
• The tax recurs. Alan Cooper shows that poor usability is paid again with every new hire, support ticket and workaround.

Good design is paid once.

So the goal is not a better training program. It is a gap small enough that the training program has little left to do.

Accessibility is bigger than we think

The best human interfaces have the best accessibility. Effective accessibility ultimately means intuitive ease of use for anyone, not only for those with limitations, whether temporary or permanent.

Most of us hear "accessibility" and think of helping people with a disability get access to things. That matters, and it is not the whole story. Accessibility may be the quickest path to ease of use, for four reasons.

• It's concrete. "Make it intuitive" is vague. Accessibility standards such as the Web Content Accessibility Guidelines (WCAG) are specific and testable, so teams can actually check their work.
• It forces clarity. Designing for the most constrained user demands plain language, clear structure, consistent navigation, forgiving errors, and more than one way to act. Those are also the classic usability heuristics.
• It spills over to everyone. Designers call this the curb-cut effect. Sidewalk ramps were built for wheelchair users, then used by everyone with a stroller, a suitcase or a bike. Captions, voice dictation and autocomplete followed the same path. What removes a barrier for one person removes friction for everyone.
• Limitation is a spectrum. Inclusive design treats it as permanent, temporary or situational: one arm, an arm in a brace, an arm holding a baby. Everyone is "limited" some of the time.

That last point changes who accessibility is for. It is not a feature for a small group. It is a description of every user on some day of the week.

Lived evidence

I have been testing this thesis on myself, without planning to.

Long before I had any physical limitation, I set a rule for my AI assistant: whenever it needs a decision from me, let me answer with a number. I did it purely for ease. One digit is faster than a sentence, and a numbered list makes the choices clear.

Then I needed surgery on my arms. Before and after it, typing was difficult or impossible, and I did more and more by voice. The numbered-reply rule turned out to be exactly what I needed. A design choice made for convenience had quietly made the interface accessible.

During recovery, I built several working AI skills entirely by voice. The interface held up under a real temporary limitation. That is the curb-cut effect running in reverse: designing for ease produced accessibility, just as designing for accessibility produces ease.

Shortcuts are compression, not keystrokes

A shortcut is one step standing in for many. It is not tied to any input method.

We tend to picture shortcuts as keyboard combinations, which makes them sound like a power-user feature. But the same compression can be typed, tapped, spoken, or answered with a single number. The numbered-reply rule is a shortcut. So is a voice command, a saved template, or a default that is already right.

This matters for two reasons:

• It serves experts and constrained users at once. The person in a hurry and the person who cannot use a keyboard both benefit from fewer steps. Accessibility and speed stop competing.
• It gives teams a practical design rule. Whenever people repeat the same two or more actions, a shortcut is a design decision waiting to be made, through whatever channel the person has available.

Designed in, not bolted on

The accessible path only feels like the long way around when it is added as an afterthought.

The usual objection is that a ramp is a longer path than the stairs. Look closely at the ramps that really are long, and most share a history: they were added to a building designed around stairs, by people who did not want to move the stairs. The ramp ends up long, awkward, and around the back.

Design the ramp and the stairs together, and the picture changes:

• The extra distance is small. A gentle slope does need some length to cover a rise. Planned alongside the stairs, that difference is usually minor.
• Invest in the accessible path and it can win outright. Moving sidewalks are essentially powered ramps, and they are often faster than walking. Elevators are the same case. When the accessible path gets first-class investment, it often beats the stairs.
• Ease includes safety. Even people who walk fine are more likely to trip on stairs, especially with a suitcase or full hands. A slightly longer, much safer path is arguably the easier one.
• Fair exceptions exist. A historic building sometimes cannot be redesigned. The real gap appears when people simply refuse to rethink the infrastructure.

Software works the same way. Accessibility designed in from day one costs almost nothing. Accessibility added later is the long ramp around the back: expensive, awkward, and treated as a separate path for a separate group of people.

Access is the other half of accessibility

Accessibility and access are intertwined. A barrier does not have to be a staircase. It can be a language, a missing tool, or information only some people can afford.

I grew up around this idea without having a name for it. My mother worked at the United Nations Secretariat in New York for more than 35 years. As a young person with a student badge, I could walk the premises and even sit in the General Assembly hall when it was not in session.

Language as access

What I noticed most were the audio jacks at every seat. Each delegate could hear the proceedings through an interpreter, in the language most natural to them. The Assembly's rules require that a speech in any of its six official languages be interpreted into the other five. A delegate who speaks another language must bring their own interpretation into one of the six. Even the UN had to decide where to draw the line, and that line has moved: the founding rules of 1946 named five official languages, and Arabic was added later.

Technology as access

My mother's unit deployed Wang computer systems to developing countries so they could run national censuses. The unit brought each country's officials to the Secretariat, trained them there, and sent them home with the systems to install. The hardware alone was not access. The training was what made it usable, which is exactly the gap good design tries to close.

The pattern is the same as the ramp. When the direct path is designed for only some people, everyone else pays for a workaround: an interpreter, a trainer, or, as the next section shows, a lawyer.

When information is the barrier: early hip-hop

Contracts and copyright law are interfaces too, and badly designed ones. When an interface is too complex to use unaided, someone has to translate it. In law, that translator is a lawyer, and the people who cannot afford one pay the full cost of the bad design.

Early hip-hop shows how that plays out. Many of its artists and producers came from poor neighborhoods, with little access to lawyers or industry knowledge. Early hip-hop contracts were often exploitative, and sometimes there was no contract at all. The problem has not gone away. Kelis has said she signed what she was told as a young artist, without independent legal advice, and does not own the copyright in much of her early work.

The courts raised the stakes. In 1991, a court ruled against Biz Markie over an unlicensed sample, granted an injunction, and referred the case for possible criminal prosecution. Critics argue the ruling made it too risky for artists to contest any sampling claim. In 2005, the Sixth Circuit's Bridgeport decision held that even a two-second, three-note guitar chord infringed, summed up as "get a license or do not sample." Settlements followed the leverage. Rights holders could demand half or more of a new song's copyright for a sample lasting a few seconds.

The artists who paid often had defenses they never had the information or the money to raise.

Fair use is a defense you have to litigate

In Campbell v. Acuff-Rose (1994), the Supreme Court held that 2 Live Crew's commercial parody of Roy Orbison's "Oh, Pretty Woman" may be a fair use. The Court sent the case back, and the parties settled. Its protection is strongest for work that comments on the original, and in Andy Warhol Foundation v. Goldsmith (2023), the Court held that adding new meaning or expression does not by itself make a use transformative. But the deeper lesson is about access. 2 Live Crew could take their case to the Supreme Court because they were already successful. A right you can only claim through years of litigation is a ramp behind a locked door.

A song carries two copyrights

One covers the composition: the melody, harmony and lyrics. The other covers the sound recording. The recording right covers only the actual sounds fixed in that recording. Federal law says an independent recording that imitates or simulates those sounds does not infringe it. Nobody owns the timbre of a synthesizer, and the companies that make them were never plaintiffs. A producer could rebuild the same patch and replay a part instead of sampling it, owing nothing on the recording. Knowing that was exactly the kind of information label lawyers had and many early producers did not. In Bridgeport itself, the composition had already been licensed. The case was about the recording alone.

Building blocks cannot be owned

Western music is built from twelve pitches, arranged in predefined keys and modes. The number of short melodies is finite, and far smaller than most people assume. Courts are increasingly recognizing this. In 2024, the Second Circuit held that the four-chord progression behind Ed Sheeran's "Thinking Out Loud" is too common to meet copyright's originality threshold.

The plaintiff was not always the owner, or the creator

George Clinton has sued his former business partner and Bridgeport Music, alleging they fraudulently obtained the copyrights to about 90% of his catalog. Clinton says he was never named as a plaintiff in Bridgeport's sampling suits, which numbered in the hundreds. Bridgeport disputes his claims, and a Florida court ruled in 2001 that his 1976 to 1983 catalog belonged to Bridgeport. Either way, a young producer facing a demand letter rarely had the records or the money to test who owned what. The plaintiff against Ed Sheeran was an investment fund holding about an 11% interest in "Let's Get It On."

The sampled artists were often exploited too, and licensing money frequently went to middlemen rather than musicians. So the dividing line was never sampler versus sampled. In both cases, whoever had the lawyers and the information won.

What change management is still for

Good design does not eliminate change management. It shrinks it to the part that is actually about people.

The strongest objections to this argument are real, and each one points to work that should stay:

The refined thesis: good design, reached fastest through accessibility, shrinks change management to roles, reasons and process. When a change program is mostly teaching people how to use the tool, that is a sign the tool is poorly designed.

Putting it to work

This is not a feature to add to one product. It is a way of approaching any design work, whether the thing being designed is software, a service or a process. It starts with one question: what is the easiest way for a human to do this?

In practice, that question breaks into a few checks a team can run on any design:

1. Design for the constrained user first. Picture the task done with one hand, by voice, on a small screen, or in a hurry. If it works there, it works everywhere.
2. Hold it to a testable standard. Use WCAG or a similar checklist so "easy" is something the team can verify, not just claim.
3. Count the steps. Wherever people repeat the same two or more actions, design a shortcut, and make sure it works through more than one channel.
4. Build both paths at once. Treat the accessible path as part of the main design, never a later add-on.
5. Read the training plan as a bug list. Every item in it that teaches people how to use the tool is a design gap to close before launch.

Teams that work this way should find their change programs getting shorter, and focused on the conversations that genuinely need people.

Conclusion

Accessibility is usually treated as a requirement for a few. It is better understood as a design method for everyone, and the fastest route to an interface people can use without being taught.

The same is true of access to language, technology and information: whoever lacks the direct path pays for a workaround. The sidewalk ramp makes the case in miniature. Built for wheelchairs, it serves everyone. Bolted on later, it is the long way around. Designed in from the start, it is barely longer, much safer, and sometimes faster.

If we design for the easiest way for a human from the beginning, the result is accessible for anyone and easier for everyone. And the change management left over is the part worth doing.

References