Ralph Hawkins

Cost per kb

2026-07-18T19:48:06.000+00:00

In Abundance, Ezra Klein and Derek Thompson talk about the cost per mile of highway and railway in the US as a metric of how hard it is for the state to build national infrastructure. It’s disproportionately more expensive to build road and railway there than in the rest of the world. Organisational complexity and outsourcing destroy productivity. The book gives an alternative example – the Madrid Metro was built for a fraction of the cost of US equivalents at least in part because a small team of state‑employed engineers ran the project themselves, instead of the whole thing being outsourced.

It made me wonder if there’s a comparable metric for the way we ship services in government. Something that would confirm or disprove my feelings that NHSE is slowed by outsourcing and blocked by process in a way that other departments aren’t. I had a dumb idea that you could give a cost per kb or something. So, given AI, I set a research project for Claude. It went through GitHub, audited accounts, contract registers and usage stats for NHSE, GDS and a Norwegian equivalent. The tl;dr is that there’s not enough openly published data about spend and many hidden repos. Sad face – but not a surprise.

Claude found a study of the Norwegian department that radically in‑sourced everything, showing that in‑sourcing was no cheaper but faster and better quality. Getting Claude to do the research made me wonder if there was new potential for open, accountable government.

Supply

The Performance Platform was an early part of GDS. The theory was that if government published how its services performed, everyone would benefit. Ministers would see what things cost. Teams would compare themselves and improve. And the public, an “army of armchair auditors” would hold government to account.

GDS attempted to mandate supply of open data.

Demand

I worked on Performance Platform for a few months in 2014. There were massive gaps in the data (departments rarely, if ever, published), and metrics that everyone agreed were admirable in principle but nobody found practical value in. There were very few examples of anyone doing anything with the data. Some supply, but as far as anyone could tell us, no demand. The departments themselves didn’t use it, because it wasn’t detailed enough to be useful to them. Other than some internet‑famous bloggers, no one was using it. No journalists, armchair or otherwise. Performance Platform was retired in 2021.

Better demand

If the demand‑side problem was time and ability – that reading government data takes weeks of skilled work nobody could spare – that problem might now be resolved.

If anyone can now read and analyse the data, the constraint moves back to the supply side. Supply is hard. Contracts Finder publishes less than half of NHS contract awards. The mechanisms of open government don’t have the teeth to be useful, and AI can’t analyse data that was never published. It requires government to put more effort into being open and accountable. But if it did, maybe the impact would be felt this time.

Making things open might make things even better.

I’m on holiday for 3 weeks. Byeee x

Dance yrself clean

2026-07-11T20:13:07.000+00:00

It happens all the time

Designers don’t seem to talk much about small‑scale relationship‑building. When we do, it’s through a framework, with a digital whiteboard, in a workshop – and my soul exits my body.

I spent this week planning how we propose to work with teams. I’m aiming for something that builds trust and keeps things light – agreement we’re moving in a shared direction, and will think about how we support each other’s goals.

Loose working relationships between partner organisations and teams are fundamental to how we work in government. A bit of friendly piggybacking. Build some trust, get some work done.

Killing it with close inspection

Good informal partnerships are mutually beneficial ways of working, with organisational overhead kept to a workable minimum. Mistaking formality for trust is a good way to kill goodwill and momentum.

It works just like a need

I’m aware that I’m a designer who works most comfortably at a level of remove from the user. I like my users spherical and in a vacuum. A predictable set of behaviours and motivations, boiled down to some user needs.

I find it hard to resist doing this with the people I work with too. As long as the work makes sense to me, everything should fall into place. I abstract them into a set of interests and incentives. Abstracting people is necessary for dealing with scale and guaranteed to burn your relationships with a handful of colleagues.

Present company expect it

I don’t hate spending time on warming people up, finding the benefit we are both working towards and ultimately building trust. But I do find it easy to think of this as the work to do the work, less important and more intangible.

I can think of a project where the work was good, but the relationships failed and the project died.

And blow the Marxism to pieces

The people we’re working with are how we get work to happen. Building trust takes time. Showing people that we understand their needs and have the capability to deliver on our (however loose) commitments is the only way these informal relationships work.

Keeping these relationships human is the work and the joy. The shape of the relationship shapes the work. While it’s informal, it’s mutual. The relationship dies when the organisation absorbs it.

Self‑aware crustaceans

2026-07-04T22:50:24.000+00:00

The NHS is many organisations posing as one. It’s complex. Process beats outcomes.

NHS England (NHSE) is one of the many organisations in the NHS. Within NHSE there are seams – we’re still NHS Digital, we just happen to be inside NHSE.

The seams and organisational complexity mean that even if we attempt to build the right thing, the organisation can still treat it as foreign. Putting work into the hands of users is two jobs. Building the service and stopping the organisation from rejecting it.

This complexity rewards those who can navigate it. I suspect that leads to more complexity. Some process is necessary and good when working in health. It’s the machinery for getting work into users’ hands. Politics is how we get through the process – know who to speak to, get a board to approve, or avoid the board in the first place.

In our team we’ve been referring to the alpha being about data and politics. Essentially all early work in NHSE is about data and politics. The data question is – can we connect fragmented systems to make something valuable for users? There are many politics questions. Can we ship with a scope tight enough not to tread on toes, but not so big that others want in or feel threatened by it? The boundaries and how we cross them shape the work.

