We need to talk about design patterns
We’re not doing it very well
A pattern isn’t a pattern until you see a pattern
One of the big problems I’ve observed recently is the creeping of patterns into our language as a substitute for the word “design”.
I’ve come up with a new pattern.
—Anon designer(s)
This is said time and time again in design community discussions. Someone has done something different — presumably because there was a validated need to, rather than a design whim — and they want to share it with the rest of the group. That is great — but. It’s not a pattern. A pattern is only a pattern when you see a pattern.
If you’ve done something different, it’s just a different design. Once broken down, you’ll probably find that the core tenets of the original design pattern are still there. This new design might have variations that need to be considered as part of the components making up the best practice example for that pattern. Or it might actually just be a one-off deviation due to the uniquness of it’s context. Nothing more.
How do components fit in all this?
This one time — at band camp — during a conversation about font-fallbacks, someone said,
Some of our patterns don’t work well with Arial.
— Anon designer
Let’s be clear — good patterns don’t care about typography. But — your components do care.
A component is a specific thing made up of code. It was probably designed first. Components can be made of other components. That’s OK.
Components should be robust. Components should be tested to withstand an onslaught of font-fallbacks. Components should have accessibility built-in. Components should play nicely with other components. Components should — if required — be timeless, while all other components change around them.
Most of the time when we talk about patterns, we’re talking about component-y things. Ideally we should have as few components as possible. The more components we have, the more complex our system becomes, which means more things for users to figure out.
There are a lot of design systems out there that are full of components by default. Some of them might never be used, or used for the wrong purpose. Designers should do the hard work to make design simple, and avoid creating new components unnecessarily.
What is a pattern again?
When we talk about patterns, we should be talking about big thematic solutions to really common problems. They can’t be categorised into something small and specific. For example, content, interaction, etc. At that level, we’re really talking about chunks of something; a component, or a snippet. These are all pretty interchangeable as words.
The confusion comes from the fact that components are repeatable too, but they’re repeatable in a different way. When we look at something like buttons…
Technically a button is an element, but I am of the opinion that we have enough words already, so let’s just call elements components and have done with that.
…a button may have style properties, it may have rules or principals. It may be reused everywhere, but it’s not a pattern.
Good patterns are,
a solution to a recurring design problem, such that you could use the solution many times and never use it in the same way twice.
— Modular Web Design, Nathan Curtis
This is where patterns differ to components. Components have constraints. Sometimes they are completely inflexible. Good patterns have clear problem statements.
One of the best examples of a design pattern, is one thing per page. It’s a way of doing good form design that solves the problems of overloading people’s cognition, helps with error handling, etc. It’s unopinionated. Patterns are component-agnostic.
Naming things is hard — so it’s understandable we don’t always get it right — but we need to try. We need to call each other out, because the more inconsistent we are, the more confusing it is and the more it diminishes our crediblity.
Good design pattern examples
GOV.UK Design Patterns
Projects by IF Data Permissions Catalogue.
