Designing for the person who isn't coping
Systems designed for the average user consistently fail the person in most need — and that failure is not a bug, it is an untested assumption baked into every design decision.
You're reading The Next Evolution by Neil Catton — essays about technology, the people it serves, and the people it leaves behind. If someone forwarded this to you, you can subscribe free at neilcatton.substack.com
INTRO
Morgan’s wife died on a Tuesday. By Thursday, Morgan was on the phone to the bank, trying to change the name on the joint account.
The automated system — helpful, efficient, well-designed by any standard metric — asked Morgan to log in. The login required a password Morgan’s wife had set up. There was a security question. Then a one-time code, sent to a mobile number that no longer existed.
After forty minutes, Morgan was transferred to a person who explained that the process for bereavement account changes required a letter, a certified death certificate, and fourteen to twenty-one working days. The person was kind. The system was not.
Morgan had done nothing wrong. The system had done nothing wrong, technically. But Morgan left that call smaller than before it started.
CHALLENGE
Systems are tested against the average user, someone who is reasonably well, reasonably rested, with a stable internet connection and a working phone. Someone whose circumstances match the assumptions baked in during design.
That user does not exist, most of the time. And they definitely do not exist during the moments when someone most needs the system to work.
Bereavement. Job loss. Serious illness. A mental health crisis. A relationship ending badly and taking documents, passwords, and shared accounts with it. These are not edge cases. They are the moments when people encounter systems with the least capacity to manage the friction those systems create.
The test of a system is not how it performs for the person who is managing fine. It is how it performs for the person who is not.
PROBLEM
Design is optimised for flow. The goal is to move the largest number of people through the most common journeys with the least friction. That is a reasonable ambition. It is also, quietly, a choice and the people who pay the cost of that choice are not the people being optimised for.
The person in a difficult period is slower, more likely to make errors, less able to navigate complexity, and more likely to disengage entirely when the system becomes hard. All of this is predictable. None of it is invisible. And yet the system is designed as though it will not happen.
This is not negligence. It is a consequence of where design attention goes. The personas used in design workshops tend to represent the capable, connected, digitally literate user. The grieving spouse, the person managing a diagnosis, the parent running on no sleep, these people are not in the room when assumptions get set.
What gets designed in workshops is what gets built. And what does not get designed is not an accident. It is a decision made in the absence of those who would otherwise have changed it.
CONSEQUENCES
The consequences are not abstract. When someone cannot complete a process during a crisis, they either persist at significant personal cost or they disengage. Disengagement means delayed benefit claims, missed medical appointments, unresolved financial issues, and legal complications that compound over time.
There is a particular cruelty in systems that penalise people for the timing of their difficulty. A person who misses a deadline because they were in hospital is penalised as equally as a person who simply forgot. The system does not know the difference, and it is not designed to ask.
People in crisis also often need to make decisions quickly, with reduced cognitive capacity. A system that requires them to locate reference numbers, verify multiple forms of identity, navigate complex menus, and understand institutional language is not neutral — it is selectively inaccessible.
What is manageable when you are well becomes impossible when you are not. That gap between the two versions of the same person is a design problem. It is being left unsolved.
SO WHAT — THE THREE A’S APPLIED
Start with Assistive. A system that assists is one that helps people do the thing they are trying to do. Morgan was trying to sort out the account. The system required Morgan to become an expert in its own processes, produce documentation under time pressure, and navigate security architecture designed for a world where both account holders are still alive. That is not assistance. That is bureaucracy wearing the clothes of a service.
Augmentive asks whether the technology adds something that was not there before. There is a version of this system — plausible with technology that already exists — that recognises a bereavement flag, routes to a specialist team, waives standard security steps against an alternative verification, and proactively tells the caller what is needed and why. The components exist. The decision to assemble them for this use case has not been made. Nothing has been augmented.
Adaptive is where the gap is widest. An adaptive system responds to individual context and circumstance. It notices that this call is different from a routine query. It offers a slower pace, simpler language, a callback when the caller is ready. It does not require the person to perform competence they do not currently have. The technology to do this is not new. The will to design for it is.
The three questions are not technical problems. They are design choices. Specifically, they are choices about whose experience the design is optimised for.
NOW WHAT — FOUR QUESTIONS
Has a system ever made something harder for you at a moment when you were already struggling? Not because it was broken, but because it was built for a version of you that did not exist that day?
If you have a story of navigating something difficult during a difficult time, share it. The pattern matters and so does the specificity.
If you could change one thing about how public or commercial services behave when a person is in difficulty, what would it be?
Is designing for the average user actually a neutral choice — or is it a values statement about whose experience matters most?
If this resonated, you can follow The Next Evolution at neilcatton.substack.com. These essays draw on the ideas in my books — The Next Evolution, The Cognitive Crucible, and The Shadow System — which are available now on Amazon.
A note on Morgan
Morgan is a fictional character. Their story is drawn from a combination of professional observation and personal proximity to real events. The experiences described are real. The person is not.