I marked the occasion by taking the traditional doorstep uniform photo, and posted a celebratory message to our internal all-hands Slack channel. It can be tough juggling work and parenting, and inevitably the two worlds collide at times, so I’m glad to work somewhere that acknowledges and supports working parents.

After the quietness of last week, the office was busier again, and I enjoyed the hubbub of catching up with people returning from holiday. I even got to meet Benjy in-person for the first time.

Homework

I spent much of the week with Xcode open, exploring design and SwiftUI code for iOS native apps. There’s a lot to learn.

I’ve been reading Apple’s Human Interface Guidelines and the SwiftUI documentation in more depth. Frustratingly they don’t always fully align with each other, a consequence of one being clearly written by designers and the other by engineers. But in general the guidance is good.

There’s also Copilot/Claude too. I’m trying to use it to teach myself things, to explain the design principles or discuss trade-offs, rather than just let it do things for me (although sometimes I succumb to the temptation). It’s tricky though, as the models trend towards (over)confidence and decisiveness, with nuance needing to be coaxed out of them. A useful tool, but not a complete replacement for reading the docs and trying out ideas for yourself.

One of the rabbitholes I fell into was exploring confirmation interfaces. These are often presented when you’re about to do something that has some consequences – in our case that might be closing an appointment booking transaction before you’ve got to the end of it, or removing a message from your NHS inbox.

In the iOS design language confirmations can either be presented in the centre of the screen as an alert, usually with cancel and confirm buttons, or they can be presented as an action sheet which animates into place over the button you just pressed, and just have a confirm button, with tapping elsewhere on the screen acting as cancel. Both are commonly seen. Apple’s guidance recommends using the action sheet to confirm intentional actions on iOS, but also suggests using both sparingly, with not all destructive actions needing a confirmation, particularly if they can be un-done.

For us working on the native NHS App, it’s been interesting to discuss these different options, and what it means for our own design and guidance.

Links

• Modelling clinic capacity in Rubie from the NHS breast screening service team – it’s fascinating to see how different product teams tackle the conceptual issue of organising appointments, with some common patterns emerging, but also some important differences between products to make them work for differing contexts
• BBC News: Flu vaccine rollout begins as NHS regroups from ‘busiest summer’ - the school flu vaccination programme is supported by Mavis, one of our new digital services, and I was very excited to get an SMS inviting me to give consent for my kids’ nasal flu sprays via it this week!
• Will Yvette Cooper and Andy Burnham still abolish NHS England? from Institute of Government explores the political/organisational choices for the new government

Happy back-to-school for all the parents out there!

In both cases, I’ve filled the time with a variety of chores and maintenance tasks.

I’ve finished coding a prototype, assembled some furniture, fixed some bugs, recycled some old furniture, installed loads of updates, sorted through old kids toys, worked on some new features for the prototype kit, bought new school uniform, and on and on. None of these things are individually very impressive, but put together it’s been satisfying to cross a lot of things off my to-do lists.

Next week the kids will return to school, my team at work will be back to full capacity, and we’ll welcome the return of our director Rachel.

But first it’s the bank holiday weekend.

Links

• How might we give teams more control of a test result? explains what our team have learnt from analysing result data in the NHS App
• Manic Mondays: how should we schedule clinics? from Anna Hepburn discusses how the breast screening service team are designing clinic scheduling
• Improving vaccination booking within the NHS App from Jo Lumley shows how her team have improved the drop-in point from the NHS App to the vaccination booking service

Off to Kew Gardens this weekend. Feels like early autumn already.

I’ve had some catching up to do.

Tables, tables, tables

Whilst I was away, version 10.6 of NHS Frontend was released. I made a few contributions to this, along with others.

The most significant new feature is sortable tables. This sounds like a small thing: tables where you can click the column headings to re-order the table by that column – but it has a long genesis.

I first used the pattern almost 10 years ago when working on GOV.UK Ethnicity facts and figures, a service that publishes a lot of tables. We found that not all users discovered it, but for those that did, it helped them explore the data a bit faster. It wasn’t essential, but a nice bonus. It feels to me like a very of-the-web feature.

Since then I’ve probably used the pattern on half a dozen government services, as you always end up with some pages of tables at some point, whether in an admin interface or on some kind of dashboard. Each time I’d copy the code from the last service I worked on (one benefit of working in the open!).

It wasn’t always appreciated. I remember at the Department of Education being asked to build a quick-turnaround data visualisation for a Minister, and beavering away to build a mini web dashboard with some interactive charts and sortable tables, only to be told that the Minister wanted the report as a print out. Oh well.

The Ministry of Justice added Sortable tables to their design system in 2021, and now we have it in the NHS one (ours have different arrows). We’ve made some improvements to the code, so I’ll try and suggest those to the MOJ and GOV.UK folks at some point soon.

Whilst we were looking at tables, the team (Colin, Ananda, Paul and others) added a few other options:

• compact table, which reduces the spacing
• striped table, which can help users distinguish between rows
• scrolling table, which lets a table scroll horizontally if it cannot fit, adding shadows to indicate where there’s more content off screen

These can be combined together, including with sortable tables, giving lots of different options.

For both public and staff facing services, it’s still often better to avoid tables, or to present only simple tables with just the right amount of information. But we do have services for specialist audiences who need to analyse lots of data, and for them, compact sortable scrollable tables may be just the thing. And I’d rather that NHS frontend supports that, in an as accessible way as possible, instead of teams needing to use expensive third-party UI platforms.

Service manual updates

Alongside the NHS.UK frontend release was an update to the NHS digital service manual. I made a couple of modest changes.

The first is a new reference page list all the override classes that can be used in HTML to tweak things. These were largely all documented in the context of the relevant pages, but I found myself sometimes needing to look them up, so having a full list of them as well felt helpful.

The second is even more subtle. Components that are now JavaScript enhanced, like password input, file upload, tabs and others, now have a JavaScript toggle on their example. By default it’s on, but you can switch it to ‘Off’ to see how the components look and behave if JavaScript is unavailable. I added it as a reminder that using progressive enhancement is part of our service standards, and to make it easier to demonstrate how our components meet this.

App prototyping

I’ve spent much of the week working on some new prototypes of the NHS App.

The previous one I did was built in native iOS code, and had several ideas included in it as a bit of a demonstration of our thinking. I made a quick video walkthrough of it before going away, which got shown to a bunch of senior folk who seemed to like it.