We’re all trying to do good, but in the absence of clarity it’s hard to know if we’re moving in the same direction. As underwhelming as it is, the 10‑year plan at least gives us something to coalesce around. Something to point at and agree on.

Navigating the organisation takes more effort and is harder to get right than designing the service that gets to users. It feels like working in a bucket of crabs. Everyone is trying to climb out. The thing to remember is that we’re a crab too. Inside the bucket we can only fix from our perspective. Every local fix creates new process or boundary. We climb a little higher and pull the other crabs down.

We’re not stuck in traffic, we are traffic. I don’t want to pull the other crabs down. But from in here, all I can see is claws and legs – and when people push back on our work, I can’t tell if they’re pulling us down or building a crab ladder.

I have been a good bing. 😊

2026-06-27T08:54:27.000+00:00

If we want more things to be in the app – the NHS 10-year plan says we do – then we need to change the relationship the app offers users. This is how the NHS App team talk about their own work. The app is moving from transactional (open the app, do a thing, close the app) to ’relational’, or a ’companion’. For prevention – I think that looks like the app remembers who you are, what you’ve done, what you’re doing now, and helps you do the next thing. Our role is to help this happen in a way that supports prevention services to meet their goals.

There’s a basic but implicit assumption in the app being a companion – fewer of your interactions with the NHS will be with a human. That isn’t inherently worse than speaking to a person, but interactions that get mediated by a screen need to work for the user. The minimum requirement is clarity.

We’ve been looking at test results a lot. The test results feed in the app shows you test results from your GP health record. But the results appear as they were written by the lab that did the test. If they’re designed at all, they’re designed to be read by a clinician. But now they’re available to people in the app. The human has been removed from the loop. You get to figure out what your 1/4 result for the AUDIT‑C score‑freq drunk 6+units (fem)/8+units (male) means.

The lack of clarity is hard to measure. But I assume it reinforces health inequalities. The people with the least health literacy, and the least time to decode this stuff, are harmed the most.

Over the discovery we’ve been thinking about how we add clarity back where the human has been removed. That looks like taking the incoming content from the GP health record and making it make sense. We have some plans for how that might be possible.

One consideration I think I’ve been avoiding thinking about is what users need beyond clarity. Depending on the result, the app might one day need to offer reassurance or empathy to be a companion. For now, we are trying to keep the human in the loop, and stop the software from undermining that process.

The results feed is a hosepipe we can’t turn off. We can’t stop results arriving, but we can make the content clearer when they do. We think it might be possible to give teams control over what they show the user, and when.

Provocagram

2026-06-20T21:57:20.000+00:00

We’re at least 4 weeks into wrapping up a 4‑week discovery. The service manual says you know a discovery is done when “you have a list of ideas you’d like to test at alpha and an idea of which one you’d like to test first.” In practice this line between a discovery and an alpha isn’t helpful. Moving from research into defining ideas creates more questions. Specificity of what we’re doing in alpha matters because we’re looking to partner with other teams. Those teams need to know what they’re agreeing to.

During this discovery, I’ve noticed that I assume the detail in my head is shared by everyone else. It often isn’t. I felt confident about our direction for alpha. Others were still worried. More than once, a detail I thought was baked in turned out to be missing from someone else’s understanding. We’ve got a team that’s good at raising problems and discussing them. Each time, it improved what we’re doing.

A diagram is a good way to get everyone seeing the same thing. A week or so ago I created a rough picture of a solution we could try. It shows how users get results in the NHS App today, and how we could change that – so those results provide context, coordinate with messaging, and align with the approach new teams are already exploring.

I showed the diagram to Frankie – his response was “are you an architect now?” It’s a legit question. I’m not an architect, but I’ve drawn a technical solution. I just want to find a way of moving things forward, having something to talk around. I don’t want to cosplay as a technical person. But I know enough to see opportunities. One team already makes small changes to tens of thousands of result types. Maybe we could make a big change to fewer than twenty. Fewer results. More care in each one. Let’s find out.

Thanks to Christian for gifting me ‘provocagram’.

Middle(of no)ware

2026-06-06T21:17:41.000+00:00

Blame the caffeine

I spent the last week and a half helping Richard Pope create a deck on what the NHS could look like if the technology that supports patients, clinicians, and admin staff was modern and interoperable. The purpose was to show how well‑designed, connected technology could reduce burden on everyone involved and let people focus on the stuff that matters when it comes to dealing with health.

We created 9 demos showing example journeys. For example, a patient does a pre‑consultation check‑in with an AI, which the clinician reviews before the appointment. Ambient voice supports the consultation itself, so the patient leaves with clear, structured notes and next steps. Stuff that is technically possible and happens in places within the NHS, but without consistency and join‑up.

The demos themselves were screens in the app and websites, stitched together using After Effects. Smoke and mirrors. I smashed a lot of stuff together. I think what we had in the end is really interesting, things I’d like to explore more in slower time.

Consistently inconsistent

I’d spent days building a vision of the joined‑up future. Then I dialled into a team day about how the work we’re doing can add value now.

The team has been through people changes – only 3 of the 7 of us have been in the team more than 3 weeks.

