11 Aug 2026: a reflection on reusability

6 months at NHS England, I’ve been reflecting on reusability. I’ve been getting into its weeds through the work we’ve done to align ourselves on it, and how we’re taking it forward, within Personalised Prevention Services (PPS).

Our PPS strategy wants to place reusability at its heart. A mindset of reusing rather than starting from scratch makes perfect sense. Particularly for designers designing the front-end, shared service and content patterns and front-end UI are straight-forward enough to reuse. Doing so means we are learning from previous work, able to deliver at pace, reducing unnecessary duplication and building valuable digital infrastructure for the whole of the NHS. It’s a no brainer.

What I’ve learnt over the last few months is that reusability gets a lot more complicated when you dig into the underlying technology.

Firstly, it takes a lot of extra time, energy and investment to build technical components to be reusable. Is that justifiable early on, when a solution hasn’t yet proven itself in the real world? There is a danger of building for scale too early, when there isn’t evidence of the value such investment will bring.

Building for reuse also brings other questions that take time and effort to answer. If we are building for reuse, have we learnt enough about other use cases beyond our own - and the to-be journeys that would need to be supported by the components we’re building? Can we make the configuration and integrations generic enough without having all the detail of the third party systems we might need to integrate with?

Add to this that there are different ‘levels’ of reuse. Designing for reuse within the ecosystems of PPS and NHSE is one thing. Designing for local health systems to reuse and integrate within their systems is a whole other level of complexity. At PPS, we want to design services that can flex to local need. We therefore need to consider what that means for how we approach reusability.

And finally, true reuse of technical components – rather than just recycling - requires a single source of truth that is kept up to date. This takes us into the land of platforms that need ongoing investment and maintenance.

Within PPS, a tech spike has helped us unpick what it would take to reuse existing PPS components. We now know just how many front-end UI and patterns we have available for reuse (answer = lots). Off the back of this work, Tricia Dever has done a brilliant job of starting a PPS content pattern library to ensure consistency and quality in content across our services.

The spike has also given us enough insight to align on what good enough needs to look like for technical reuse. That means not building for complete reuse from day one, but building components in a way that they can be more easily lifted to build for reuse in the future.

Thanks to Dan Booker-Macedo for reviewing, suggesting edits and general encouragement to get this post over the line!