This one though is a bit more back to reality, as we want to show how the current NHS App works to show test results (in multiple places), and an a minimally viable initial improvement on this. We hope to test both with users in research, to see if our hunches are right and to learn more about the detailed content design work.

This has meant switching tools and building the prototypes using the existing web-based frontend. In theory it should have been quick to do, using the NHS app design and existing prototypes, but I kept getting distracted by minor discrepancies between how the live app actually looks, and how the documentation suggests it should look. Probably it doesn’t matter for the sake of our planned user research, but I couldn’t resist investigating and updating a few things where I could.

If nothing else, spotting tiny visual flaws helps assuage my fraudulent fears of not having a background in graphic design.

The question to explore was ‘how might we help users find and understand results from multiple sources in the NHS App?’

The problem, as introduced by James is that currently if you open the ‘Test results’ section in the app, you’ll see that test results recorded by GPs are separate from any test results recorded by hospitals (if any). The screens are basically organised by data source. This wouldn’t be so bad, except that there are going to be many more different teams and services supplying test results, beyond GPs.

Users shouldn’t have to know which database holds a test result in order to find it. And for some types of test, like blood pressure or blood glucose, it may be useful to see how the results change over time, regardless of whether the individual readings were taken by a GP, pharmacist, hospital or by the user themselves.

This isn’t a problem unique to test results. James also reminded us that the NHS App at one point had up to 4 separate ‘inboxes’ within it, which have now been reduced to 1.

During the hack day, we shared existing research, mapped out user needs, sketched interfaces, drew technical architecture diagrams, categorised with post-its, and coded up a prototype.

Given we were short on time, I have to admit that the AI coding assistants were pretty helpful for keeping things working quickly and generating a bunch of example test data.

Much of the initial debate was on whether there’s still a need to identify where the test came from, even if that’s not the primary way of navigating. Much of the time, this might not matter too much, but if you had a question about the result, or think there might be a mistake with it, you need to know who to contact.

One of the interesting side-questions we had was: how might you categorise the many different types of test in order to make them more easily filterable/browsable? By body part, like heart, lungs, eyes, skin? By test method, like urine, blood, nasal, questionnaire? By the type of condition they’re testing for, like viruses, cardio-vascular disease, signs of cancer, diabetes? By reason for the test, like whether it was a routine health check or to help diagnose some symptoms? Or some combination, based on user mental models, and the types of test that are more commonly done? We didn’t have a clear answer, but it’ll be a good topic to explore in future.

We ended the second day in my favourite way: by demoing the prototype and talking through our design decisions.

There will be some follow-up discussions, including where this all goes next.

Just as important as the output from the day was the relationships built between the different teams. I really enjoyed working with everyone, and we each brought different perspectives. With the NHS App being a shared surface for many different service teams, it’s important to help us all see how it can fit together, rather than just being concerned about finding our own jump-off points.

I’m about to go on holiday for 3 weeks, travelling through Europe. See you in August!

Communicating the discovery

A lot of my team’s time this week was spent communicating what we’ve learnt so far to other teams, in various forms.

I don’t need to summarise it here, as Ralph and Jeannie have written a design history post: Helping users do more with their results, so you can go read that instead.

Steve and co have also polished up a discovery ‘deck’, which was presented in a show and tell, as well as a long-form report.

My main role was to demo the early prototype I’ve designed. I was a little nervous of this, as it’s full of untested and speculative ideas. I’m avoiding the term ‘provocatype’ but have instead taken to calling it an early sketch. It’s a rough outline of how test results might become a first class object within the NHS app, with notifications, unread statuses, and next steps. I prefixed the demos with a ton of caveats – not least that achieving this will require some significant infrastructure changes – but also hoped that it’d sell our bigger vision.

I think it’s been well received so far. The alpha stage is where we’ll really start to iterate, in collaboration with other teams responsible for the individual services.

Away day

Midway through the week was the summer event for digital prevention services, held up in Leeds.

The keynote speaker was Paul Jones, the Chief Digital Information Officer at Leeds Teaching Hospitals NHS Trust. He spoke passionately and openly about the challenges of managing the hundreds of digital services that the hospital trust relies on, as well as highlighting a bunch of innovative tech projects the hospital has pioneered. What struck me most was how fiercely IT had to compete with other local priorities for funding, and how financial constraints were limiting the ability to modernise aging services. A reality check.

The away day also included sessions on our achievements from the past 6 months, as well as a ‘fail fest’, giving us time to reflect on previous mistakes we’d made, and how we can better create an environment where learning from failures (or ‘falls’, to use the suggested rebranding) is accepted and celebrated.

The day was also a chance to catch up with colleagues, and meet some new ones I’d not seen in person before.

Accepting the meta

Back in London we had a team retro, where I admitted that I struggle a bit with ‘the meta’ of agile planning and delivery. Steve and Jamie are really good at this stuff, and I do not doubt its value – particularly in these early days where we can otherwise feel like we’re grasping at straws.

I can’t always get my head around riskiest assumptions, problem statements, hypotheses, and dare I say it, even user needs. My mind instead races off to think about the details of design and implementation.

But taking a step back can be wise before diving in. We need a balance between the meta and the material.

Links

• The GOV.UK Design System team added the Interruption page pattern this week. I helped with this a bit, as we published it within the NHS design system recently, but it was a cross-government effort.
• Stay put, or keep moving? by Dan Bower identifies a conflict in gradients between clinical and digital worlds in whether keeping moving is the safest option or not.
• Testing ‘one thing per page’ in practice from Michael Watson discusses how the much-maligned one-thing-per-page guidance is being applied to questions about smoking shisha.
• Finding a jump-off from Mike Gallagher articulates how the NHS App is currently a menu of disconnected services, and needs a new narrative to describe exactly how it might become something more coherent.

World Cup was fun. I let my 6 year old stay up for the final. Viva Espana!

It’s been another very hot week. And as the weekend approached, my son came down with the traditional end-of-summer-term vomiting bug. He’s fine now, but we all lost a lot of sleep.

Consequently these notes are going to be quite short.

Good Services, Bad Services

I did find some time on Sunday afternoon to sit outside and read Lou Downe’s new book, Bad Services. I enjoyed it. Especially chapter 3, which discusses how design (and policy) cannot be done in isolation from understanding the materials of how services are actually made. There’s also a great section about building a mandate and environment for people to collaborate in.

The book is a sequel of sorts to Lou’s previous book, Good Services.