We’re close to wrapping up a discovery into how we might help prevention services present results to users. The team had been doing what a group of smart people do and questioning what we were doing and why. When I joined, there were a lot of questions and good ideas. I spent the next hour or so trying to explain why we were where we were. It doesn’t feel good to spend time saying ‘we tried that’, ‘we thought about that’ to a bunch of enthusiastic people. I think if I’d been a little less burnt out and distracted I could have seen the real question the team were asking.

They were asking why we were looking at results and whether it was really worthwhile. Teams in Digital Prevention are doing a good job of communicating what people need to understand through messages. As long as the results are positive and one‑off, a well‑written message offers the user what they need. It also gives the team publishing results what they need – easy to shape and iterate the content.

Improving results isn’t a big value add on its own. The point of results is that they’re a foothold – the first place we can start joining prevention services up, a way to support teams that aren’t working with the app. Two things sit awkwardly together. On its own, the results work is only the start. But it still has to be worth doing now.

You didn’t have to do it but you would anyway

The team were right to question the work we’re doing and think broadly. The answer they deserved wasn’t ‘we tried that’ – it was a better connection from this work to a future where the NHS is more joined‑up. I failed to make that clear in the moment.

Work in the open, it makes things better

2026-05-23T13:33:17.000+00:00

A spicy week at work – decisions made, and people left to speculate. IYKYK.

It’s made me think about what ‘making things open’ means. The GDS principle talks about sharing code, showing work and discussing mistakes publicly. At its core, working in the open is working accountably. Much of the principle, like making the code we write open to everyone, is about being accountable to taxpayers.

But external accountability needs a culture that supports it internally. An organisation that hides decisions from its own staff will struggle to be open with the public. The way leaders treat the people doing the work shows up in how the organisation holds itself to account publicly. Concealment is a decision. So is transparency. Transparency is work. You have to keep choosing it.

A healthy, respectful organisation is a precondition of working openly. In a healthy culture, leaders tell you what’s going on. People can be honest about what is and isn’t working, and own mistakes made for good reasons without fear. Transparency runs in both directions – leaders explaining decisions to the people doing the work, and people doing the work raising concerns without fear of consequences.

Principles are good, but they won’t go far if the leadership doesn’t believe in them. Working openly as an organisation isn’t about show and tells and design history posts – these are signs of an organisation’s health, not the thing itself. It’s about accountability to the people you work with. It’s about trust and respect.

This week I watched people live these values at their own cost. How we show up matters.

The results are in

2026-05-17T08:41:03.000+00:00

We’re 5 or 6 weeks into a 4‑week discovery on how we could help publish results. The work we planned at the start is wrapped up.

The main thing we have left to understand is how we work with teams in alpha. That meant finding a tech lead for our team. We’ve got that person now and we can progress conversations with teams. We’re getting into the weeds of how we’ll work with teams next week.

During a discovery or any research, it’s interesting when what you’re learning tips over from being adjacent context to a part of your scope. It’s easy for me at least to over‑focus on the immediate problem and push the context to the side.

With a bit more breathing space in the work we’re doing, it’s possible to look at the whole problem. The most important thing we’ve seen as part of the discovery is how users are getting results that weren’t designed for them to receive, for example, exposed in their patient record or via documents shared with them. The experience can be harmful and distressing. It’s a tension for the team – is the boundary of the problem the boundary of what our team looks at?

This gets grouped in with the idea that no worrying results should be shown to the user without a healthcare professional to speak to. There are a few concerns that sometimes appear to be conflated:

waiting for a result – where ‘no news is good news’ is the most hostile version of this
not understanding a result – not knowing what the result means for a person’s health or what will happen next. This merges into the need for reassurance, that you’ll be cared for
need for empathy and understanding – to not feel alone with a result

The design for each problem is different. The context changes with the test and the result. I think we can provide systemic thresholds and allow for clinical discretion. My hope is that we can give people more results sooner, with less stress. The design for this needs to work for the whole journey and not rely on humans never making mistakes.

The absolute worst case for all of this is when it happens in a way that no one has designed. The software is working as intended, but the experience for users is created by the gaps between parts of the NHS.

Users getting unintended results is a problem that already exists in the NHS App. We want to set our scope around digital prevention services to start with and need to understand our role in improving the user experience across the whole NHS App.

Aggregators

2026-04-26T17:55:28.000+00:00

We’re half‑way through a discovery into how Digital Prevention Services teams present results to NHS app users.

At the highest level we’re using the discovery to answer 3 questions.

Are there user needs that could be better met by how results work in the app?
Are there team needs that could be met by a shared way of publishing results?
Is it feasible, from a governance, clinical, technical and organisational perspective?

Each of these questions has many sub‑questions.

By results and findings we mean the outcomes of NHS tests, checks and screening, including what they mean and what to do next.

For us, these things make something a result or finding:

personal to the user (not general health advice)
the output of a measurement, test, check, or screen the NHS did
there is an action or a reassurance (for example, you need to do this, don’t need to do anything, or we’ll contact you again in 5 years)

Screening teams often prefer ’findings’ because screening identifies risk or indications rather than diagnoses. The NHS app uses ‘results’ because that’s the word users are familiar with. We’re using both for now.

Currently, there are 3 ways a user could see results in the app:

as a message
as part of their patient record
as a link from the main nav (this is only for users who have completed their NHS Health Check online)

