By Emma Raftery-Kenworthy, director of PR and marketing, Aire Logic and marketing lead, The Equity Charter
If you build digital health products for a living, here’s a question I’d like you to sit with. When you’re in a meeting room deciding how a service should work, who is actually in the room?
If everyone broadly shares the same background, the same level of digital confidence, the same assumptions about how the world works, then you have a problem, even if nobody can see it yet.
You’re designing for people who are not present, and the gaps will inevitably show up later in the people you fail to reach.
The people who get left behind by digital health are rarely the ones we picture when we sketch out a new app. They are not the early adopters who will happily test three versions before lunch.
They are the people who already have the least access to care. The ones who cannot get a timely appointment, cannot afford to go private, and do not have anyone to turn to when the system asks them to do something it has not explained.
I keep returning to one woman I came across through a digital health project. She needed a repeat prescription and a change of pharmacy sorted on the NHS app, and she could not make it work.
So, she was getting up at six every morning, in the middle of winter, taking three buses and then walking the rest of the way, just to do in person what the technology was supposed to make easy.
The app was meant to help her. Instead, it became one more barrier in a life that already had too many.
That is what failure looks like, and it is almost never the failure of a single product feature. It’s the failure to have understood her in the first place.
Diversity is not a nice-to-have, it is the build
This is why I don’t believe the argument that diversity is a separate, softer concern, something you attend to once the real engineering is done.
In digital health it’s the engineering. You need teams of people with different lived experiences in the room, people who speak different languages, who have lived in different countries, who have used health services as patients rather than simply built them.
Without that range of perspective, you will produce a product that works beautifully for people exactly like you, and quietly fails everyone else.
I get pushback on this, of course. Some people will tell you that digital somehow makes inequality disappear, that because everyone is on the same app there is no difference in how they experience it.
That is simply not true, and the evidence on the ground is hard to wave away. A poorly understood user is a user you will lose, whatever the platform.
Listening beats translating, every time
Here is a story that changed how I think about all of this.
A team had noticed that white British populations with dementia were accessing a particular kind of support, treatments built around music, which can reach memory in remarkable ways and slow some of the effects of the condition.
Asian populations were not using the service at all. The easy and obvious instinct was to translate the materials into community languages. Quick to do. A clear win, surely.
Except the team stopped, sat down with those communities, and asked them why they were not coming. And the answer had nothing to do with language.
They did not listen to the kind of music on offer. Their music was different, specific, woven into entirely different memories. No amount of translation would have fixed a problem that was never about words.
The solution was not digital at all. It was listening to the end user and understanding what the problem genuinely was.
It is so easy to get this wrong with the best of intentions, reaching for the tool before we have understood the problem the people in front of us actually have.
Research is not a launch activity
If there is one habit I would press on anyone building in this space, it is to treat research as continuous rather than a box you tick before go-live.
It is not enough to do user research once, ship, and move on. You need to keep doing it, every iteration, and with the people who actually use the service, not only a couple of testers who are deeply comfortable with technology and will find their way around any interface you put in front of them.
That means watching how very specific groups interact with an app, taking their suggestions seriously, and feeding all of that straight back to the team that built it.
The people using the service become part of building it, and that is the loop that keeps a product honest.
Don’t forget the staff
There’s another group we often overlook, and that is the workforce being asked to absorb all this change.
Across the NHS and beyond, you have people with hugely varied levels of digital confidence being handed new systems, then upgrades, then replacements, often every few years.
Many did not come into healthcare to wrestle with software. They came to look after patients. Too often the big systems are designed by consultants and transformation teams, handed down, and not really built for the nurse or the IT staff doing the actual work.
People are not trained properly, and no one truly thinks about the end user at the front line. Supporting people through that is not a side issue. It’s the job.
All of this comes back to the same point.
Whether it’s the patient who cannot make the app work, the community the service never reached, or the staff member struggling with a system that keeps changing, the temptation is always to look for the answer in the technology. It is rarely there.
The answer is in the room, if we are willing to invite the right people into it and listen to what they tell us.
That is the discipline, and everything else follows from it.
