Ralph Hawkins

Render therefore unto Caesar

2026-08-29T11:28:28.000+00:00

Still working on a presentation on the future of the NHS. Last week it felt like trying to do 6 weeks’ work in 2. Thankfully, over this week, I’ve got more adept and, thanks to Mike, we found a process that takes a good amount of the manual creation out of After Effects. Half a vignette took the first week; this week we finished nearly three.

Another thing that really helped speed us up was Mike getting access to After Effects on Wednesday. As far as I can tell there are no built-in collaboration tools in After Effects. We started sending zip files to each other like it was 2005.

Mike started experimenting with using AI to build scripts to create some of the animation. I felt a little worried that he was going to demonstrate that we could have done the whole thing in minutes and I’d wasted my time. It put a simple intro together well enough, but anything more complex was comically unhinged. Maybe a new aesthetic, but probably not suitable for our purposes.

Steve and Matt from the Managing my health team wrote a great design history post on the work they’ve been doing to give teams more control of results.

Feeling the After Effects

2026-08-22T18:45:10.000+00:00

I’ve locked myself away this week to build a presentation. It’s a continuation of work on the future of the NHS – how we could use digital to make the whole system work harder for users and staff.

The first version was a series of screen recordings, mostly of prototypes or things based on prototypes. It limited the storytelling to what people see on screens. But the opportunity is what happens between the screens – a user sharing live data with someone caring for them, the system raising alerts.

I wanted to break the edges of the screens to show this. So version 2 uses After Effects to animate the connections and relationships between things.

The problem is I’m the only person with access to After Effects, and I’ve barely used it in 20 years. After Effects is stuck in the same software paradigms it had back then, which is a blessing and a curse. It’s the same as last time I used it, but it’s scarily brittle. Things you’d expect to just work – setting colours globally – can only be done as a workaround, using scripts. Thankfully AI takes much of the pain out of what would otherwise be frantic, endless googling.

The thing about animation is that it’s labour. None of the individual parts are hard or time‑consuming, but the bits add up quickly. It’s hard to resist a little tweak here, an extra bit of overshoot on something appearing to give it more charm or feel more like a phone interface. A hundred small tweaks later, I’d spent a day on 10 seconds of footage.

We don’t have time for that. Thankfully Mike has been a calm voice of reason, keeping my spiralling somewhat in check.

String theory

2026-08-15T21:16:11.000+00:00

For screening services, a result leaves the lab as structured data. Then it duplicates and splits. One copy goes into the screening programme’s own system – structured, readable, never intended for anything directly user‑facing. The other copy goes to the GP record – also never designed for users – but eventually reaches them in the NHS App. By the time it arrives it has been translated, truncated and reformatted by each of the many systems it passed through. What the user sees is a bundle of strings, and the strings are unpredictable. Sometimes they’re readable. Sometimes a result arrives titled “Hum papill vir DNA dtctn assay”.

We want to help users of prevention services get test results in a way that gives them the best chance of being confident they know what it means – and if they need to do something, how to do that thing. If we can consistently and safely match the two copies, the readable version tells us what the messy version means. Then we can enhance what reaches the user – clear, well‑structured information and what to do next. But it might mean hooking into reporting systems that weren’t built for this purpose.

Anything we build works across other people’s software. We won’t know what this changes for other teams until we’re deeper into the detail.

For information governance reasons, we can’t look at the data reaching users to test any of this at scale. We can test if the matching works with a handful of results. But a handful will only be a proof of concept. To know if it works safely at scale, we’d need to test against real data. That might look like a ‘dark’ version of the service. Running against real results under full clinical and information governance, producing evidence for us, while users see nothing until we know it works.

The NHS App alone cannot change this system – it doesn’t own any of this. Designing services within the NHS is like trying to build a rocket to land on the moon – but the component parts were built 30 years ago, by organisations that never met and didn’t know they were building a rocket. There are teams trying to fix this at the core, but that work is big and really, really hard. It takes political leadership and consistency.

This is us making things better in the short term. Trying to untangle knots, or at least understand what thing goes where. It’s workarounds wrapped around workarounds bound up in workarounds. Simplicity for the user is paid for in complexity for services. That cost is real. We’re doing the hard work to make it simple, but we’re also adding to the spaghetti of complexity.

Jeannie had the idea to gather real examples and Alistair wrote up how prevention results appear in the NHS App.

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.