Messages give users the best context, doing the most to help a user understand what their results mean and what they need to do next. However, message inboxes can fill up, results compete with other messages, and they’re harder to return to later.

Results in the patient record have limitations:

they arrive as a stream, so finding a specific result is hard
over 50,000 types of result can appear, and there’s no way to curate what shows
we can’t group related results together (like HPV and Cytology tests)
we can’t show change over time (like weight or blood pressure trends)

The NHS Health Check online results page might be a better model, but it only works for one set of tests. There’s no wider journey beyond it, except a GP referral when results need follow‑up.

At this stage of the discovery, things are taking shape. We’re seeing good evidence of how we can better meet user needs. There’s long‑term potential to add value if results all work in the same way. And there’s enough consistency in team approaches to feel like we can offer tech that won’t be too much of a burden to adopt.

Organisationally I think there’s scope. There are newer teams looking at solving this problem who we should be able to support. The more mature teams will take more time and planning.

We’re still looking into the clinical and governance questions, but they will need detail that comes during an alpha to answer them.

The discovery has been really good for us as a team. Everyone has a clear focus on the questions they’re answering. We start each week with a summary of what we learnt last week. This session is the one I look forward to most. It’s fun having the strands of a discovery come together.

Mutually assured limbo

2026-03-29T21:57:52.000+00:00

My parents have a tray of colourful wooden blocks in various shapes and sizes. I played with them as a kid, my nieces played with them when they were little, my son plays with them now. The game is usually to see how tall a tower you can make before the child knocks it over.

Since my son is less destructive these days, I’ve stopped making a tower to be destroyed, I try to build something aesthetic. Something sculptural and visually pleasing. It’s a small pleasure to indulge that bit of my brain. Letting a sense of emotion and aesthetics guide me, deliberately avoiding efficiency. This feels like creativity to me. It doesn’t feel like design.

Design is a process – empathise, define, ideate, prototype and test. These steps don’t need to be creative. It’s often logic and application of patterns. Find a proven solution and adapt it.

I’ve been a graphic designer and an interaction designer, I carry those skills with me. The idea of a designer makes sense to me when linked to a material or form. Writers use words, mathematicians use maths – an interaction designer uses code, visual language, words, to make a series of screens into a journey. When work doesn’t have a material, is it design?

Service design doesn’t have a material. Or if it does, those materials aren’t unique to service designers. Research, mapping, workshops, decks, conversations – things anyone in a meeting can do.

Service design is about creating shared understanding – mapping what exists now, prototyping what could. These days I plan and communicate. I’m not sure this makes me a designer.

I’ve done a few getting to know the team sessions since starting a new role this year. I find myself saying “I like making things”. Taking pride in execution. Communicating with precision. I think this sometimes makes me quite annoying to work with.

Live alpha

2026-03-21T23:03:39.000+00:00

This week I spent two days at the Products and Platforms planning event. The fifth one of these I’ve attended – they’re starting to feel less overwhelming. One of the unconference sessions was on test and learn. The discussion focused on problems people face trying to be agile in a deeply risk‑averse organisation.

For services that help users form habits or manage conditions, governance that doesn’t support us to test and learn is a blocker. The normal moderated research sessions we can do in the alpha phase aren’t sufficient. In an interview a participant might tell you they’d quit smoking or start exercising, but would they? What would their actual experience be like?

We need a way to test the purpose of the service, to see if we can impact behaviour over time. But putting something unmoderated out into the world without following the rigorous standards designed for scaled services has proved so hard that teams have given‑up trying to do the necessary testing in alpha and had to move to private beta to get anything done. Quick, small‑scale pilots are extremely difficult.

‘Pilot’ has become a banned word.

I think for good reason. Pilots are often an end in themselves, or can be seen as a way to get a service live without going through the necessary rigour.

Last year, I went to a meeting about running a pilot. A big meeting, lots of investment in time, lots of expertise in the room. I asked a few times what the pilot was looking to learn, the team said that they were going to get to that. I still don’t understand why anyone would decide to run a pilot before knowing what they need to learn from it.

As an assessor I’d struggle to pass a team through an alpha assessment without proving the core purpose of their service worked. I think part of the solution might be as simple as working with the various governance boards to create a new phase – between testing prototypes in alpha and building the MVP in private beta.

A ‘live alpha’.

Irina and I wrote a definition of pilots last year. A working service, tested with a limited group of real users, for a defined period – not built to scale, with clear success criteria and a decision point at the end. The idea was that it would sit within the second phase of an alpha.

Live testing not tied to production ways of working will become even more important as we start to use AI in our services. With AI you can’t fully specify the service, which means the normal model of ‘build it, then test it’ stops working.

The relationship is the service. You can test a relationship in a prototype, but to understand if it’s safe and has any real impact, you need real users, in real moments. A live alpha is the only honest way to test something that can’t be fully specified before you commit to an expensive build.

Living in an old house

2026-03-14T22:14:48.000+00:00

I worry communication can become an end in itself. Explaining what we want to happen instead of making it happen.

I spent some time this week writing a deck to set out the framing of what the Managing my health team is doing. I care that we communicate well. Clear language, nothing to hide behind. No use of ‘empowered‘.

Still, I could have been more precise. I used the phrase ‘in the app’ throughout, assuming it was clear what that means. But ‘in the app’ could mean a link to a website, a native journey. Something shown to everyone or only at the right authentication level, or something personalised and persistent.