It got me thinking about all the previous services I’ve worked on. Some were good, some were bad, and some were somewhere in the middle. Which was largely a function of the organisations they belonged to, and decisions made early on.

Improving services is both a long game and a short game. It relies on hard work, people, building connections, and luck. And as Lou says, it helps if you can be an idealistic pragmatist.

Links

• Synthetic research participants: Increasing efficiency or a shortcut to false confidence? by my colleague Kathryn Murphy-Wright
• The portal trap by Cathy Dutton
• Understanding shisha as a different experience of smoking by Michael Watson
• BRCA2 discovery by colleagues Stu Lorente-Cronin and Lasara Denton
• Your risk aversion is riskier by Audree Fletcher
• GBR urgently needs a brand strategy by Thomas Ableman

Been enjoying the World Cup. Come on England!

We’ll continue learning things – discovery is never done – but now we’ll start designing and testing different ideas, in collaboration with other teams, as well as investigating the technical options in more detail.

Our kick-off was held in person. We had sessions on our existing research, our goals for the alpha, our riskiest assumptions, and creating a stakeholder map.

My main contribution was to run a sketching session.

I printed out some examples of test results as they’re currently shown in the NHS App, as well as examples of the messages about test results, shown separately in a different section of the app.

The aim was to sketch, in low-fidelity Sharpie, some different ways to bring the 2 things together.

In explaining the task, I hit upon some new analogies.

Right now, it is as if you receive 2 separate pieces of paper in separate envelopes. The first contains a detailed table of your school exam results, broken down by subject. The second contains a letter telling you whether you got into the university of your choice or not, and what the next steps for enrolment are. They might arrive in your letterbox on different days, in either order, causing confusion and anxiety.

The simplest design solution might be to staple the 2 sheets together and post them in the same envelope.

The digital equivalent of this might be links between the 2 screens. This could be our MVP.

Another design option might be to merge the 2 things, and design a new single sheet of paper that contains both results and a summary of what this means and what your next steps are.

The challenge for this is that whilst it might make more sense in the moment, it’s less ideal for the longer-term view. You might file the sheet away in a folder for future reference, but the results could become harder to find as they’re cluttered together with enrolment information no longer relevant after you’ve long since graduated.

An analogue solution to this can be found in another classic of school information: the school trip letter.

In these, the top two-thirds of the letter contains the information you need to remember: the date, the times, the destination, whether they need to wear school uniform, and so on.

The bottom third is a tear-off strip. It contains a short form where you give permission to attend, say whether your child needs a school packed lunch or not, and tick if you’re able to attend as a parent volunteer.

The letter goes on your noticeboard, and the strip at the bottom gets returned to school. As well as saving paper, one nice advantage of this design is that you can see at a glance whether you’ve done the thing yet. Paper still intact? Must remember to do the form. Strip at the bottom missing? Ah good, we’ve done it.

It’s not perfect (school bags are not 100% reliable postal systems), but it generally works.

How can we design a digital equivalent of the tear-off strip? Test results that are shown alongside good explanations and next steps, but where the next steps section changes over time. The button to book a follow-up appointment gets replaced with the details of that appointment once booked. And then perhaps replaced in turn with the outcome of that appointment, which might have its own next steps.

Over time, this might evolve into an interface which treats test results and appointments not as one-off transactions, but as part of an ongoing relationship journey between the patient and the NHS.

This is what our sketches started exploring.

There’s no way I can stay up into the early hours, so I’m hoping to wake up to news of an England win instead.

The couple days of anxious waiting to see if schools would close brought back painful flashbacks of the start of the Covid 19 pandemic. And then when many of them closed — partially or fully — the parents in our teams were once again back to juggling childcare and working from home.

Heat is a public health issue. The London Ambulance Service had its busiest ever day. Several hospitals declared critical incidents, with their equipment struggling, or a surge of incoming patients.

I’m worried that these heatwaves will become more prevalent and prolonged. I’m angry that the global warming we were warned about has come to pass.

What does this mean for NHS digital services?

Sustainability was added to our design principles in 2023. Defra have gone a step further and added it as a 15th service standard point, which may become a government-wide thing. Good.

We should be thinking more about energy use and efficiency, perhaps time-shifting compute-heavy tasks to when the electric grid is cleanest. And yes, this means AI too.

Beyond that, is there a need for digital services to directly support people in a heatwave? To help work out how best to cope with the temperatures, or to find cool public spaces for some temporary relief?

I don’t have the answers, but I know that it is hot, and this issue cannot be ignored.

It’s Sunday and my flat is finally below 30 degrees.

I would make a comparison to ‘tech vs doctors’ in the NHS, but I don’t want to include any spoilers so let’s leave it there.

Messages vs data

I’m now a couple of weeks in to working with my new team, which is in the process of wrapping up a discovery. This means that I, along with the other new team members, have been asking lots of questions as we try to get our heads around what’s been discovered and what the proposed next steps are.

The issues are becoming clearer to me. Here’s my interpretation of what it boils down to.

The way the NHS App is designed is constrained by how it works. And how it works is that each bit of the app is a separate web view that talks to a separate database, often run by entirely separate organisations.

One way this shows up is that the messages section of the app is disconnected from all the other sections of the app, even if the message is fundamentally about that thing.

For example, a cervical screening will result in a test result that shows up in the “GP-ordered test results” section, but also a separate message which describes the same result.

The format of the two things are different too. Test results are mainly data, although they can have some lab and/or GP notes attached. Their main purpose is to go into your GP record for health professionals to look at. Users are, rightly, given access to the data too, but it’s kinda not designed primarily for them. The NHS App does its best to help you interpret the results, for example by linking to a massive list of acronyms, but the sheer variety of different test results and the different ways they can be recorded currently makes it hard to do much more.

On the other hand messages are designed for patients, and go through testing and clinical assurance to make sure they’re as clear and accurate as possible. But messages are just text with links (they fall back to being an email or a letter), so whilst they may do a good immediate job of telling patients their result, what it means and what to do next, they can’t easily form an archive of results for you to easily look back on or see results over time.

Because these are triggered by different processes, those 2 things may not appear in the app at the same time. There’s also currently no way to notify the user about a new test result, only a new message.

Having the same test result in 2 places but with different information attached can cause confusion. Or worse, it can cause unnecessary anxiety if the harder to interpret test result is seen before the message.

Resolving this is tricky. I see 3 possible options.

