The most disorienting thing about bad software isn’t that it fails; it’s that it fails in ways that make us feel like the problem.
There’s a certain piece of software I use almost daily in my job, which will remain unnamed but that handles things like email marketing, data collection and dashboards, landing pages and form builders, things like that. This piece of software has close to 300,000 customers, including some very large businesses you’ve surely heard of.
And yet everyone I know hates using it. It feels clunky and regularly breaks in New and Interesting ways. Why? Why is such a ubiquitous tool so frustrating to use?
I believe that we as the users are doing things just fine. The software is the problem. But understanding why requires drawing a line that most design criticism never bothers to draw: the line between a tool that failed accidentally, one that failed through negligence, and one that was built to frustrate you on purpose. That matters, because only one of those failures is innocent.
Design-induced confusion
Design-induced confusion is a documented phenomenon. The foundational argument comes from Don Norman’s The Design of Everyday Things, and it goes like this: When a well-intentioned person fails repeatedly with a tool, the correct diagnosis is a failed tool, not a failed user. Norman made this case about doors and light switches. It applies, with even more force, to software, because software companies have something physical product designers don’t: a direct feedback channel to the user they can choose to use or ignore.
Most choose to ignore it. Routing user frustration into FAQ pages, chatbot flows, and support ticket queues instead of fixing the interface is a choice. Someone decided it was cheaper to manage your confusion than to eliminate it. The cost of bad design gets transferred, invisibly, from the company’s engineering budget to yours.
Research published in 2026 found that older adults face an especially acute convergence of barriers, including health limitations, unfamiliarity with design conventions, cognitive load, and limited access to workarounds. Separate findings from the same period identified age, education, and income as the most consistent predictors of digital exclusion.
Three failure modes produce the same feeling but have very different causes:
- Accidental bad design: the result of resource constraints, inexperience, or genuine oversight
- Negligent design: when a team builds for a narrow default user and never tests outside that group.
- Deliberately friction-laden design: dark patterns and engagement traps built to serve the company at the user’s expense.
Only the first of those failure modes is innocent, and it’s less common than the industry likes to admit.
Design always has a default user
Every design decision is a bet. When a product team builds a user persona, they’re wagering that their composite sketch of “the typical user” is accurate enough to make decisions against.
Nielsen Norman Group research and others have documented a persistent split between standard design team personas and the real users of the products those teams ship. The assumed default tends to be young, non-disabled, native English-speaking, broadband-connected, and working on a current-generation device. That profile describes the people doing the designing far more reliably than it describes the people doing the using.
When the people who design software are also the people who test it, failure is structurally invisible to them. The interface works on their machine, in their browser, on their fiber connection, with their motor control and their reading fluency, so they ship it.
What happens to everyone else
Generally, no individual design choice represents a deliberate exclusion. People by and large don’t set out to exclude others. But combined, these decisions can make the product unusable for people who rely on keyboard navigation, people with low vision, and people using screen readers. Our analysis of thousands of websites found accessibility failures of exactly this kind are not edge cases. They’re the norm, distributed quietly across the web at scale.
The same interface costs different people different things
Friction isn’t distributed like weather, hitting everyone more or less equally over time. It’s structural, and it follows the same fault lines every time.
WebAIM’s Screen Reader User Survey has documented for years the specific barriers that most reliably prevent task completion for people who rely on assistive technology:
- missing or inadequate alternative text,
- inaccessible forms,
- poor keyboard focus management, and
- modal dialogs that trap rather than serve.
These are the failures that appear at the top of the list, year after year, on the most visited pages of the web. These barriers cause complete abandonment of a task far more often than they cause mere slowdown, something most developers building the tools never see.
Power users
Most software is designed to reward investment. Learn the keyboard shortcuts, internalize the menu logic, map the non-obvious navigation patterns, and the tool eventually returns value proportional to that effort. The problem is that this model treats learning cost as a one-time fee. For a full-time employee using the same tool every day, that fee gets amortized quickly. For someone who uses the tool infrequently, has a cognitive disability that makes pattern-learning harder, or is simply new to the category, the fee never gets amortized. It gets charged every single session.
That makes the software permanently more expensive to use for the people who are already excluded by it. Research examining usability barriers across user groups found that design conventions optimized for experienced users consistently created steeper barriers for those outside the assumed competency baseline.
Enterprise
Consumer software has a pressure valve. If a product is too frustrating, a user can switch. Enterprise software has no such valve.
A person who navigates by keyboard, or who relies on a screen reader, navigating a poorly-built enterprise SaaS platform doesn’t get to choose a competitor. The friction cost is real, it falls entirely on the user (and, by proxy, the company, although it’s an invisible cost that’s often ignored), and it compounds daily. The whole reason the WCAG 4.1 compatibility criteria exists is because assistive technology compatibility in complex web applications requires deliberate engineering, not accidental good fortune.
The language side of things, something I care deeply about as a long-time content writer, compounds everything else.
The average reading level of U.S. adults sits at roughly an eighth-grade level, and a meaningful portion of the adult population reads below that. SaaS onboarding copy, error messages, and help documentation are routinely written at a college reading level by people for whom that fluency is unremarkable. An error message that reads “Your authentication token has expired. Re-initialize your session credentials to proceed” presents a barrier to comprehension that falls hardest on users who are already contending with unfamiliarity, stress, or limited English proficiency.
WCAG 3.1 on readable content addresses this directly, but compliance here is among the least-enforced criteria in practice. The two pieces of research cited earlier in this article both confirm that literacy, age, and income cluster together as predictors of who gets locked out, meaning that bad language design also doesn’t impose its costs randomly.
When bad design becomes fraud
Dark patterns are deliberate engineering. When Harry Brignull first catalogued the taxonomy, he named specific mechanisms:
- roach motels (easy to enter, nearly impossible to exit),
- “confirmshaming” (guilt-framed opt-outs),
- hidden costs revealed only at checkout, and
- misdirection that draws attention away from the thing the company does not want you to see.
Each of these requires a designer to make an active choice to obstruct the user from doing what they came to do.
A famous example of a dark pattern in design is/was Amazon’s subscription cancellation flow, widely reported and described internally as the “Iliad flow.” It required users to pass through multiple screens of discouragement, each reframing the cancellation as a mistake, before allowing them to actually cancel. The FTC took legal action against this flow back in 2023, saying that Amazon “knowingly making it difficult for consumers to cancel their subscriptions.”
A widespread example that you may have experienced yourself is when cookie consent dialogs, different ones across thousands of sites, are engineered so that “reject all” requires navigating multiple submenus while “accept all” is a single prominent button.
These are examples of design successes, where the interface performed exactly as the company intended, at the user’s expense. The FTC’s 2024 review of dark patterns, conducted with international consumer protection networks, found these mechanics operating across a wide range of platforms and product categories.
Regulatory frameworks are now catching up: the FTC’s “click to cancel” rule (unfortunately nullified in court as of the writing of this article), GDPR enforcement targeting manipulative cookie flows, and the EU Digital Services Act’s provisions on deceptive interfaces are the first legal instruments that treat this as fraud rather than poor taste.
Feedback loops only listen to winners
There’s a reason bad design persists, and it has nothing to do with indifference. The people building these tools are usually trying to improve them. They run surveys, monitor dashboards, track scores. The problem is that the measurement systems they rely on only register the experience of people who made it through. NPS and CSAT scores are collected after task completion. They’re incapable of registering the experience of someone who never completed the task, because that person is not in the denominator. A product can score well on satisfaction surveys and simultaneously be unusable for a significant share of potential users.
This is the silent abandonment problem, and it’s harder to fix than it sounds. Analytics platforms measure clicks, scrolls, session duration, and conversion. They do not, by default, record why someone left.
A person who relies on a screen reader and hits an inaccessible form error message that never surfaces to their assistive technology is recorded identically to someone who got a phone call and closed the tab. Both just register as a bounce. Observed abandonment rates and diagnosed root causes diverge sharply, because most analytics instrumentation was never designed to distinguish them.
We on marketing and product teams are generally trying to prioritize making our stuff work for the people who convert. You can probably see how constantly chasing after the same type of person would create a cycle that increasingly excludes every other type of person.
This is what happens when the people building the tools, choosing the metrics, and reading the dashboards are not the people the tool is failing. The design choices that exclude specific users and the measurement choices that make those users invisible both make a default assumption about who the user is, and do it so early into the process that it stops looking like an assumption at all.
When design gets fixed, everyone moves faster
The curb cut is the oldest example people reach for, and it’s still the right one: Cut into a curb for wheelchair users, and suddenly cyclists, delivery workers, parents with strollers, and anyone carrying something heavy all benefit without anyone having planned for them.
The same pattern runs through software with a consistency that should, by now, have changed how product teams justify inclusive design work. It hasn’t yet fully done so, but the documented evidence is too specific to dismiss. Captions were designed for people who are deaf or hard of hearing. They’re now used by a substantial majority of people watching video in public spaces, which is why every major streaming platform defaults to them. The accommodation became the standard because the population that needed it turned out to be much larger than anyone had modelled.
Keyboard navigation is the software version of the curb cut: built for people who navigate by keyboard because a mouse is inaccessible to them, and now depended upon daily by power users, developers, and anyone who has learned that lifting a hand to a mouse is slower than it looks.
Microsoft’s inclusive design framework is the most thoroughly documented corporate example of this at scale. Their design team developed what they call the “persona spectrum,” which maps a single permanent disability onto a cascade of temporary and situational equivalents. Think personas like someone with one arm, someone with a broken wrist, someone holding a baby. They’ve realized that designing for the most constrained case produces an interface with more degrees of freedom for everyone.
The distinction that matters most, though, is not between companies that fixed design problems and companies that did not. It’s between organizations that fix problems when threatened and those that build the conditions for finding problems early.
Reactive remediation, driven by a lawsuit or a compliance deadline, tends to produce a narrower fix: the specific barrier named in the complaint gets addressed, and the underlying process that created it stays intact. Proactive approaches, where inclusive testing sits inside the product cycle rather than after it, catch the same class of problem before it compounds across a codebase. The ADA deadline framing misses this entirely. Deadlines create a finish line. Design philosophy creates a practice, and it is the practice that determines whether the user who was excluded last year is still excluded next year under a different feature name.
Is it you, or is it the tool?
When in doubt, ask yourself these three questions:
- Does the failure happen at the same point for multiple people, or only for you? If a specific step in a workflow reliably trips up different users with different skill levels, that is a design problem wearing the costume of a user problem.
- Does the tool behave differently depending on how you access it (which browser, which device, which screen size, or whether you’re using a keyboard instead of a mouse)?
- Is the path to success discoverable/learnable without already knowing the answer?
The workaround community is the most underused diagnostic available. When users of a tool have collectively built browser extensions, third-party guides, and Reddit threads explaining what the interface refuses to tell you, that body of informal documentation is an audit.
None of this is the users’ failure. It’s the users doing the product team’s job without the product team’s budget. Yes, some (many) tools carry a learning curve that is proportionate to their power. Think things like Vim, Figma, or Excel. Hard tools aren’t bad tools. But a difficulty that falls evenly across users and returns proportionate capability is different from difficulty that scales with identity rather than with the complexity of what you’re trying to do.
The larger implication is that the question “Is this my fault?” is itself a product of how these systems are built. Software that fails specific people reliably tends to make those people feel individually deficient rather than collectively excluded, which is convenient for the people who built it.
Knowing the difference isn’t just useful for your own sanity. It’s the first step toward demanding better from the tools your work and your life depend on.