A deck is a useful first iteration. Get stuff down on a page, make it look legit and get a reaction. Be wrong on the internet. Our vision – ‘Connecting NHS services in the app so it is easy for people to prevent ill health – for themselves and the people they care for.’ Connecting services across the NHS is the frame we’re working with. We might be wrong.

We’re committed to the 10‑year plan vision that the NHS app is the front door to the entire NHS, while also believing that only relevant things belong in it. These aims seem contradictory. But the only way to be a front door to everything without overwhelming people is to help them find what matters to them. Curation is a design principle. It requires something the NHS isn’t set up for – sharing data across services so the app knows what’s relevant to show you. The hardest button to button.

The transactional to relational scale is a way of being open about scope. Transactional services – like vaccines – are discrete, low‑intensity, and the app already does them. Relational services – managing type 2 diabetes, losing weight – are ongoing, complex, and would represent a significant shift in what the app is for. We want to start with transactional services and build from there.

We’ve grouped our ideas into four themes, each named for the job it does for someone:

I know what I’ve had, what I’ve missed, and what’s next
I find out about risks and act on them
I manage my condition and stop it getting worse
I get joined‑up care, from screening to treatment

The themes are vaguely in order of impact (lowest to highest), all of them are difficult.

Each theme has measurable outcomes and a list of smaller, concrete, shippable ideas underneath.

I’ve struggled to find the time to get our ideas down in detail. Too much of it lives in my head. We can’t move as a team until I externalise it. Once I have documented our ideas – as dispassionately as I can – the team can prioritise them.

Communicating the process is necessary, but it's not the point. The goal is to make a difference to people’s health. Until we can start having an impact I’m going to feel uncomfortable.

Nautilus

2026-03-07T20:34:45.000+00:00

This week we stopped to question whether we were moving in the right direction. It’s early days, but we felt like we’d made a false start. I’m torn between wanting to move forwards and the need to make sure we’re creating solid foundations.

We tried to move fast – find somewhere we could add value quickly, learn what it takes to make changes in the NHS app. Unsurprisingly, there’s not much we can do that has value, progresses the strategies of both Digital Prevention Services and the NHS app, and isn’t incredibly complex.

Scrimshaw

With new people joining a couple of weeks ago, it felt like a good time to reassess. What’s our purpose? What foundational work do we need to do to reduce the risk of going in the wrong direction?

Even with a small team, communicating clearly about our purpose matters. We’re now five people. I can’t assume everyone is on the same page.

I started by framing the purpose of our team to be the intersection between the goals of the Digital Prevention Services – helping people stay healthy, and the NHS app’s goal of being the primary way user’s access the NHS.

R‑Type

For me, there’s one riskiest assumption. ‘Prevention’ or ‘reduce your risk of getting ill’, or whatever we end up calling it makes sense to users as a single concept. We need an informed view of this to shape almost everything else. The last thing I want is to ship our org structure if it doesn’t match how users think.

We started by exploring whether to put screening and vaccines on a single page. I built a prototype to explore what this might look like – the data needed, how you might organise it. But screening and vaccines are just two things that reduce risk. There are many others, for example taking medicine.

A chronological view feels inside‑out. Organised by when things happen rather than what they mean to someone. This probably changes depending on who’s looking. Parents might think differently about their child’s record than their own. Most people will only care about the most critical thing – what have they missed? What needs action now?

That matters most for people who are least likely to chase up. People who move frequently, have lower health literacy, or have had poor continuity of care. The people we most need to reach.

Dowager

When we look across the ideas we’re exploring, they fall into two groups. What we’re referring to as transactional services – one‑off things like screenings and vaccinations – where theoretically the app can help people know what they’re due and act on it. And ongoing support – behaviour change, managing long‑term risk – where the relationship between the user and their health is sustained over time. Different problems. The transactional stuff is hard, really hard, but people are working on it. Ongoing health management might never be part of the app, or if it is, it’s a long road to get there.

Blackfriars

The prototype I built is useful to talk around, to explore what data needs to be available and what will be hard about this, but it’s leaping to a solution. I’ll be more comfortable starting with basic user needs and mental models. How do people think about reducing their risk of illness? What do they need to know, and when?

None of these ideas are small. Making any of them real will need commitment from across the NHS. I keep reminding myself we’re not going backwards – we’re just building more structure before we move.

The (post‑it) notes you don’t play

2026-02-28T23:46:58.000+00:00

Oli Lovell asked me what it would look like to create the optimal experience for users looking after their health. It’s one of those questions that feels both easy and hard. I spend a lot of time thinking about the user experience for prevention services – I feel like I should be able to answer easily – but I haven’t spent much time actually thinking about the perfect experience, because I spend all my time looking at problems.

But it’s actually quite an easy thing to answer. Don’t make users have to think. Show them what they need. Help them move through any journey – coping with the infinite complexity of health and associated factors – show them only the most useful things without limiting their options.

Easy to say. Hard to do.

The NHS is a fragmented system, the user experience as a whole is no one’s responsibility. Can we give a connected experience for a whole pathway – the way GOV.UK treats ’learn to drive’ as a single thing a person does, not 17 separate transactions.