Option 1 would be to improve the test result section so that results are easier to understand and any next steps are clear. If we were also able to notify users about this, then there might be no need to send a separate message.

Option 2 would be to stick with messages as the primary user interface, and suppress or downplay the test results somehow. Maybe the messages could also be improved and the archive made easier to navigate.

Option 3 would be to keep and improve both interfaces, connecting messages and test results somehow so that they both arrive at the same time and are linked together.

This same dilemma applies to messages and appointments. If you get given an hospital or screening appointment, should that appear in the appointments section or messages or both? In the consumer world, Microsoft seem to have decided that meeting invites should appear both in your Outlook inbox and Teams calendar, with the option to RSVP from either. On the other hand Apple event invites appear in a separate inbox within the calendar app.

For the NHS App, I’m not yet sure which is the better option from a user perspective, nor which would be more technically feasible, (although we now have a few provocagrams to try and tease out the options).

I think this is a question for us to explore.

Native app

One thing our team agrees on is that in any alpha work we should skate to where the puck is going and doing our design and research exclusively for the new more platform-native NHS App.

I’ve been trying to prepare for this by learning how to design and prototype for native apps. So far I’ve focused on iOS and using SwiftUI. It’s all massively different from the last time I worked on a iPhone app, where we were using interface builder (Xib) files with a semi drag and drop interface. In contrast SwiftUI uses declarative code that is much closer to the semantic markup of HTML. I like it, and I think we can teach it to other designers too.

The native app design team now has a fairly stable iOS app prototype, and has started moving some of the styles and components into an iOS design system, with a bit of help from me.

It’s early days, and there’s lots of debates still to be had around picking the right levels of abstraction. I’m not totally sure whether ‘design system’ is even the right term – unlike the main NHS design system which is used by hundreds of live services, this is purely for a single NHS iOS app. But it may still help support prototyping and collaboration between design and development.

Links

Only 1 link this week, but it’s a big one: Operating patterns for a more dynamic NHS from James Plunkett, Richard Pope and Abigail Bentley. I’ve not fully digested it all yet, but I’ve a feeling we’ll be referencing it a lot over the months to come.

This is my 100th weeknote. I didn’t expect to keep up the practice this long. If you read these and have comments, do let me know. I mostly write them for myself by I’m happy to take feedback too.

For several years my hearing had been getting slowly worse. Not so bad that I couldn’t hear at all, but enough that I would miss things if people weren’t speaking directly to me, and wouldn’t wake up when my kids made a noise in the middle of the night. Worse in one ear than the other. Worse whenever I got a cold. And bouts of tinnitus. But manageable.

I knew I should probably get it checked but I never got around to it.

And then a few weeks ago I got hit by some kind of viral flu type thing, which meant a day of fatigue but a big deterioration in hearing, even once recovered.

This meant I could no longer hear the television. I had to keep asking people to repeat things. And hushed conversations in the office were so unintelligible that I took to just nodding along. One ear was also quite painful at times. Everything sounded muffled and disconnected.

I phoned the Islington’s extended hours GP service (easier to access than my regular GP!) and was invited in for an appointment within the hour.

I feared an ear infection, but the GP took a look in both ears and told me it was likely just ‘impacted’ wax in the inner ear. She couldn’t even see the ear drums.

She drew me a cross section picture of the ear to show what was happening and explained that “some of us are wax producers and others aren’t”. The wax is there to help prevent infection but it can get pushed into the inner ear where it then won’t naturally escape from.

Did I put cotton wool buds in my ear, she asked. No. Did I use earbud headphones? Ah… Yes. Almost all day, in every one of the many video calls.

She prescribed me some ear spray to reduce the inflammation, and then suggested using olive oil drops daily for about a week before getting microsuction. This is a treatment available now in many pharmacies and opticians. I’d heard of it before but had been nervous to try it. But the GP reassured me that it’s safe and effective. She’d had it regularly herself, and recommended a company who specialise in it.

I duly followed the instructions and booked an appointment for a week or so’s time.

When I arrived the clinician looked into my ears with their head mounted magnifying glass and confirmed that the ears were complete blocked. But he seemed confident that he’d be able to clear them.

Half an hour later, in which I was told under no circumstances to move my head, and after much effort from him, it was done. He told me I had unusual ear anatomy, with a very narrow ear canal, and it’d been the hardest pair of ears he’d treated for 3 years. But the right ear was now completely clear and the left ear 90% clear.

As I walked out of the clinic the difference was immediately noticeable. I could hear the water lapping against the dock of Canary Wharf. I could heard distant sounds of road traffic. I could hear the background conversations of all the strangers around me. It was almost overwhelming, as if noise suppression had been turned off in a video call.

It seemed to take a couple of days for my brain to readjust and be able to mentally filter out irrelevant sounds again.

Of course the biggest benefit was being able to hear the voices of my family and friends more clearly. To be able to participate in more conversations.

It’s not perfect. I still get a bit of tinnitus and one ear is better than the other. But I’m very grateful for the vast improvement.

I’m not sure if there’s a moral of this story. I guess I probably followed the classic health pattern of waiting too long before getting help. I’m sure this can be mapped to the COM-B model of behavioural change, or something. Prevention is harder than reaction.

Tinnitus and hearing loss affect a lot of people. Microsuction is now more widely available, but often not on the NHS for some reason. I think it probably should be.

I bought a pair of over-ear headphones and no longer use earbud ones.

Regular work-related weeknotes will resume next week.

The new team is still part of NHS Digital prevention services, and includes Ralph, Rose, Steve, Jamie, Jeannie and Alistair – a great bunch!

The team has been created because the NHS App is changing, from digital front door to lifelong companion, and our role is to help shape and support prevention services in that future.

This is very different from my previous team.

It means I’m facing 3 big shifts:

Web → App
Staff facing → Public facing
Live service → Early stage design

Web → App

I know the web. I’ve been working with it since the 90s, when it was new and exciting. I understand how it works, its quirks, conventions and history.

Mobile apps are different. I still remember the first iPhones pre-App Store where you’d just use web apps, but that idea didn’t last and native apps soon became a thing that exploded in popularity and are now ubiquitous.

I’ve used mobile apps, of course, but I’ve not really spent much time designing for them, and especially not in the past 10 years.

The current NHS App is mostly web views embedded in a thin app wrapper,but the plan is for it to become much more of a proper platform-native app.

This means new design conventions, new coding languages, new ways of working.

