Most Bad UX Is a Memory Problem, Not a Design Problem

A developer writing under the handle towernter published a piece recently about what actually separates good UX from digital torture. The framing is worth taking seriously even if the title is a bit dramatic. The core claim: working memory has a real limit, and most interfaces that feel frustrating aren't badly designed in some vague aesthetic sense, they're asking users to hold too much in their head at once.

The constraint nobody designs around

This isn't a new idea. Miller's Law, from cognitive psychology, puts working memory capacity at roughly seven items, give or take a couple. What's useful about applying it to product design is that it turns "this feels confusing" from a subjective complaint into something closer to a load-bearing capacity problem. A checkout flow with nine visible fields and three optional ones isn't confusing because the visual design is off. It's confusing because it's asking someone to track more open items than working memory comfortably holds while they're also trying to remember their card number.

What this actually looks like in bad interfaces

The examples are familiar the moment you see them named. Long forms with unlabeled optional fields, where the user can't tell what's actually required without trial and error. Forced account creation before someone can complete a purchase, adding a whole extra task to what was supposed to be a two-minute transaction. Cascading modal windows, where closing one reveals another underneath it. Error messages like "Error 403: Forbidden," which are accurate to the server and useless to the person reading them.

None of these are failures of visual polish. They're failures of respecting how much a person can track at once while trying to do something else.

A short list of principles that hold up

A few of the specific principles from the piece are worth keeping as an actual working list, not just reading once and forgetting:

• If someone can't find the button, the button is in the wrong place. That's a design failure, not a user failure, and treating it as the latter is how teams stop fixing real problems.
• Every extra step is a tax. Before adding a confirmation screen, an extra toggle, or a second modal, the question should be whether it's solving a real risk or just covering the team's own uncertainty.
• Feedback has to be immediate and visible. A button that does something with no spinner, no confirmation, no visible state change reads as broken, even when it technically worked.
• Consistency isn't a style preference. When a pattern repeats the same way across a product, people stop having to think about it at all, which is the actual goal, not decoration.

The one question that resolves most design arguments

The most useful line in the piece is also the simplest: ask what the user is actually trying to do right now, then put that thing one step away. Most disagreements about a flow, a form, or a page layout resolve quickly once that question is answered honestly, because it cuts through debates about visual preference and gets back to the actual job the screen needs to do. If a team can't answer it clearly for a given screen, that's usually a sign the screen is solving the wrong problem, not that it needs a redesign.