I started mapping the process a person goes through – from first contact about cervical cancer screening, just after they turn 24 and a half, through to treatment if it’s needed. As with all of these things it’s an abstraction. The map is not the territory. I keep a list of things I’m not including, to be transparent about how surface my representation is – people with learning difficulties, language barriers, those experiencing homelessness, survivors of sexual violence. The list gets long quickly.

From that mapping, a theme emerged. Things that are connected for a user – a letter, an appointment, a result, a follow‑up – are owned by different organisations or held in their own system with no simple way to talk to, or rely on each other. For example, the system that triggers an invite to cervical screening has no knowledge of when a user books an appointment. For the user, it’s one thing. For the NHS, it’s a hand‑off between systems that don’t speak to each other. The NHS has to design with the assumption of worst case scenario because it can’t verify that another part of the system has done its job. Independent, loosely connected entities. Each system stores its own data because there’s no trust. If you can’t trust the record someone else holds, you keep your own – there are as many versions of the truth as there are organisations involved. The last fallback is always the GP, everyone sends a letter to the GP.

The fix doesn’t start with tech or design standards. It starts with relationships between things that are connected for the user across organisations.

The 10‑year plan describes the app as the front door to the NHS by 2028 – the primary way patients access, navigate, and manage their care digitally. That means it has to own the experience. The NHS app might be a way to help the NHS think differently about how it helps users understand services. Not because the app solves the problem, but because it could force connections. To connect a journey in the app, you have to connect the organisations behind it. I think we can test this with one or two pathways in one or two areas, but lasting, sustainable change will need something more fundamental in how we work.

Conway or another

2026-02-21T08:11:39.000+00:00

This week I ‘finished’ prototyping our first ‘idea’. It’s been a useful exercise – thinking through making, surfacing questions.

In the first few weeks of the year we spoke to teams across Digital Prevention Services, looking for places we could add value as a team that looks across prevention services. We came up with a list of ideas, shortlisted them and presented back to our team. We ended‑up bringing several ideas together. Which means we have something that is a vision, but is a long way from being achievable.

The prototype shows users which health screenings and vaccinations they’re eligible for, lets them book appointments, record vaccines they’ve had elsewhere, and opt out of things. It also supports proxy management – for example, parents can view and manage their children’s vaccinations. This is a lot of things. Way beyond what we can do now. That wasn’t what I wanted to make first. Last year I created a prototype of a vision and I knew it wasn’t realistic. I’d like to focus more on iteration instead of visions, we need to split out what we can start with.

Does ‘prevention’ make sense to users?

The core of the idea explores whether there’s value in combining the view a user has of their vaccines and screening in one place. This builds on the work the vaccines team are doing to show the user what they have had and are eligible.

This tests one of my biggest concerns – that ‘prevention‘ is a concept that makes sense to users, and we’re not just shipping our org structure. Putting these together in one view gives us some sense of what this means. When it comes to testing, we’ll need to start with card‑sorting to stop us from influencing the participant’s view.

Can we show things that work differently side by side?

There are many difficult things about actually combining screening and vaccines. There is no single, reliable record of those things. We don’t get screening attendance data until weeks after the appointment. Vaccinations are recorded in different places depending on the vaccine and who and where it was given.

Screening and vaccines work differently. Users can book vaccines or find a pharmacy and get one there. Screening, the user can be given an appointment they need to attend, invited to book, or sent a kit. Can we show people that they’re eligible for two things side‑by‑side but also make it clear they can book one and for the other they need to be invited?

As a first iteration could we allow eligible users to order their bowel testing kit from the same page as where they can see their vaccine eligibility. Being incomplete may be dangerous. If we cannot show a person all the things they are eligible for or have had because we don’t know enough to tell them with confidence, in the worst case the user could assume they’re not eligible and miss a screening or vaccination. We’re speaking to clinical colleagues next week. It’s a design constraint other teams have faced – if you can’t show someone everything, showing them something partial might be worse than showing them nothing. It’s not clear yet what my team’s role in taking something like that on is.

Taking a leap of faith that we can get the data. Is it useful to show people what they can do, what they’ve missed and what they’ve had? Another hypothesis we want to test is whether showing people what someone they care for (for example their child) has had and will have is more valuable than seeing your own record.

I think the minimum we’d need to do is help users to book these things. Giving people the means to take action and not nagging them to do something without making it easy to do it is a principle of our team.

Can users tell us things the NHS doesn’t know?

From the list view – we could help users manage what they’re eligible for. For example, there are some vaccines where eligibility can change depending on information the NHS won’t have a record of. For example, if you have become a carer. But if you were to tell us that, we’d know you were eligible for Covid and flu vaccines. Or the user could tell us they got flu vaccine in another country, then we could record that and show it in the history and stop reminding eligible people to get one.

We have a hypothesis that if we want to personalise a person’s experience in the NHS the self‑reported data is fundamental. The NHS Health Check online private beta is already doing this. Testing other ways this could work would be valuable.

There’s a tension here that if we know something about a person then someone is clinically responsible for it, we can’t ask for someone’s blood pressure without taking responsibility for it. Asking a user if they have had a vaccine might be a way we can test this idea with relative clinical simplicity.

Can we design for the system as well as the user?

Part of our team’s purpose is to speed up prevention teams working in the app and make the journeys they create work better for users by offering a coherent journey across services. If a page that shows users what they’re eligible for also works better for people building services, that’s an exciting proposition. Can we offer a simple way for teams to onboard their services and present them in context?

