In public sector design there is rarely an uncompromised solution. We have to choose what we prioritise and what or who we optimise for.

The NHS App is a hub with an ever‑increasing number of spokes. For it to offer simple, clear journeys through a network of services, we all have to keep choosing between what an individual service needs and what the network needs.

Teams design well for their service’s needs, but often don’t see how their approach will compromise the whole. That sometimes looks like:

  • research that doesn’t involve the step before or after
  • success measures that stop where the service ends
  • a request for a hub

I love the architect Eliel Saarinen’s idea of considering a thing in its next larger context: a chair in a room, a room in a house, a house in a neighbourhood, and a neighbourhood in a city. Design for the context your work sits in. For us it’s something like a screen in a journey, a journey in the app, the app in the NHS, the NHS in someone’s life, and someone’s life in society.

Wanting a hub isn’t a failure of imagination. It’s a way of keeping control, putting a gap between everyone else’s noise and your understanding of your users. In an organisation as unpredictable and hard to deliver in as ours, asking people to give up control and spend energy looking sideways is a big ask. For most teams, looking at how the whole works isn’t the priority, and it’s hard to do on top of delivering.

If the app’s structure makes connecting too expensive, most of that cost should sit with the people who own the shared space, and not be passed down to teams.

At the same time, treating a service as a spoke rather than as part of a network isn’t sustainable. Every isolated spoke makes the app a bit harder to use. Teams need to accept some compromise to make the app work like an app, and share control of how services fit together.

I think there are some things we can do to make it easier that don’t involve performative coordination rituals. We need clarity on what we’re aiming at and shared evidence about what does and doesn’t work.

Frankie has been exploring how we can design from a perspective of coherence across journeys, offering a direction that isn’t tied to how a team fits in the organisation. Our team has the structural benefit of not being on the hook for a single outcome so we can design with broader needs in mind.

I wonder if we could ask teams to regression test the most important journeys in the app when they propose a change. Take journeys that already work, like ordering a prescription or reading a message. Test them before your change and after. You could make your service a huge success by making the link to it red and flashing, and meet all your own measures while making everything else harder. Testing the wider journeys makes that trade‑off visible. Some compromise might be fine, but it should be a choice, not an accident.