The interaction patterns that feel obvious but still go wrong

The interaction patterns that go wrong most often are the ones everyone assumes they already know how to design. Search. Filters. Sort. Pagination. Modal confirmations. These don't get the same scrutiny as a novel pattern, because nobody thinks they need to. They're "solved." And then they ship broken anyway.

The solved patterns are the ones that have the deepest set of bad defaults sitting underneath them. Every product copies the patterns, copies the defaults, and inherits the problems.

Search that doesn't search what you typed

A user types into a search box. The product returns either too many results, the wrong results, or no results. The user tries a different phrasing. Now the question is what the search was actually searching against.

Most product search is doing one of two things badly. Either it's matching whole-word substrings in a limited set of fields, so "design system" doesn't find results titled "designing systems," or it's doing fuzzy matching with so loose a threshold that typing "card" returns content about "cars" and "carpets" and the user can't tell why.

The fix isn't a better algorithm. It's a clearer answer to the question of what should match. That answer comes from understanding what users actually type. The work that gets skipped most often is the analysis of real search queries against the product. Without it, search is designed against a guess.

Filters that don't restore

A user filters a list. They click into one result. They go back. The filters are gone. They re-apply them, click into the next result, and the same thing happens. The filter is technically working. It just isn't sticky across navigation.

The reverse failure mode is also common: filters that persist forever, including across sessions, so the user comes back tomorrow and can't figure out why their list is empty. They forgot they had filters applied.

The right behavior is in between, and the boundary is contextual. Filters should usually persist for the duration of the user's task (across pagination, across drill-ins, across short navigations away) and reset on a clean entry to the page from elsewhere. Implementing this correctly requires deciding what "the user's task" means in the product, which is the work most teams skip.

Modal confirmations that don't confirm anything

Are you sure you want to delete this? The user clicks delete, gets a modal, clicks confirm. The action happens. The modal was a speed bump, not a safety net.

Real confirmation works when the cost of the action is high and the answer to "are you sure" might be no. Deleting an empty draft does not need confirmation. Deleting a workspace with thirty members does. Most products apply confirmations on the wrong distribution: trivial actions get them, high-impact actions get the same treatment, and the user clicks through both reflexively.

The pattern that actually prevents mistakes isn't a modal. It's a path to undo. After the action happens, the UI surfaces a way to reverse it. Gmail's "Undo Send" is the canonical version. It works because it doesn't slow the user down on the action they meant to take and gives them a recovery path on the one they didn't.

Sort orders that are arbitrary

A list has a sort dropdown. The options are "Default," "Most recent," "Alphabetical." The user picks Default and the list reorders to something they don't recognize. Most recent puts items in an order that doesn't seem to be by date. Alphabetical sorts by an attribute the user didn't expect.

Sort is one of those interactions where the visible label hides a substantial decision. What is "Default"? What does "Most recent" measure: created, modified, last viewed, last edited by anyone? When alphabetical, alphabetical by what: the title field, the display name, the unique ID?

The pattern that works is being explicit about the sort target in the label. "Recently modified," "Alphabetical by title," "By status, then date." Users don't read these once and remember. They read them every time and need to be able to confirm they're getting what they want.

Pagination that fights the user

Infinite scroll is a default that doesn't deserve to be one. It works for content streams where users don't need to find anything specific. It fails for everything else: lists with searchable content, results that need to be referenced later, anything where a user wants to scroll past something and come back.

Pagination has the opposite problem when implemented as a default. Twenty items per page, no way to change it, no jump to specific pages. The user is forced to click through ten times to get to the thing they remembered seeing last week.

The pattern that actually works depends on what the list is for. Reference data wants pagination with adjustable page sizes and jump-to-page. Feeds want infinite scroll. Hybrid data, something users will both browse and search, usually wants pagination with a clear total count so the user knows the scope of what they're navigating.

The deeper pattern

The common thread across these failures is the same one. The designer encountered the pattern, recognized it as something they already knew how to do, copied the previous version, and never re-asked what the user was trying to accomplish with that specific instance of the pattern. The defaults that work in one context get applied to a context they don't fit.

The fix is unglamorous: when you encounter a "solved" pattern, ask what work the user is doing with this specific instance and let that decide the configuration. The pattern is generic. The implementation isn't.