Presenting prevention

We’re trying to keep the scope of the thing we do first small, none of that is small. We’re looking at ways we can work with teams, but also we need to be realistic about the complexity of the work we’re doing.

It’s tricky to not want to go after something and dig into the whole of it. I often want to look at how we might work with one of the journeys. The work we’re doing is about improving how things are presented. Reducing the burden on users by making the system less overwhelming.

We have some other ideas about smaller experiments we can develop – ways to test the boundaries of what’s achievable before committing to the bigger vision. Next week we’re looking at what it might mean to use the app as a mechanism for targeting users based on their cohort and what screening or vaccines they’re eligible for. Could it be done in conjunction with a campaign? Could we allow local health organisations to control what they promote to who?

Some excellent design history posts published this week

I heard you like apps, so I put an app in your app

2026-02-15T08:45:31.000+00:00

Doing work in a big org sometimes feels like trying to leave the house with a toddler. If you could stack the tasks back to back, the whole thing would take 15 minutes. But instead you need to carefully coordinate each thing individually. Give 5 minute warnings, distract, play, indulge, not lose your shit when they refuse to wear a coat even though it’s raining. They can sense when you’re stressed and so remaining calm is vital.

We didn’t get to speak to all the teams that are involved in our first experiment so I can’t talk about the detail yet. It’s a bit frustrating that we couldn’t make calendars line up.

We did speak to a few people and with each conversation we’ve honed the idea and our approach, it’s starting to feel concrete. I can see how the work will support and build on other work in Digital prevention services. There’s a core idea the work is built on that we need to test, but as long as that assumption holds true then I think we’ve got something that will add value, designed around user needs and built for what helps the system meet those needs.

If we can get agreement on the idea across Digital prevention services, I think the next thing will be to start a more formal discovery, it can be lightweight, but needs rigour that we’ve not applied yet. Testing assumptions about data and putting prototypes in front of users.

A theme that has come up a couple of times since we started on Managing my Health is what belongs in the NHS app. To me, the rule is only put things in the app that earn the overhead of authenticating – the app is a secure environment so we can show people sensitive information, don’t show them things they could find on the web more easily. So for example, not showing people a list of things 65‑year‑olds are eligible for, but showing the user what they are eligible for. This is harder than I’d assumed though – we can’t always be as confident as we need to be to infer eligibility. Part of the discovery will be understanding what data we actually have access to and how reliable it is and what we can do to have the certainty we need to create a journey that works for users.

Exchanging long protein strings

2026-02-07T16:06:58.000+00:00

We decided on the first experiment for Managing my Health and started prototyping. We’re exploring whether joining up existing work that’s previously been separate will make sense for users. There’s potential to use it as a jumping off point for a few other things we’ve been thinking about. I don’t want to say more before we talk to the teams involved.

Building the prototype showed how complex eligibility modelling across services will be. It’s nice to be doing tangible work, but if I’m honest, I didn’t want to start designing before speaking to the related teams. But we’re under pressure to show what we’re doing and sell the vision.

Next week we’ll speak to the teams our experiment is related to. Just presenting ideas at teams won’t be enough. We need to back it up with our own ability to contribute and clarity on how we add value that’s worth the distraction. We have funding to build software ourselves, but we’ll need to collaborate. Breaking silos comes with an overhead and we need to own that. It’s what our team is here to do. We’re testing what this takes as much as we’re testing what works for users.

Next best action

2026-01-31T10:48:19.000+00:00

The first priority for Manage my Health is to find something we can ship relatively quickly – test our approach, learn by doing, add value. We’re looking for something a cross‑cutting team can do, ideally connecting between services.

We spoke to product leads across Digital Prevention Services this week about their work and working with the NHS app.

The app sits at the apex of all the things that are difficult about working on digital services in the NHS. It’s on top of a patchwork of technology, data, organisations. Finding eligible people is messy. Creating joined‑up experiences is difficult because the basic building blocks you’d expect to exist – like standardised ways of classifying appointments – don’t. The plumbing is fucked.

Because everything is so hard, even things you’d think should exist – like a list of screenings you’ve attended – need to prove their value. Dan Bower questioned whether the app adds value for some journeys. If we send someone a link and it works, why add the friction of logging in first?

The app has an outsized influence, in one good way at least. It’s a point of coalescence for the NHS. Something that the rest of the organisation can see as useful – a way into their services. Our job is to find a way of doing that which works for users.

In the spirit of working openly, here are some high‑level ideas we’ve been discussing. Very early days, not yet agreed, not exhaustive. Not filtered by how achievable they might be.

Personalised health risk summary

Make abstract risk more tangible. Example: persistently showing your heart age after completing an NHS Health Check.

User‑submitted data

Improve personalisation and control. Example: recording a vaccine you had privately or abroad, so you don’t get prompted for something you’ve already done.

Local NHS can enable home monitoring

Give users easier access to monitoring that connects with their care. Example: an ICB selects a cohort who need to record blood pressure, using the app to track it.

Next best action

Guide users through the complexity. Example: after an NHS Health Check identifies lung cancer screening eligibility, suggest completing the pre‑screening questionnaire.

Book a prevention specialist

Help users get consultation on what they could be doing. Example: pilot using WhatsApp or any messaging platform with a small cohort.

