Patterns mean a lot of things to a lot of different industries, from fabric patterns in fashion to patterns for sand casting metal components. Even within the digital space, the idea of what patterns are, is equally varied. The word ‘pattern’ can refer to the excellent atomic design approach shown at patternlab.io, Origami (the work at FT.com) or even libraries of interactions. You’ll hear us speak about them a lot as they are fundamental to the work we are doing here on NHS.UK Alpha.

For us, patterns are repeatable solutions to a user need. They can be a way of structuring content or displaying an interaction or implementing a piece of code. They can be small or they can be really big.

They provide two main advantages. They will help build a consistent (but not uniform) NHS and will provide thinking that people can spring-board off to find their own solutions.

For us, patterns should not be confined to just the interface. We’ve found the most effective patterns exist across three main areas:

  • Design patterns: reusable things the user interacts with.
  • Content patterns: repeatable information structures (within a single view or across an entire service) that the user can understand.
  • Build Patterns: Reusable chunks of code that developers can use to build the service.

Organising patterns (pattern taxonomy)

Our pattern design work ranges from simple elements to more complex assemblies. Three levels of patterns have emerged.Generally speaking, as the patterns become more complex, the user need becomes more specific.

Units

The first level is the unit. This is the basic building block. It represents a basic interaction or piece of information that the user can interact with. These are needs such as “I need to be able to understand the content”. User needs, at this level can be quite general but also fundamental to a successful service.

An example of a unit is:

  • a headline of copy
  • a paragraph of text

slide_unit

Figure 1.0 An example of a unit pattern. These building blocks fulfil broad user needs around  basic understanding and comprehension.

Components

A component is a combination of units that represent a more complex interaction. The user needs here are usually more specific, such as  “I need to confirm my appointment time” or  “I need to know which course of action to take”.

  • a button
  • a call-out box
  • a combination of paragraphs and headlines
Animation showing assembly of header and paragraphs into a call out module.

Image 2.0. The callout box pattern fulfils the user need of helping users determine what course of action to take. This pattern works for emergency actions as well as less critical paths to care, such as calling 111 or making a GP appointment. As a content design pattern, this combination of units works well where there’s a need for a user to make a discernible action.

Assemblies

An assembly is a collection of components. Combined, these components fulfil more complex user needs.

 

Image 3.0 This assembly is really effective in fulfilling the user need: people were wanting to know if they should go to A&E or call 111.  It is based on components that fulfil the user need to help them make a decision on what course of action to take next.

This assembly is currently being used across a number of our symptoms pages. It fulfills a user need where people want to understand which course of action they can take with regards to a particular symptom. This entire assembly will form part of a growing pattern library for NHS.UK.

The benefit of a library like this, is that the pattern it contains will be great starting point for anyone who encounters a similar need. In this case of this assembly, the need could be helping a user choose between different treatment or drug options. If, in the future, teams find a user need that understand a piece of content and then choose a number of actions from that (with different levels of urgency), then this is a great place to start.

The environment

Patterns are presented within structures that are fundamental to NHS.UK. These structures not only include elements that affect the display and presentation of components, but also the style, language and tone of voice. These include:

  • The overall grid structure
  • The NHS.UK Digital colour palette and colour language
  • The NHS.UK typeface
  • Iconography
  • Content tone of voice
  • Content reading age

Together, patterns and the environment that presents them are what defines the experience of any digital service on NHS.UK

Benefits we’ve found in doing this.

Patterns provide a way of building a consistent but not uniform NHS.UK. It will be the framework with which will can roll out many services, across many devices.

Patterns make design thinking scalable. Many teams will use existing patterns to help solve their own unique needs. They’ll piggy back on the thinking that’s been done already: design thinking that has been rooted in user needs.

In this way, patterns are collaborative both within and across teams. Across teams, they are a powerful ‘lead by example’ tool to help other people solve similar problems. Within a team working on a specific area, they help unite content, design and development.

Patterns are repeatable and reusable. The inbuilt efficiency that comes from repeatable patterns is the smartest way to tackle something as large as NHS.UK, with millions of words and millions of interactions. We don’t have time or need to design bespoke elements for each interaction, nor want to suffer the ongoing cost of supporting this in the future.

Are you working in this area? We’d love to hear your thoughts on what we’re working on.

One response to “What we think about when we think about patterns”

  1. Comment from Duke Vukadinovic

    Hey Tim,

    I share your opinion that patterns are repeatable solutions to a user need and they shouldn’t be confined to just the interface because the idea of what patterns are, is equally varied even in the digital space.

    Really looking forward to your next post! :)

    Reply

Leave a comment