The web is still my first true love, but I’m excited to learn and get stuck in to designing for the NHS App.

Staff facing → public facing

Lots of gov design is designing for services for staff, whether those be civil servants or teachers or doctors and nurses. It’s what I’ve probably spent most of my time doing.

There are government services used by huge propositions of the general public, like GOV.UK or applying for common things like driving licenses or passports, but those services tend to be the minority.

The NHS App though is truly used by vast numbers of people, and the ambition is for it to be used by almost everyone. This is particularly true when you think of prevention services as being used by people when they are well and not just those who are ill or have a condition.

But unlike staff services which might be used by a small group of users for hours at a time, the NHS App is for most people to use but for short amounts of time.

This means quite a different way of doing design and research.

Live service → early stage design

Working on a live service has its challenges but it is great being able to get insight from how your services are actually up the service and then design changes and see them ship, and hopefully deliver real user value.

Whilst the NHS App is a live service, the project to make it more native has only just begun. And although there are a few prevention related things in the app already, the ideas about what prevention in the app could be are at early stages.

The team is just concluding an initial discovery focused on one possible initial starting point, but there is a lot that is still unknown and uncertain.

In recent years I’ve become far more comfortable and familiar with designing for a fairly well defined service proposition than on helping to sketch out and explore possibilities for a loosely held idea.

But I did used to do a lot more of this, including a long stint with BBC R&D where nothing ever went beyond a prototype, so I’m hoping those skills and instincts are still there somewhere.

(Although I hope that we go beyond sketches and alphas, and can test and learn through getting things live.)

As always, I’ll be working in the open and writing these weeknotes to share the journey with you.

Links

• Improving the experience of NHS website health information and service finding in the NHS App
• Two new posts from the breast screening teams: Connectivity and fallbacks and requesting prior mammograms
• The Online NHS Trust has now been formally created and has announced a chair
• Move fast, then fix things – what we learned building Register early career teachers from my old team in the Department for Education
• Faster support for children to get school ready as Tech Sec vows to better connect public services was announced as part of the new National Data Library thingy. There are some relevance to the NHS as sharing data from health visitors is mentioned.

I joined the team back in April 2024. The aim was to replace a pandemic-era legacy service called the National Immunisation & Vaccination System (NIVS), but to design and build it in such a way that it could be more easily extended to other vaccine types, beyond COVID-19 and flu.

At the point I joined, a discovery and alpha had already been done, and a small live pilot was about to be launched. The pilot ended up being the most minimal of MVPs. It worked, but there were lots of missing features.

As I got to work designing new bits for the service, I realised that one of the causes of the slow development process had been that everything had been custom designed (in Figma) and custom developed.

I spent the next 2 years steering the design onto more common ground.

The first step was to advocate for using the NHS design system. However I also realised that the design system itself had been stagnant for a couple of years (the victim of re-organisation and the pandemic). It contained bugs and accessibility issues that had long since been fixed by the GOV.UK design system. Along with others, we copied across the changes and new features from GOV.UK, resulting in the significant v10 update. We’ve continued developing it since, adding new features, to the point where we’re now able to argue that the design system is for both staff-facing and patient-facing services.

I also observed that using Figma could result in designs that looked fine but were harder to do realistic usability testing on, and could cause huge development backlogs by designing new elements which were much more work to implement. I switched to designing in code using the NHS prototype kit, in the process becoming the maintainer of the project (it hadn’t been updated in a while), reinvesting in the kit’s development and setting up training to teach others too.

All the while RAVS was growing. After the pilot we went immediately into working on preparations to extend the service to support a brand new vaccine for RSV. This was a huge opportunity as unlike COVID-19 and flu, RAVS would be the only service able to support recording this vaccination in maternity services and pharmacies. It was an early test of the premise that designing and building a service in-house would give us more agility. And it worked. The RSV vaccine launched in September 2024 and RAVS was a big enabler of it.

As we hit the 1 year mark, the service was much improved, with many of the missing features now added. But we realised that the core of it, the interface for actually recording vaccinations, needed redesigning. It was too slow, asked too many questions, and been developed in a way that made changes very tricky.

Along with my team, we kicked off an initial design sprint to re-think the interface. This involved a deeper interrogation of why each question was being asked and whether it was truly needed. These answers weren’t always easy to come by, in some cases lost to the pandemic era of fast change with little documentation. I suspect some of the questions had been directly driven by the need for stats for those daily televised press conferences.

We dug as far as we could, and ended up with a redesigned ‘streamlined’ interface with fewer, better questions. This didn’t mean fewer pages, as we also adopted the ‘one thing per page’ pattern at the same time, but we observed users moving through it faster with less confusion.

To this day, I remain convinced that some of the best and hardest design you can do in government is removing fields from forms.

We didn’t get it all right, of course. Some users were concerned about the removal of one of the important-sounding fields and had to be reassured that yes we really were sure this was no longer required. We also ended up changing the order of the questions not long after launching the redesigned flow, in response to issues we’d not discovered in research.

In August 2025 we were ready to allow any pharmacy in England to use the service. Unusually for a government service (but more common in the NHS), pharmacies would be able to choose whether to use our service or one from an assured third party provider. To promote ours, we built a product page and an easy self-onboard process, but the marketing effort was otherwise minimal. However word of mouth spread and as of today just over 1,000 pharmacies have signed up.

Some of my most memorable moments with the team have been the in-person research visits to the pharmacies, maternity teams and hospitals using the service. It’s always a moment mixed with both pride and mild embarrassment (there’s always things to improve). But it’s also humbling seeing the teams of people doing the crucial work of reassuring patients and putting vaccinations in arms. The digital service is not the service, but merely a supporting tool which should ideally be as unobtrusive as possible.

I’ve loved working with the RAVS team. The relationships between the disciplines have been strong, respectful of each others’ expertise whilst not being protective over boundaries. Interaction design, content design, service design and user research have melded together as one blurry functional team. I’ve enjoyed the cut and thrust of negotiation with our product manager too, whose ability to slice and dice to a deliverable but viable core is second to none! There is still much to do — including a crucial integration with the vaccination appointment booking service — but I’m confident in the team and I’ll be cheering them on.

Big thanks to Anna, John, Mark, Ileri, Matt, James, Mike, Tom, Shaun, Alice, Amy and everyone else who’s worked on the team with me over the past 2 years! It’s been fun.

I’m away for half term, and then I return to a new role in a new team within NHS Digital prevention services. More on that anon.

