G’day, I’m Tim, a designer on NHS.UK Alpha. I’ve recently joined the team and started looking at our design approach and process. We need to be able to solve increasingly complex design problems quickly and with as little overhead as possible. We can do this using a modular design approach, relying on reusable elements and patterns.

Systems not screens

Our design work aims to generate elements and patterns rather than designing complete screens (static representations of what a service or product may look like). Screens, although really useful, are not the end design goal. They are a design artefact created to test elements in context.

Screens often suffer from being representations of the thing you’re trying to design rather than the thing itself. A design process that focuses on only producing screens tends to avoid thinking about reusable elements. It favours bespoke solutions to problems that each screen is trying to solve.

From the outset, our aim is to create a system where basic elements or blocks can be combined to create more complex patterns and systems. Starting with the most basic elements, our ambition is to create an ever-evolving library of elements that can be shared and used across teams.

Build and iterate

Initially, our aim is to create just enough elements to tackle any new design challenges. We will then develop these elements further as we iterate through build and test loops.

We can also take a systematic approach to measure the effectiveness of any element or pattern we create. We can take one element, designed in one specific context and then see how it works and test it in a variety of other contexts. If testing results in changes to an element, those changes can easily be made across all contexts.

We drew a lot from the thinking of Brad Frost, Dan Mall, and others who work in this area, around how we could layer complexity through the arrangement of elements. Start small with the fundamentals and then build up from there.

Emerging patterns and elements

By looking at systems rather than screens, we are starting to see that in the work we are doing, any design is made up of three interconnected design tasks: content design (what the product says), interface design (how it says it), and context design (where it’s saying it).

Dan Mall recently wrote a great post about content display patterns and development patterns being ‘the design’. This is something that resonated with us here. Most pattern work focuses on the presentation layer – basically how the thing looks. However, we’re finding that patterns can be found in both the content and the build.

With the work we’ve done on diabetes for example, we understand that, by and large, most people’s experience of alpha.nhs.uk to date has been through content.

The content is the actual interface.

So it makes sense to explore any content display patterns so we can start creating efficiencies in the content creation process.

Furthermore, as we start to develop prototyping kits, we’re seeing the need for development patterns that are closely related to their content and display pattern counterparts.

These three layers reflect the interdisciplinary nature of the work we’re doing. As a team, we’re all across the design, from content to display to the front end build. Just as user research is a team sport, so is design.

We started small, looking at the grid and fundamental elements around typography and then started building out from there.


Ways of working

Getting these systems up and working will take a fair chunk of time, discipline and focus. Initially, it’s easy to be overwhelmed by the scope and scale of it all. However, to overcome some of these fears, we’ve come up with a number of approaches:

  • Just enough design – we’re not trying to design the whole thing up front here. We’re only looking at basic elements and then seeing what patterns evolve, whilst always considering user needs, presentation, content and context.
  • Avoid inertia by making mistakes – we know we need to make decisions, but we also need to be prepared to change any decisions we make almost immediately.
  • Focus on the big and the small at the same time – what we must do is look at the really small elements and then traverse out to the larger context. We need to regularly step back from the canvas to understand the bigger picture.
  • Research vigorously – take every opportunity to put things in front of users.
  • Know which problems to park – some problems will take a long time to fix, do just enough to keep moving forward, and work on solving the big problem.

Are you working in this area? We’d love to hear from you: alphafeedback@digital.nhs.uk

Further reading:

I’ve mentioned a few links within the actual post. Here are some others that continue to inform our research:

Pattern Lab

FT – Origamis style guide

Ian Feather – Maintainable style guide

Modular web design


  1. hi there – really interesting read, thank you. I’m wondering if you guys see the off-screen support that your users may need as being ‘all part of the service’, or if what you’re really talking about is designing a website without getting obsessed over screens for screens’ sake?

    I work on Assisted Digital at GDS and am just interested in different approaches!

    • Comment from Tim Allan

      Thanks for the input. With regards to your question, the post focused on how we’re starting to develop underlying elements and patterns and the design thinking behind those. It’s only a narrow slice of the wider design problem.

      However, with regards to your question. When designing a service, we definitely take a wider service design approach to looking at the entire user interaction. This may cross many different touch points, and always involves a much bigger cross discipline team.

  2. Hi there,
    I work at RNIB looking at accessibility so mostly deal with the end user interface of products but was interested in the atomic design idea. I presume this not only ‘chunks’ information into logical units but also helps in terms of the serialisation of data that is needed for screen reader and braille users? By thinking about the logical reading order at each level of granularity you should be able to pre-empt and possibly eradicate any such concerns later on in the design process.
    Also, does this mean that page elements such as images are treated more as objects (in the object oriented programming sense of the word) with meta-data such as alt tags seen as being integral to the element?

    ps. your URL checker doesn’t seem to accept http://www.RNIB.org.uk it may need updating to allow .org.uk domains

    • Comment from Tim Allan

      Hi there,

      ‘Chunking’ definitely helps with what you suggested. Well structured content, should be well structured content regardless of device, whether that be screen reader or mobile display. We’re a cross-disciplinary team, so content design, design and development always work in unison. Accessibility isn’t something we do later in the design process, but something we engage in from the very beginning.

      Thanks for the heads-up on the URL checker too.


Leave a comment