Prevention overview

Clearer expectations of what’s upcoming and access to records. Example: a summary screen showing vaccination, screening, and health checks.

Better messages

Use what digital communication is good at. Example: prompt someone to complete an NHS Health Check after a vaccination – catching them while they’re engaged.

Health goals

Support sustained behaviour change. Example: set one goal, receive a monthly check‑in asking how it’s going.

Looking at that list, I worry there’s nothing in the sweet spot – shippable within weeks or a few months and adds real value. We spent time last week defining criteria for choosing what to work on. I think we can simplify this to – find something that looks remotely achievable.

Another korma

2026-01-23T17:58:08.000+00:00

This week, Manage my Health went from being me, to a proper team of 3. This has been great, progress feels more tangible and I get stuff out of my head. When new people join the team or we talk about the work, I often mention that I think we as an organisation are over‑indexed on the NHS app. The NHS is a massive (set of) organisation(s) with GP surgeries, hospitals, websites, etc and that focussing heavily on an app feels like a strategy that underutilises the strengths of the NHS. I think these days the desire to make apps, born out of FOMO, has mostly translated into the desire to do AI. I guess apps are moving into the trough of disillusionment phase.

My new job, which I like doing and am excited to see where it goes, is to help bring prevention services to people through the NHS app. So it’s helpful to think about what having an app on your phone could offer users for prevention. There are some things we could offer (assuming we do our job well):

easier access to one‑off actions – booking a screening, getting a vaccination – without navigating the system
relevant services based on the user’s needs – they don’t need to know what exists or what they’re eligible for
proactive contact – I’m not sure if this will be possible, but speaking to users when they are in the right frame of mind will be more effective in helping offer support
support for behaviour change over longer periods – not a one‑off appointment
a private interface for sensitive topics – for some, preferable to a conversation

All of this is a big change to how the NHS app works at the moment. Currently the app is good at supporting users to do tasks like order a prescription, check a message, or view a test result.

Adding prevention – especially anything around behaviour change – will make the app into something different. One big theme from the NHS 10‑year plan is that the app will be all the things. There aren’t many ‘all the things’ apps. Different apps for different things tend to be the model. For example, Apple and Google split mail and calendars into separate apps, and as Mike Gallagher points out, not following platform conventions causes friction and erodes trust.

We had our first conversation with the Child Health team this week. They’re the only team in our area organised around a demographic rather than a type of care. The app is designed around managing your own health. But parents managing children’s health have different needs. They want to schedule two children’s appointments together, to see screening results and health visitor notes. Someone with postnatal depression needs support for themselves and their child at the same time. Proxy access, family health, caring for others are different models of care that the current app doesn’t support well.

We’re looking for small opportunities to start with. Places where a cross‑cutting team can support the work that’s already happening. But we’re also trying to think about what the long‑term might be. What should be in the NHS app and if and when the one‑app‑for‑everything approach starts to break – is something we’ll learn as we go. Maybe we’ll find out that smashing everything into the app is a good strategy.

Dilated peoples

2026-01-17T16:46:00.000+00:00

‘Prevention in the app’ is no more – we’re now ‘Managing my health’. This is positive for us because it gives a clear scope and we no longer share an acronym with ’pain in the arse’.

This week I finished the demo I’ve been building in Swift to show what it looks like when we can connect between health checks, screening and vaccines. It’s similar to what I’d built before, but using the components the app team have been testing as part of their exploration of whether the NHS app should be a native app.

It took me longer than I anticipated to finish because:

I’m bad at estimating how long things will take
I added a few more pages than I was planning on at the start
I spent most of a day this week in eye casualty because I have an inflamed iris
I’m teaching myself and using Claude to teach me Swift

Using AI to teach me to program in a new language has been mixed. It’s great in that you have a teacher who can give specific guidance and instant feedback. But also that teacher can be a bit nuts and it’s hard to resist just asking the teacher to do things for me. It’s faster than having to google everything, but also I’m probably not gaining the benefit of seeing adjacent concepts. I’m forcing myself to ask for explanations, but I’ve also just given in and pasted code where I know there’s a typo and can’t be bothered to find it.

When I started learning front‑end for web, a dev gave me a tip I still think about. Type all the things, don’t copy and paste. It helps to retain the things you need. With Claude, it’s not just copy and pasting I’m actively resisting but also just having the LLM write my code for me. I try not to put anything into my work that I don’t understand.

What else could a cross‑cutting team do?

The first phase is understanding what teams across Digital Prevention Services are working on. Over the next few weeks we’ll find where connecting journeys might improve outcomes and run experiments around these.

I’ve been thinking about what else we can do. Prevention governance is local – local authorities commission behaviour change, ICBs own screening uptake, vaccination happens through pharmacies and GPs. But the app is national. How do we design for this?

What if local commissioners configured what appears for their population? Local authorities choose to offer blood pressure monitoring in the app. Areas with low screening uptake surface it more prominently. Vaccination teams add their pop‑ups.

This mirrors existing accountability. Local commissioners already own outcomes – the app could extend that instead of creating something parallel. We offer more control, in exchange for more responsibility.

The obvious difficulty is capacity. We need to find ways that support or build on existing processes and incentives.

My eye is fine. Just needs 245 eye drops over the next 6 weeks.