Patterns in Design Systems

A few years ago, while working on the GOV.UK Design System I spent probably a little too much time thinking about the differences between Components and Patterns. I thought about where they crossed over, where they were distinct and how they might be distributed or documented differently.

What started off as an information architecture exercise quickly escalated into a journey of self-discovery…ok, not quite, but it did help me classify type of patterns and create repeatable rules I’m still using in design systems today.

Components

To classify patterns, we first must classify what we mean by components. This isn’t an easy job nowadays. A lot of our tooling has used the term “component” to mean pretty much anything we add a wrapper around and give a name, rather than an active choice to say, this thing, really is something.

When I think about Components in a Design System sense, I think of “things”:

• Un-opinionated objects
• Named as nouns
• Can be used in multiple contexts

On the most part this definition holds. Even when a component is a bit more specific to a context, for example, to capture a specific type of content, it’s designed in a way so it’s the most agnostic version of that thing.

I generally do not consider components like <HomePageSliceBlackFriday> or <MySpecialRadios> to be real components by this definition, just part of a frontend development process no different than defining a class name.

Patterns, there’s more than one type

When looking at how to define patterns I couldn’t find a single set of definitions to neatly organise things into. That’s because it doesn’t exist. I classify patterns into three distinct types. Rather than being un-opinionated objects, they are context or activity specific.

UI Patterns

A UI pattern is one step up from a component. These are the elements that bridge the gap between components and patterns, or what makes them blur together if that’s a better way to look at it.

A UI pattern might be:

• An arrangement of components for a specific purpose
• UI scaffolding
• Layout / Page templates

Depending on the way that your system is built, some of these things could be considered components. Likewise, they could equally be considered more of a prescriptive way of composing components through guidance and examples for a specific scenario.

The main differentiator here is probably the absence of a real component API. If they are considered components in software like Figma it would be purely as a method of delivery. You’d expect and encourage these UI patterns to be detached as soon as they’re imported. In code, you might simply make a copyable example on your documentation site.

Behavioural Patterns

These are the patterns that document a process, concept, or user flow. Even within this sub section there’s a lot of variety.

An example of what I’d call a behavioural pattern would be:

• Authenticate with a magic link
• Check your answers
• Give consent
• Email confirmation loop
• Ask for an address

Despite the output of these behavioural patterns being quite varied, they are focussed on specific activities or user goals. They are all about the context, not an object to apply context to.

The delivery of behavioural patterns could be:

• Guidance and representative illustrations
• An example of a component(s) with context specific content
• Flow diagrams
• Multi-page prototypes

Service patterns

Zooming out even further, I see service patterns as guiding frameworks. A way to document common user tasks or common stages of a journey. This could be designing a map for types of journeys such as “Apply for something” or equally, bigger, more zoomed out versions of some behavioural patterns.

The delivery of service patterns might be:

• A series of service blueprints or maps
• Exemplar service prototype
• Guidance and representative illustrations

From Components, to UI Patterns, to Behavioural Patterns and finally to Service Patterns we get further and further away from a coded deliverable.

We move from something that can be consumed and used directly to something more conceptual. Something that guides us and helps us make decisions, with frankly whatever UI we’re using.

That is until we get to the concept of Feature Modules.

Feature Modules

A feature module is like a massive component, but more in the software sense of “component” rather than a design system one. It’s a highly contextual and specific module that would allow a team to plug in an entire feature into an application.

Rather than copying some of the UI examples and templates and hooking them up to an API, a feature module would ideally just work out of the box. Need an address lookup, import the Address module. Need the user to log in, import the authentication module.

I must first admit I have never seen this concept fully realised. Some of the reasons I’ve seen this idea fail:

• A lot of upfront effort causes development to stall
• Requires DevOps and funding support
• Some modules would require contracts for third party data – not something you want to put on a personal credit card
• Specific to one tech stack, meaning many consumers need to fall back to self-assembly anyway
• Not kept up to date with the Design System
• Designers want to integrate some of these patterns in different ways

While I don’t think Feature Modules would be in the remit of a Design System, as this article is about the delivery of patterns it’s worth mentioning this as a potential future concept. If anyone has done something similar, please let me know!

Wrapping up

You may not need to categorise patterns like this in the real world. When it comes to delivery of patterns, there is just no one size fits all approach. I hope some of these examples give you a good starting point how to document and distribute these different types.