Good UX is easy to recognize when the birds are chirping and the sun is shining. The workflow feels smooth, the interface feels calm, and we get where we meant to go without much fuss. But how about when the storm clouds gather and things stop being tidy: when a workflow change collides with a deadline, when a system’s idea of how work should happen no longer matches reality, or when an older or anxious user faces an interface that expects more tech familiarity than they have.
Many systems are still built around a narrow picture of a normal user in a normal situation. When life drifts away from that model, the system rarely follows. People memorize quirks, keep side spreadsheets, coach one another through confusing flows, and patch over what the tool does not handle. The official language is usually training issues or resistance. The more accurate description is that the system has offloaded the adaptation burden onto its users. And that’s what messy moments reveal about where UX and UI need to go next.
Workarounds appear when the official path makes it hard to achieve a legitimate goal. Someone needs to pay a person correctly, update a record, reconcile a number, or move a case forward, and the prescribed path does not fit the data, timing, or context. But people don’t stop just because the software throws up a roadblock. Instead, they reroute.
Sometimes the reroute is small: splitting information across fields or using comments to piggyback detail the system won’t accept. Sometimes it’s more significant: a spreadsheet that tracks reality better than the database, an email confirmation everyone trusts more than the status field, or a side call that serves as the real approval while the system is updated later for the record. The workaround is goal driven. It’s there to keep essential work moving and it becomes coordinated practice. People share them with new colleagues. Teams agree informally on how they really do the work. Seen this way, workarounds are a form of bottom-up design.
But. That doesn’t mean they’re always good. Some create risk, inadvertently hide information from audits, or bypass important security safeguards. However, even the risky workarounds are instructive. They show where the design is asking too much of users or enforcing a workflow that doesn’t fit tactical requirements. If all workarounds are treated as misbehavior, then that signal is lost.
A system shouldn’t be judged only by how smooth its happy path looks in a demo. It should also be judged by how many workarounds it provokes, how much hidden adaptation it demands, and how much de facto design work it pushes back onto the people who use it.
Some of the most interesting answers to these problems are coming from the edges. Tools built for older adults and other tech-averse users have had to confront constraints that mainstream products often gloss over: reduced vision or dexterity, lower confidence, less patience for trial and error, less comfortability in digital environments, and less support when something goes wrong.
In response, these products have made different design choices. Platforms like PRISM, devices like GrandPad, interactive care systems like I-Care, and aging-in-place kits built around smart speakers and sensors tend to focus on a small set of meaningful tasks. They use larger targets, clearer typography, cleaner and calmer layouts, shorter flows, and more instructive support. Support is built into the product and the surrounding service.
These choices are often framed as accommodations for a special group but in practice, they solve problems many mainstream users also have, though are better at hiding: uncertainty, distraction, limited working memory, and fear of pressing the wrong thing. An interface that makes an anxious, late-adopting user feel safe will almost certainly feel clearer for everyone else too.
Seen this way, inclusive and age-friendly design is applied research into what interfaces should do when they can’t assume a fluent, confident, well-supported user. The best patterns from this work, including thoughtful defaults, visible recovery paths, progressive disclosure, and co-design with non-expert users, are exactly the patterns that make other systems less punishing when workflows go sideways.
Almost every system makes a choice about who will adapt to whom. In many cases, that choice has been made so often in favor of the tool that teams no longer see it as a choice at all.
We can see it in error messages that scold more than they help. We can see it in exception handling left to email and memory instead of visible branches in the workflow. We can see it in forms that expose every requirement at once, assuming users will patiently read and comprehend, and in advanced features layered on without regard for how occasional users will navigate the noise.
This assumption shows up everywhere. Some business systems treat timing quirks, retroactivity, and unusual cases as edge conditions to which users must adapt. Some interfaces demand fine motor control, perfect vision, or high digital literacy and just assume users will either figure it out or opt out altogether.
A more wholistic UX practice would ask, for each important workflow and interface, where it is legitimate to ask people to learn and change, and where it’s incumbent upon the system to be flexible. It would treat exceptions, fragile moments, and anxious users not as outliers but as core design cases.
Once we look at systems this way, the question is not whether users should ever adapt. Of course they should. Every tool imposes some structure, and some of that structure is necessary. Payroll cannot be improvisational. Clinical records can’t be infinitely flexible. Safety checks, TFAs, audit trails, and legal requirements are real constraints.
The problem is that systems often ask more of people than they should, then hide that fact behind the language of compliance, best practice, or training.
If the workarounds continue to show up around the same screens, timing issues, or exceptions, that’s not noise; that’s signal. Instead of treating every workaround as a policy violation first, teams could ask a better question: what job is this workaround doing that the interface or workflow is failing to address?
This question matters because it moves UX research away from idealized use and toward lived use. Systems often look reasonable when viewed as isolated screens. They look less reasonable when we follow the chain of clarifications, recovery steps, and side work users perform around them.
This would also discourage UX design to stop treating inclusive and age-friendly design as a niche specialty. Clearer defaults, visible recovery paths, fewer simultaneous decisions, calmer layouts, stronger confirmation cues, and support available before the user feels stranded are not special features. They’re signs that a system understands how people behave when they are distracted, uncertain, or under pressure.
For any important task or interaction UX teams can ask these design governance questions:
- What must stay fixed because of safety, legal, or operational reasons?
- Where are we asking the user to memorize or compensate for complexity that the system could carry instead?
- Which errors are we treating as user faults even though they are predictable results of the design?
- Where does the interface need one clear default path, and where does it need supported variations for different realities?
This is also where good systems begin to look less polished in the superficial sense and more resilient in the practical one. The goal is to create a system that stays understandable when things start to go awry: when someone is new, rushed, uncertain, older, interrupted, or trying to solve a problem the original workflow didn’t anticipate.
Conclusion
A great deal of UX conversation has been shaped by ease, speed, and delight. Some of that still matters. But ease on a good day is a low bar. Plenty of products feel elegant when the data is clean, the user is confident, and the path is linear. The more revealing test is what happens when those conditions disappear.
A good system should absorb more of the mess real users bring to it. It should reduce the memorization, translation, and patching people do on its behalf. It should make room for different levels of confidence and ability. It should show where the workflow branches, where the exceptions live, and how to recover when something goes wrong. And when users invent workarounds, it should treat those not only as control problems but as evidence that the official design has stopped where the work hasn’t.
That standard changes the way a system is judged. Instead of asking only whether users can complete the intended task, it asks what extra work they had to perform that the product never acknowledged. Instead of admiring an interface for how little it shows, it asks whether the hidden complexity is now being carried in memory, training, shadow processes, or institutional folklore. Instead of treating inclusivity as a separate concern, it asks whether the design remains usable when the user is less fluent, less patient, or less supported than the team assumed.
In our opinion, the next step for UX and UI is to design systems that carry more of the adaptation burden themselves, especially in the moments when work becomes messy and users are least able to do that work for them. That will not always produce the sleekest interface or the shortest specification. It will, however, produce tools that are more responsive to how work and life actually unfold. Systems become humane when they continue to work with people rather than against them should the happy path give out.
