This got me reflecting on various similar conversations that we at Clearleft have had with clients and the wider community, and that as an industry we use lots of different labels - design system, pattern library, style guide et al - but often there are different understandings and interpretations of these things.
So, what follows is an attempt to add a little clarity to some of this confusion - a glossary of sorts -
Systematised design
When we talk about design systems, pattern libraries, component libraries et al, it’s important to remember that they are all products of and methods of, communicating and delivering systematised design:
Systematised design - design that has been put into a system and arranged according to a plan.
There are 2 primary reasons for designing in a systematised way:
- To save you time e.g. re-using a component or thing
- To make things more consistent e.g. design, content, code
There are plenty of examples of systematised design working well, but no matter how shiny and aspirational the end result, all of these examples are based on the principal of modular, reusable and scalable design - it’s at the core of all systematised design.
Fundamentals
These are the guiding principles for design, content and technology - they define and have the greatest overall impact on the system as a whole. If you were constructing a building, fundamentals would be the base materials and approach that you take - will you use wood, bricks, concrete? What typeface, colours and tone of voice will you use for your product? What's the purpose of the building - what will go in it? What’s the primary purpose of your product? These are things you want to get aligned as early on as possible.
Stuff in the middle
When you start to combine and extend fundamentals, you get elements & components. I won’t go into too much detail here as there are different ways to approach and break these things down - Brad Frost’s Atomic Design is a good place to start - so for now, let’s call this ‘stuff in the middle’ - the sum of combining various fundamentals in certain ways.
The stuff in the middle is essentially the small parts of a system - these can be assembled and reused anywhere in a system, but they exist independently, of each other and don’t really function until assembled into larger groups. These are the buttons, search forms, headers of your product - the windows, doors, rendered walls of your building. In isolation, these small parts don’t do much, but together they start to have function and meaning.
Pattern library (a.k.a component library)
Granted this seems like a big step from ‘stuff in middle’, but a pattern library is really just a catalogue of components and elements - the warehouse of prefabricated building parts. You can visit, collect the items you need and then combine them into something with a specific function. In the digital world, a pattern library exists in code, in a single location, and is accessible by everyone who needs access to it on a shareable url.
Pattern libraries are living things - they need to expand and grow, adapt and iterate alongside your business, team and user needs. For some organisations, a pattern library is enough - they can contain all the components needed to build a product, without having any more function than simply providing a place in which to organise those components.
But a pattern library crucially does not contain the information on how to combine components - it’s not a blueprint.
Templates and pages
In order to see the structure and context of how individual components and patterns combine into larger groups, a reference is needed. Enter templates and pages - the individual room blueprints of systematised design.
Essentially a template is an organised container - an arrangement of empty-state components - whereas a page is really a template populated with actual content. Templates and pages are visual and often coded, and they provide relevant examples of the things you are trying to build. Whilst you don’t need templates and pages to have a functioning pattern library, without some kind of reference like this how do you know how everything fits together?
Guidelines
Styleguides, technical documentation, content guidelines, implementation guidelines - these are the detailed architectural notes of the system. Guidelines use written language and diagrams to define and communicate the purpose of a system.
Amy Hupe, Content Strategist at GDS says that...
Written documentation guides us in a way examples & code can’t… When we don’t document and provide instructions on how to use and combine components, we’re building failure into our design systems.
This is precisely where guidelines and documentation comes in - these can be used to describe any part or focus of a system, anything to help communicate shared understanding and consistency.
So, what happens when you start to combine a coded library of patterns, usage examples and detailed documentation?
Design system
The single source of truth, the holy grail (or not) - this is the entire architectural project. A design system packages up all the previous items and provides a location for anyone involved in a project to go and extract the information or parts that they need, enabling teams to design, realise and develop a product.
Crucially, a design system incorporates the shared language and vocabulary needed for everyone to have context of, and work with, its contents. This is the structure for all of your design, helping to make sense of seemingly nebulous parts.
Design systems are also living things - they need to grow, be refined alongside, and in response to business, user and team needs. In order that this can happen, they need experienced and enthusiastic people to maintain and govern them and to help train others in how to use them. Architects don’t just drop all the plans on the build team, cross their fingers and hope for the best - they work closely with them, shaping, refining, overcoming issues and iterating as the building takes shape.
The onion
It’s important to remember that all of the aforementioned are not part of a linear process, and whilst some have dependencies on others, they often don’t happen in ‘order’.
This diagram doesn’t represent size or dependancy, more layers of an onion - peel each layer away and you’ll find related layers, but these are no more or less important than each other - they are all part of the whole.
So, a quick reminder of the glossary (from the middle of the onion):
Fundamentals - the core of any system, the base materials and approach you take eg typography, tone of voice, bricks, wood
Stuff in the middle - the combined fundamentals, the elements and components of the system eg buttons, search forms, windows & doors
Pattern library - an organised catalogue of components and elements, a warehouse of prefabricated building parts
Templates and pages - the reference of how the ‘stuff in the middle’ fits together, the room blue prints
Guidelines - the documentation of how to use a system, the detailed architectural notes
Design system - The package of all of the above - the entire architectural project
Lastly, it’s not about the label
Whilst a good understanding of these labels and definitions can go a long way, it’s ultimately not these that will be the success of any given system or project. Back to the 2 primary reasons for designing in a systematised way - to save you time, and to make things more consistent - both of these reasons rely on a shared understanding and communication, and are label agnostic. It’s about what you can gain by having the most appropriate thing for you, it’s not about what the thing is called.
So, when you’re about to tackle your next project (or are even in the process of assessing your current one), consider this -
Just build the thing that best serves you and your team, and make sure that everyone involved knows what that thing is, understands the context, and how to use it.
Hopefully this little glossary will have ironed any confusion you might have had, but if you'd like to chat about any of this, or about how it might be of help to you or your team, please drop me a line - ben.white@clearleft.com.