So let’s talk about some other topics instead.

Small (not so) boring tools made with AI

In our monthly user-centred design community call this week, we had Joe Julier leading a mini show-and-tell of small tools that he and several other people had made using AI code assistants.

The tool that Joe showed was an interactive dashboard that summarises the different detailed categories of feedback that his service has received through different sources (surveys, support requests, user research and so on), and how they’ve changed over time.

It looks super useful, and hopefully he’ll be writing his own blog post about how it was made and how it’s being used.

Whatever your feelings about AI – and mine are mixed – helping individuals to build small, personal tools seems like an interesting and positive development. If spreadsheets get over-used for far too many tasks (and believe me they are) because that’s all people have access to, then perhaps AI is a gateway drug into helping folk create more appropriate tools using code?

There are of course questions about how scalable, sustainable and maintainable the small boring AI-made tools are, but I’m glad people are experimenting. If nothing else, it proves that you no longer need to buy expensive off-the-shelf software to combine data sources and build a simple dashboard.

Keeping things open, redux

I was pleased to be able to get agreement that prototypes built by teams using the NHS prototype kit can remain open and public on GitHub. These pose no security risk as they are not production code or deployed to production servers. Keeping them open makes it easier for designers to see and reuse it each other’s code across NHS England and the wider NHS family, and helps teams meet service standard 13: use and contribute to open standards, common components and patterns.

Meanwhile the Government Digital Service have published some new cross Government guidance on AI, open code and vulnerability risk in the public sector which argues that private-by-default should not be used to mask under‑resourced maintenance.

Links

• The team building a new digital service for breast screening have announced the name for the their service: ‘Rubie’. Read their design history post to find out what it means.
• I enjoyed this YouTube video about a £2.6 million heist, which is partly about rubbish but also about the digital transformation of government services.
• Coco’s post on the MHCLG blog, From emergency to sustainability: creating Share Homes for Ukraine data got some great coverage from the BBC, highlighting how millions of pounds have been saved by moving a service in-house.
• Fellow ‘nerd-with-a-website’ Steve Messer joined our digital prevention services gang this week, see his weeknote for his first impressions.
• Rebuilding the car tax service in ten weeks in 2014 from Dafydd Vaughan is a great re-telling of moving fast and proving value.

One week to go until half term. I’m hoping the weather gets warmer.

Thing mapping

At our in-person team get-together this week, I organised a group activity to try and map out the things in our service. The idea was to use index cards to name the nouns and string to show the relationships between them, in a manner akin to the crazy walls trope you often see within TV shows and films.

The different disciplines can interpret this in different ways. To a developer this might represent a database schema, or the model represented by classes within code. To an architect this might represent concepts within an API, or even the global FHIR standard. To a designer, these are the words used within a user interface and the navigation between them.

The interesting part was the rough edges. The bits where the interface doesn’t currently match the underlying data model. Or where the words are ambiguous and can be interpreted differently by different people.

For instance, should pharmacies be represented as ‘organisations’ at the at same level as hospitals? And what is a ‘vaccine’? Is it a specific product by a specific manufacturer, or a generic term covering all vaccines targeting a specific disease or combination of diseases?

The point of the exercise was not to reach conclusions on all these questions, but to have the conversations and debate about possible future changes. We’ve had some new people join the team recently, so hopefully this was a useful grounding exercise for them too.

We will make a digital version of the diagram to continue the discussion, but we avoided committing ourselves to the impossible task of always keeping it up to date. The map is not the territory .

Still annoyed that Ryman didn’t sell red string though.

Competitor analysis

On Friday I undertook some gonzo secret shopper competitor research. Or in other words, I got a private COVID-19 vaccination at a national pharmacy chain near the office.

This was mainly driven by not wanting to get ill before my holidays, as has happened in previous summers. But I was also curious what the digital experience of getting a vaccination outside of the NHS would be like.

Booking was straightforward, with plenty of availability. There were a lot of health-related questions though, presented in a chat style interface with Yes or No answers. Not just asking about any allergies, but also about any inflammation of the heart muscle (myocarditis), capillary leak syndrome, bone marrow transplants or long covid. It supported Apple Pay, which is always a win, although paying for healthcare feels weird and makes me thankful for the free-to-use universal NHS system.

I turned up 8 minutes late (got lost) and was mildly told off. Taken into a very small room with the vaccination fridge, a computer and 2 chairs.
The pharmacist read out a bunch more questions from the screen – some of which felt like they were the same ones I answered when booking – and ticked ‘No’ a dozen or so times. Then the vaccine came out of the fridge, and the lot number and expiry date was typed in (in our service these currently have to be pre-entered, in theory saving time and improving accuracy). Left arm or right arm? Click. Needle in arm. Done.

I asked if the record would be sent to my GP, knowing that it wouldn’t be. They offered to give me a paper record instead. This involved hand writing out all the details on the back of a piece of paper intended for another purpose.

It’d be better if these systems could join up, and private vaccinations could be automatically sent to NHS GPs (if the patient consents). We could also let people self-enter vaccines into their own records, perhaps via the NHS App. Both things I’d like to explore in future.

For now, I’ve posted the paper note to my GP and have asked them to record it digitally for me. Let’s see what happens.

Notes in brief

Trying out a new format. Other things from this week:

• Had a call with a designer from a team in a completely different bit of NHS England who’d read my blog post and wanted to contribute some staff-facing patterns. Blogging works!
• Negotiated with our product manager on which features we’ve designed would would be in scope for some upcoming development work. As this was in-person for once, I joked that it was like a trading floor of a market where we were haggling on a deal. Design meets delivery. We reached a good compromise.
• Discussed options for a comms strategy, timings and channels for an announcement we’ll soon be able to make. Still trying to work out what would make it ‘official’.
• Recently hit 2 years of working for the NHS. Someone said I didn’t mark it in these weeknotes so I’m mentioning it now. I’m grateful for the work and still hopeful about the mission.

This weekend was spent putting together an IKEA wardrobe. Mistakes were made. There were insults (aimed at whoever designed the instructions) and injury (minor). They said you shouldn’t blame the user, but in this case it was my fault. Always check orientation in all three dimensions, not just two…!

Totally worth it though, to see the excitement when participants realise that they can actually make things that actually work.

There have been 74 people who’ve now completed the course, and there’s another 80 or so on the waiting list. Over the next few months I plan to think about ways to make it more scalable and sustainable.

Admin

