The case for process-first design systems
Design systems help organisations stay consistent and empower individuals to work collaboratively — but they also help teams deliver better.
At least in theory.
It seems like at the moment, organisations are so keen to have a (buzzword) design system that they build one that dictates how a few team members (often designers) think the organisation should work.
But a design system should reflect how they already work.
Prioritising process
Thinking about our design processes before pulling together patterns and components helps us see where we can streamline and improve how we work as a team. It not only helps to improve design overall but it’ll bring individuals together, create a collaborative environment and increase ownership at every stage.
My experience implementing design systems at Co-op Digital and Mettle (the challenger business bank from RBS), has shaped my view that the most useful and effective design systems are a ‘process-first’ design systems.
This post is about how and where to start if consistency is becoming more important to your organisation.
First, I want to bust a few myths about design systems.
Myth 1: A pattern library is a design system
A style guide or pattern library is just one part of your design system. Focussing on it is reactionary to the inconsistency in your products. It’s more efficient to solve the root cause of the inconsistency first — the process.
Myth 2: Visual consistency is the goal
Complete consistency is difficult and maybe impossible to achieve, especially when your organisation is juggling multiple products under the same brand.
Instead, like eyebrows, your products should be sisters not twins.
Your brand touch-points are the consistent elements to your products while everything else can vary to some degree. That’s ok.
Myth 3: A design system should tell designers how to design
A design system is a collection of guidance, processes and principles. It’s not hard and fast rules.
An effective system is led by emerging products and services, not dictated by them. It should set the tone and structure of how your organisation designs the things it does.
Myth 4: A design system is only for designers
Your design system should be relevant to everyone involved in making the products or services in your organisation, and yes, this includes designers.
The ‘design’ in design system is more about realising a product or service than it is the job your Designers do. For example, an architect designs a building, but they don’t supply the bricks, the regulations, the interiors etc. However, all of those things still contribute to the building design.
![](https://miro.medium.com/v2/resize:fit:1000/1*lOp9iG_bWMX6sRBNuYmCNA.png)
What is a system and how does it apply to design?
A system is either a group of ‘things’ working together as part of a larger network, or an organised set of principles according to which something is ‘done’.
Both are about the interconnecting parts that rely on each other like ingredients for baking a cake.
So in that sense a design system is the principles and materials needed to design a product or service in a way that remains as consistent as necessary –not as consistent as possible.
Most design systems will contain guidance on:
- How to apply your brand; for example what your logo is or your colour palette and how they work within your products
- Principles that your teams keep in mind while contributing to your products
- How you learn from the people using your products
- How you communicate with the people using your products
- Solutions to common design problems
- Assets or components used to solve those problems
- Code used to build the assets
The most comprehensive system might include much more but this depends on the team. It needs to reflect a team’s process.
Where to start your design system
There are hundreds of organisations tackling their own design systems to varying degrees of success and the temptation is to take inspiration from them. However keep in mind that they are solving design problems unique to their organisation, and they may not even be doing that very well.
Start with your users exactly as you would do when designing anything else. Your users are the people in your teams: designers, engineers, writers, managers, customers and stakeholders. By understanding their needs, you can begin to figure out what they need from a design system and how it can best benefit your organisation.
Do internal research
Learn about your team’s end-to-end process of starting a new piece of work: how decisions are made; who makes them, and what they need to make those decisions. Consider the process from inception through to the delivery of the final piece of work and how people work together.
Using this information you can then think about how to streamline and connect each process: where are there commonalities on ways of working? How does work move from one person to another?
The goal is to make each process collaborative and multidisciplinary.
Implementing and delivering a design system
Map your process
Now you’ve understood all the work that goes into making a product you can begin to map that process out. Try to generalise the process and map out each stage, creating opportunity for cross-team collaboration as you go.
Here is an example of a product process I’ve implemented:
It represents the major stages how a problem is solved from research through to implementation. There are multiple stages for review and to document each solution — this is the foundation for your design system.
Create a space for it to live and grow
Create a template for all the information you’re going to gather. This is where consistency does matter. Ideally you want everything you document to follow the same structure, have the same considerations and be consistent at every step. This is where you’re going to start to connect different disciplines and experiment with where your design system might live.
Here’s an example Trello card we used at Co-op Digital for documenting a pattern:
You’ll notice that the problem needs to be articulated before the solution is considered, and even then the solution is dependent on user needs. In this organisation each pattern also has consideration for accessibility and research. Effectively, no guidance can exist without considering how accessible it is.
Populating the design system
Once you’ve established your process, and a space to collect documentation, you can begin to populate it as your products and teams evolve.
Next steps
Filling in the gaps
Perhaps you don’t have design principles and you feel they could benefit your team, or maybe you want to tighten the relationship between design and engineering.
Test and learn
Your design system will never be ‘done’ so re-evaluate where you’ve come from and where you’re going. It’s ok to remove content, it’s ok for something to fail, and it’s ok to start again if you need to.
Bring the wider organisation in
If your organisation is large there may well be a lot of people left out that could contribute. Perhaps there is a marketing team, a communications team, technical stakeholders, these are all valuable design resources.
Create ceremonies
Set aside time to discuss the design system, whether it’s to contribute to it, manage change or check-in with it’s users. I like to arrange a designated session once a week where new and old patterns can be discussed. Create an environment of decision making.
Share what you learn (and what you’re struggling with)
We’re all trying to be better at what we do so share the things you find and learn with the wider community. Lots of people would be interested to know how you get on and offer advice if you need it.
Design systems: what are they good for?
The main benefit of a design system isn’t in documenting your patterns and components but in streamlining your processes as a cohesive team.
By learning from the people that contribute to products at your organisation you can begin to instil a collaborative way of working by default, encourage everyone to be involved in design and free up Designers to solve broader problems with the side effect of helping them be more agile.
Written with lots of help from, and edited by, Amy McNichol