What human-centred really means in healthcare technology

"Human-centred" appears on almost every health technology website, ours included. It is easy to claim and hard to check. A phrase that everyone uses has stopped telling anyone very much.

We think it becomes useful again when you notice that two different traditions use similar words. Product design talks about being user-centred, which means understanding the person in front of the screen and shaping the product around their needs. Health policy talks about being people-centred, which is broader. It is about how care is organised around people and communities, and what part they play in it. A health product that honours only the first tradition can be pleasant to use and still fail the people it was built for.

Two meanings of the same idea

In 2016 the World Health Assembly adopted WHO's framework on integrated, people-centred health services. Its aim is to put people and communities, not diseases, at the centre of health systems, and to help people take charge of their own health rather than remain passive recipients of services.

That is a demanding idea, and it reaches well past interface design. It asks who decides what a service is for, how care connects across settings, and whether people can act on what they learn. When WHO member states extended the global strategy on digital health to 2027, the same language came back. The extension was framed around equitable, resilient and people-centred health systems.

Product design brings something health policy often lacks, which is a working method. Research with real people, rapid prototypes and testing in context turn good intentions into specific decisions about what to build. The NHS service standard opens with exactly this point. Teams should "understand users and their needs in the context of health and care".

The phrase "in the context of health and care" does a lot of work in that sentence. It is where the two traditions meet.

The user is not the only person in the room

Most health products have more than one kind of user, even if only one of them holds the phone. A women's health app is used by the woman who downloads it. It is also shaped by the midwife who answers her questions, the family members she talks to, and the health service she may be referred to.

Designing only for the person holding the phone produces familiar failures. A consultation feature works well for the patient and adds work for the clinician. An education library is engaging but drifts away from what local health workers actually advise. A referral suggestion is clear on screen and leads to a service with no capacity to respond.

The Principles for Digital Development, endorsed by more than 300 organisations, address this in two of their nine principles. One is "Design with people". Another is "Understand the existing ecosystem". Read together, they say that a product's users include everyone whose work or wellbeing it touches, and that no product arrives in an empty space.

What it looks like in practice

For us, taking both traditions seriously changes how we work at each stage.

1. We define the health need before the feature. A product idea starts as a description of a problem people experience, written in their terms, before anyone sketches a screen.
2. We learn from the people who deliver care as well as those who receive it. Midwives and other health professionals see patterns that no single user can, and they know where digital tools tend to create extra work.
3. We test in realistic conditions. That means the devices, connections and daily routines people actually have, not only a well-lit office on a fast network.
4. We design the hand-overs. The moments where a product passes someone to a person, a service or a next step get as much attention as the screens around them.
5. We keep listening after release. Feedback from users and from care providers shapes what changes next.

The NHS standard makes a related point that is easy to skip past. Teams should "create a team that includes multidisciplinary skills and perspectives". At Luna, that means healthcare thinking, product design and engineering working on the same problem from the start, not handing it from one to the next.

Dignity is a design requirement

WHO's antenatal care guidance contains a sentence that we think belongs in every health product brief. Pregnancy should be a positive experience for all women, and they should receive care that respects their dignity.

Dignity is rarely written into a specification, but it shows up in many small decisions. It is in the words a product uses for bodies and symptoms. It is in whether someone is asked for information they do not want to give. It is in how a product responds when someone logs something that worries them, and in whether it treats them as capable of making decisions about their own health.

These are not decorative choices. A product that makes people feel judged or talked down to will be used less, and the help it could offer goes unused with it.

The test we use

When we review our own work, we try to ask a harder question than "is this easy to use?" We ask whether it helps the person understand and act on their own health, whether it fits the way care is actually delivered around them, and whether the professionals involved would recognise it as useful.

Those questions are harder to answer than a usability score. They also say more about whether a product will matter.

If you work in health services, public health or health technology and think about these questions differently, we would like to hear from you. We learn the most from conversations with people who see the problem from another side.