Jordan noticed it on a Tuesday morning, about four months in. They had opened the app the way they opened other apps — without thinking about it, on the way to something else. The result was there when they looked: a number, with a short explanation of what it meant in relation to where it had been last week. Jordan read it in the time it takes to make coffee. There was nothing to decode.
That moment — a test result arriving with context, at a time they could actually do something with it — was not dramatic. It did not change the condition. Jordan has a condition that requires regular monitoring, and it will require monitoring indefinitely. But something had shifted in the daily experience of managing it. The technology had been built to serve that experience, not to process it. For the first time in years of navigating health systems, the difference was legible.
The system Jordan already knew
Before the app, the management of Jordan’s condition was a patchwork held together by their own effort. Test results arrived on paper, sometimes days after the event, with reference ranges printed beside the numbers but no interpretation of what those numbers meant in context. They went into a folder maintained on their own — disconnected from the records at the GP surgery, disconnected from the records at the specialist clinic. The folder existed because Jordan had created it. No one had suggested it; no system supported it.
Appointments were bookable, but the booking required persistence — the kind that is straightforward when you are well and difficult when you are managing a condition that affects concentration and energy. Jordan had learned which times to call, and which numbers to try when the first was engaged. These were not skills anyone had expected to need.
The condition itself was manageable. What was not manageable, not sustainably over years, was the administrative overhead the health system had attached to it. The paper trail that was entirely the individuals responsibility. The records that told a different story depending on which part of the system you were looking at. The appointments that were partly administrative events — catching up on information that should have been shared already, establishing a baseline that should have been continuous.
The ordinary cost of managing a long-term condition in a system not designed for the person managing it is a cost that most people carrying those conditions pay, quietly, without counting it as a cost. The honest context is that health technology has not, on the whole, served people in this situation well. Two thirds of NHS patients and carers reported at least one administrative problem in the past year, according to the King’s Fund in 2025 — disproportionately those managing long-term conditions. That history is part of why the difference, when it came, was so immediately recognisable.
The question they asked first
The team that built the app began with a question rather than a specification. Not: what should this app do? But: what does it feel like to manage this condition, and where does the friction concentrate?
Those two questions produce different software. The first produces a list of features. The second produces an understanding of what is actually hard about the problem — which is rarely what the first question reveals, and rarely what someone without the condition imagines from the outside.
The answer, when they gathered it, was specific. The friction was not in the absence of information but in its format and its timing. Information arrived too late, without context, through channels not connected to anything else. The friction was in the administration of care, not in the care itself. The app was designed to reduce that specific friction, in that specific form, for people in that situation.
What came next followed from that question. The design was tested throughout development with people who found digital tools genuinely difficult to use — not only with people who were already comfortable with health apps and quick to forgive poor design. The team was accountable, internally, for whether the people using it could actually manage their condition better — not only for whether the app was delivered within budget and adopted within target timescales. And the design was iterated after deployment, based on how people used the app in practice rather than how they had been expected to use it.
None of that requires a large budget or an unusually skilled team. It requires a set of priorities — a decision, made at the start and maintained throughout, that the person using the technology matters more than the efficiency of the organisation providing it. That decision is not always made. When it is not, the technology reflects the absence.
What actually changed
Jordan’s condition is no better or worse than it would otherwise have been. What is better is the experience of managing it, day to day, in the space between clinical appointments.
Test results that used to require interpretation now arrive pre-interpreted — with enough context to inform a decision, to notice a pattern, to decide whether something warrants a call before the next scheduled appointment. No more calls to the surgery to ask what a number means. The conversation with the clinical team is more useful because the patient arrives with information, and the team arrives without gaps to fill. What used to be a partly administrative appointment is now a clinical one.
The relationship with the clinical team has changed because the technology removed the noise that used to surround it. The paper trail is gone. The catch-up is gone. The time spent establishing what the records should already show — gone. That is not a small improvement in a clinical relationship. It is a different kind of care.
There is also more time. Time that used to go to navigating systems that were not working — chasing results, maintaining the folder, ringing back — is available for other things. The calculation is not large on any single occasion. Over years, it compounds.
None of this is dramatic. The condition is still there, still requires attention, still shapes daily life in ways that are not going to change. But the daily weight of managing it is lighter than it was, and that lightness is the direct result of a design team that started with actual circumstances rather than a generic idea of what a patient requires.
What the design actually did
The app does one thing well: manage this condition, in these circumstances, with these constraints. Not a generic patient managing a generic condition — a specific person, with the particular shape of their daily life. The help it provides is specific to where the friction actually is, rather than matched to what the average health app is assumed to need. That specificity is the direct consequence of the question they asked first.
The app adds something that was not there before. The person using it can now participate in their own care in a way that was previously impractical — reviewing their own data with context, preparing for clinical conversations with real information, communicating between appointments without the friction that made that communication more trouble than it was worth. The participation remains theirs. The app did not take over the management of the condition. It provided better tools to manage it.
That distinction, between technology that substitutes for a person’s agency and technology that extends it, was a design decision, not an accident. It was made at the start.
The app also responds to the individual. Over time it reflects what this person uses, finds useful, needs at different moments. The personalisation is not surface-level — it changes how the app functions rather than how it looks, making it more useful over time rather than more impressive in a product demo. That responsiveness requires a feedback loop between user and team — one that exists only because someone was accountable for outcomes. Which is, again, the decision made at the start.
Four questions for the next project
Think of a piece of technology — an app, a service, a system — that has genuinely helped you, in a way that felt specific to you rather than generic to all users. What made it different? Can you identify the design decision that produced that experience?
If you build or commission technology, how does your design process ensure that the person who will use it is the starting point rather than the endpoint? What specific mechanisms — genuine user research, inclusive testing, accountability for the human outcome — are in place to hold that priority throughout development, not only at the requirements stage?
What would it take, in your organisation or sector, to make conditions like these the standard rather than the exception? Not in five years — in the next project. What is the single first change that would make the most difference?
Is the gap between technology that burdens and technology that helps primarily a technical gap, a resource gap, or a priorities gap? And if it is a priorities gap, what does that tell us about who has the power to close it?
The conditions that produced an app like this are not secrets. They are known, replicable, and not especially expensive. The gap between what exists and what is possible is not technical. The reason it persists is a question for the people who make the priorities, not the people who write the code.
Authors Note:
Jordan 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.
You’re reading The Next Evolution by Neil Catton, articles that explore the human world and the intersection of technology, they try and ask difficult questions - not to scare - but to inform. If someone forwarded this to you, you can subscribe free at neilcatton.substack.com.
Neil Catton is the author of The Next Evolution, The Cognitive Crucible and The Shadow System - available on Amazon, and writes at the intersection of technology, ethics, and human purpose.