Our talk for Thoughtful Thursday this week was from Julia Cream and Dan Wellings from The King’s Fund, titled ‘Lost in the system: patient experience of admin’.

In this context, ‘admin’ means all of the logistical and organisational stuff that happens around the actual healthcare being given: everything from sorting out an appointment, understanding what’s happening with a referral, seeing test results, collecting medication, and so on and on.

The polling research commissioned by The King’s Fund showed that patient perception of how the NHS handles this admin is poor, and getting worse.

The impact of this is high, with 45% of people in their survey saying their poor experience of NHS admin had made them give up seeking care or treatment.

Fixing this isn’t easy, but they had some recommended actions, including steps to recognise the importance of admin by measuring patient feedback on it, and setting out expectations in guidance.

One of their priorities which caught my eye though was to design and deliver two-way communications.

This is a bugbear of mine too. The most prominent feature of the NHS App is a ‘Messages’ section which has all the trappings of an email or messaging app, including read/unread status, sender names, filters, flagged and removed messages, and so on. Except for one: you cannot reply to anything or start your own message. It looks like email, but behaves like broadcast.

There’s reasons for this, of course, but I’d love to help think through the problems and design some genuine two-way communication channels for patients.

Keeping things open

NHS England was in the news this week over plans to withdraw software from public view over AI hacking fears. There are blog posts and an open letter rallying against it.

I can’t speak to the security threat that AI tools like ‘Mythos’ may pose – I’ll let others far more qualified do that. But I’ve seen the huge value that the practice of coding-in-the-open brings, and it would be a tragedy of the commons to lose it.

Links

• On Maintenance from Sarah Fisher is great. I used to think that digital services were quite different from other civil works in not really having distinct ‘build’ and ‘maintain’ phases. But there might be parallels in other areas too: such as the suggestion that electrification of our railways would be better achieved as a rolling activity from a long-term funded team rather than as one-off big projects. Sounds familiar.
• Weeknote 1: What do we have here? from new joiner Alexandra Deschamps-Sonsino. Welcome!
• For the NHS, by the NHS - our motto for NHS Digital Prevention Services now has a webpage, describing what this philosophy means to us.

The title for this week’s post comes from a Snow Patrol song that I heard a great rendition of by a busker on my way to the office. I had to skip a couple of tubes to hear it to the end and donate. Show me a garden that’s burstin’ into life.

One design system is better than 2

As previously trailed, this week my grid slot came up, and One design system is better than 2 was finally published on the NHS Design Matters blog.

This marks another milestone in our strategy to expand the scope of the NHS service manual and design system to cover staff-facing services – something I’ve covered a few times in these weeknotes, first back in week 22, and then in week 61 and week 75.

The aim of the blog post is to raise awareness of the work we’ve done so far, and to try and prevent teams from working on digital services for NHS staff from going off and doing their own thing.

Not only does this save time and prevent wasted effort, it also impacts the user experience too. Staff using lots of different digital services which use the same design patterns don’t have to spend as much time learning how to use interfaces.

As I try to make clear in the post though, this doesn’t mean that all services will be alike. There’s a huge spectrum, from services used infrequently to daily, and from those used by all staff to those used by a specialist handful. The design system is a common foundation not a finite set of parts which teams have to limit themselves to.

I’ve also observed a second order effect, which is that where staff use several different services which look very similar, but which are not joined-up in terms of the data, they are more likely to (rightly!) complain. This in turn can act as a bit of a forcing function encouraging us to improve our data flows.

Reuse

On Monday I went to the extended leadership team (ESLT) away day for digital prevention services.

One the planned discussions was about ‘reuse’. This wasn’t well defined so meant different things to different people.

My reaction when people mention reuse is to talk about micro things like the design system (see above), frontend libraries and common style guides. There is informal reusing too – designers are magpies, and are constantly copying and tweaking ideas from other people.

But much of the discussion was about the higher-level reusing of platforms and API services - thinks like NHS Notify, Cohorting as a service, Care Identity Service and so on. The NHS has lot of these, in different stages of development.

The result of our discussion was to list 3, perhaps-controversial ideas:

1. Rethink mandates - make products and platforms that are so good that teams want to use them, rather than trying to force them to.
2. Teams should work in the open and promote their services through design histories, show and tells (with no slides, show the thing only!), great documentation and so on.
3. We should identify opportunities for reuse as they emerge, rather than try and architect it all up front. This is more art than science!

Links

• Supporting MenB vaccinations in response to an outbreak – I wrote about the design changes we made to add support for the MenB vaccine
• Improving the booking retrieval process - Jo Lumley documents some great changes that the vaccination booking services have made
• Mapping childhood vaccination data flows - a great post from an alpha team which describes the Bermuda Triangle of childhood vaccination data
• Newborn blood spot notifications - a summary from another alpha team, looking at how parents are told the results of the newborn blood spot test

Heading out for a long family bike ride this weekend. London is great in the sun.

As part of my leadership role I try to encourage designers to work in the open and share their work in progress. This can understandably take people a while to get comfortable with.

So in this spirit, I’ll share 3 bits of interface design I’ve been working on, each of which is somewhat new and I’m not 100% sure of yet.

Search and select

The first aims to solve an issue I mentioned in a previous week, which is a screen of checkboxes listing pharmacies within a single company. Often this will be a short list, but it can be quite long, and in a few cases very long!

To make this a bit more manageable, I’ve now added a:

• ‘select all’ checkbox
• search input which filters the checkboxes as-you-type
• updating count of the number of selected checkboxes
• scrollable region with a maximum height

The search lets you filter on pharmacy name (although they might all be the same), partial or full postcode, and the ODS code. Ideally I’d include the first line of the address too, but the ODS search API doesn’t seem to include that.

The design is based in part on the organisation filter on the GOV.UK Guidance and regulation page, but repurposed for a new context

Check a list

The next page then lists the selected pharmacies, and a ‘remove’ button in case you selected one by mistake. Clicking the button instantly removes that item from the list, with no undo.

If you’ve missed an item from the list and need to add it, you have to go back to the previous page.

It’s quite possible that this screen isn’t needed at all, but I felt that it might be helpful and provide some extra reassurance.

Add another

The third new interface asks for a name and email address for a lead administrator, but lets users add up to 9 additional lead administrators using a button.

This pattern isn’t entirely novel, as it’s based on the Add another component from the Ministry of Justice. However I made some changes, left-aligning the ‘Remove’ buttons, and adding ‘2nd’, ‘3rd’ etc to the headings to help users keep track.

Sketching in code

Each of these 3 interfaces involves a fair bit of JavaScript, and for some of them I’ll admit that I used AI to help, which saved time.

Interfaces like this can only really be explored in a fully working and interactive way, which is why I promote sketching in code rather than Figma.

We’re doing some user testing on them next week, and I’ll publish some notes on the findings.

Links

• RSV maternal vaccine cuts baby hospital admissions by up to 85% from UK Health Security Agency - I’m proud to have had a small role in this
• Should you really trust health advice from an AI chatbot? from BBC News
• 4 things to do before integrating breast screening with GP records from Vero Jermolina
• From garbage can to compost heap by Mike Gallagher

Went to Legoland with my son at the weekend. He didn’t want to do the Driving School ride as he sees no need to learn to drive. Such a city kid.

Getting an official blog post out is a lengthy process with several steps and sign-off needed from multiple teams. The post was initially rejected, but approved after I appealed for more feedback. I’m not entirely sure why, I wasn’t in the room where it happened.

I’ll say more about the post and why we think it’s important when it’s actually live and I can link to it – it still needs adding to the CMS and then a grid slot agreed for publication.

There’s a part of me that understands why there’s a high bar for publishing. The work is what counts. But we do also need to talk about it. Not as vapid fluff, but openly and honestly showing the things as we build them, discussing what we’ve learnt, and inviting others to contribute.

Agile comms are a critical part of the method.

These weeknotes and the weeknotes and blog posts of my colleagues help to tell our story.

Our mission is important, and we’re not throwing away our shot.

Links

• On failure. Or, one song to the tune of another from Sarah Fisher
• Writing a business plan in NHS England from Dan Bower
• Becoming everyone’s problem from Mike Gallagher
• How user centred design became a handbrake from Vero Jermolina
• Mutally assured limbo from Ralph Hawkins

I went to see Hamilton this weekend. Can you tell?

Sometimes working in digital for the NHS feels like a Hail Mary activity. Trying to fix an organisation saddled with decades of technical debt and unfathomable complexity. Against a backdrop of continual organisational restructuring, some big dominant suppliers and shifting political priorities.

We even share some of the same language as space flight, with our mission patches and go/no-go calls.

But unlike the movies, our tale is not one of solo heroic acts. Instead it’s a story of collaboration and smart, multi-discipline teams doing the steady work of building and shipping software, designed around our user. Not enterprise architecture or generic data platforms but specific digital services for specific needs.

This is radical in its own way. We’re working in the open, releasing the source code, and sharing our learning as we go.

For the NHS, by the NHS.

It’s a Hail Mary endeavour but it might just work.

Prototyping with real data

I spent much of the week preparing for some user research that took place on Thursday. We’ve been looking again at how pharmacies sign up to Record a vaccination. The design we launched in August last year has been successful, but it only lets pharmacies sign up one at a time. So now we’re looking at making it easier for pharmacy chains to sign up multiple locations at once.

It’s a tough problem as the chains vary massively in size. There are hundreds of small companies which own a handful of sites, lots of mid sized companies owning dozens, and then there are few big national brands which have hundreds of shops.

We wanted the user research to be as realistic as possible. My initial idea was to set the prototype up with the information about the companies that the users who’d signed up for research were from. But this was a fair amount of tedious work, copying names and addresses into a data file. So I pivoted and decided to just set the prototype up to query the live API of NHS organisations (which includes pharmacies) instead. The data is open and public so I didn’t have to ask permission or worry about privacy.

It worked a charm, and instantly transformed the prototype from being a basic demo to something that feels far more real. It’ll also tell us a lot about the quirks and limitations of the ODS data source too.

The actual interface I’ve designed doesn’t really scale for the very biggest pharmacy chains yet. They basically get a very very long page of checkboxes. But I decided to test with this anyway, as these companies are the exception, and we need to learn more about how they operate before designing anything more complicated.

Vaccination history redux

There was news this week of a meningitis outbreak in Kent, in which 2 students have sadly died. Colleagues from UKHSA and NHS England have mobilised a response, distributing antibiotics and vaccinations.

It’s promoted some further discussion about the difficulty that patients currently have in being able to easily and reliably access their vaccination history. As I’ve mentioned before, the NHS App does offer this, but only if you’ve set it up and have asked your GP to enable full record access, and even then the information may be partial or hard to interpret. For those in Kent, the best advice right now is probably to check with their GP.

One of our teams has launched a check children’s vaccination history alpha which will explore the data problem, with an initial focus on MMR vaccinations.

In Cardiff this weekend there was an NHS Hack Day. I used to love going to hack days (fond memories of a massive one in Ally Pally sponsored by Yahoo!) as they were a great place to learn and experiment. I couldn’t make it to Cardiff, but I did watch the final presentations online, and one team explored the topic of vaccination histories, presenting a prototype called ‘Find my jabs’.

Their prototype aimed to help patients understand that they may have to consult multiple sources to get their complete vaccination record, including any given privately, through occupational health, or by the health service of another country. Well done to the team for giving up their weekend to explore this tricky topic!

I’m hoping we can collectively make some inroads into improving this.

NHS frontend and prototype kit updates

We’ve released a couple of small updates to NHS frontend and the NHS prototype kit.

Version 10.4 of NHS frontend contains a new ‘inline’ option for the header. This is useful in contexts where the header contains only a couple of elements, as it’ll now take up less space on mobile.

It also contains updates to the Nunjucks macros which aim to make them easier to use. Instead of having to remember (or look up) a bunch of special hyphenated class names like nhsuk-input--width-10 and nhsuk-button--secondary, you can now use width: 10 or variant: 'secondary' instead.

For the prototype kit, version 8.1 contains a new date formatting filter. This makes it easy to take a date entered as numbers by the user and display it as the more readable ‘22 March 2026’ format on the check answers page.

Both of these last 2 changes came directly in response to our prototyping training course, where we’ve learnt which things participants find it hard to do. A nice example of user-centred-design for design systems.

Links

• Why the phrase “We need to do a discovery” sends chills down everyone’s spines from Mark at Paper
• The “solution-first” survival playbook from GovCamp 2026 from Public Digital
• Know where your codes are from Giles Turnbull
• Pop-up research at public libraries from Gabe Fender
• Breast screening in mobile vans from Veronika Jermolina

Looking forward to watching Project Hail Mary this week. No spoilers please!