Taming Chaos: Our Design System Governance at Scale
How we defined a model to empower everyone to contribute
Are you struggling through huge Design System backlogs? No time to document anything properly? Keep forgetting decisions about components and guidelines?
Design System development can be chaotic. Having clearly defined governance and contribution systems make it easier to keep track of requests and decisions, and helps drive efficient development.
Since implementing our own governance and contribution last month, we’ve had two huge impacts:
- In the 12 weeks prior to our new setup, we’d had a total of four new contribution requests. On the day of the launch, we had five new requests and by the end of the week it had doubled! As the team now know how to contribute — they are actively doing so.
- There’s been a 93% decrease in the confused questions that the team would ask about how to give bits of unstructured feedback to the system. For me, not having to answer all the messages and calls has been a huge boost to my sanity!
So, how did we manage this?
Utilise EVERYONE
Whether it’s designing and building the assets or writing documentation, there’s a huge workload for Design Systems.
In the beginning we had one or two individual designers and developers building our reusable components. They had complete control over all aspects of the system.
Quite quickly, it wasn’t enough: More and more projects began using the system — each bringing their own demands. As we began focusing on documentation and building a new home for our Design System, organisational chaos began to creep in.
What we realised was that we weren’t utilising all of the assets available to us at all; instead of just having one or two designers work on the system in isolation, we could utilise the entire design team!
Beyond just having a larger Design System workforce — each of the team brought specific expertise, so it made sense to have the designer with the most expertise about an element to build it themselves.
These completely decentralised contributors created more organisational issues. The team was busy on their own projects and it was difficult to have cohesion, as they all had different ideas of how they wanted to make things.
A Council, not a Core Team
With the whole team at our disposal, the original Design System builders thought about forming into a sort of ‘core’ Design Systems team who could manage all of the new development and longer-term vision — but we found that this lead to the rest of the team feeling excluded and unable to put forward their own ideas.
The solution was a Design System Council.
What is a Design System Council?
You might be thinking, isn’t a Council just another name for a core team? No!
The underlying concept behind the Council is that anyone from the design team may be a member and it isn’t a fixed position — contributors may come and go and membership is completely dependant on whether the designer has the time and enthusiasm to work on the system.
We defined these requirements for being in the council:
- Time — Members must be able to commit half to one full day a week working on the system; be available for council meetings and be active in council communications
- Tools — Must have access and be comfortable with: Github, Teams, Adobe XD, the SG Playground, DS Documentation and Invison
- Language — English must be used for all Design System communications (we are a large multinational bank, with lots of languages!)
The Council’s Mission
We also defined the overall mission and purpose of the Council:
- Create and enforce strategy and consistency in the system
- Check that new components / design patterns / styles and their documentation are aligned with the rest of the system
- Write and review documentation to complete the system
- Follow up and assist contribution to the system
To make sure that we could continue to move quickly and development of the system wasn’t slowed down by the new governance, we had one last guideline: A maximum of four designers in the Council at any one time.
Spreading the Council
The creation of the Council was well timed. Another branch of the bank was looking to adopt our system, so we needed to be able to scale and collaborate with them. Right away a designer from their team could join the Council to be involved in the overall development.
(Mostly) Painless Contribution
We still had one area of the system that wasn’t scalable at all: contribution.
From the early days of the design system, contribution moved quickly and wasn’t clearly organised. This lack of organisation was irrelevant to us whilst the system was being created but, as it grew, it quickly became difficult to collect, prioritise and act upon feedback and new ideas.
So we defined a contribution system.
Without giving too much backstory on how we built our contribution system (there is more details on that in part 2 by
), I will say that it was a bit of ‘master planning’, a lot of experimentation and these invaluable resources for inspiration.Create a Single Entry Point
We track our system’s development almost entirely through Github. We’ve found that it’s amazing for recording conversations and decisions using the issue and project board features.
Despite Github being amazing for tracking development, it can be a bit intimidating to begin with.
Initially we had different repositories for everything, from the Asset Library (or ‘UI kit’) to the documentation itself. As a result, it was impossible for our contributors to keep track of anything, let alone remember the correct place to contribute.
We solved this issue with a simple, single entry point for every contributor — one place to make any request that you wanted: Github issue templates.
Organising the Requests
We defined that there were three general categories for requests that anyone could make: Requesting something new, general feedback/suggestions, or reporting a bug.
After a Github issue has been made, this is where the Council members step in with their first duty — reviewing all of the new requests. Each one is discussed and then first marked with one of the pre-defined outcomes (depending on what type of request it is), which informs the next steps that are taken in contribution.
The outcomes range from our favourite, “No work needed” (where an existing solution is identified with the contributor), to launching the main “Something new” workflow.
A Taste of Contribution Workflows
From organising governance, to clarifying a single entry point for requests and categorising those requests into outcomes, you might be wondering what comes next! What are the contribution workflows?
The second part of this article is a deep dive into these contribution workflows, but I couldn’t resist to end on a look at our huge contribution diagram:
Final thoughts
As with all Design System-related articles, this has to end with the reminder that Design Systems are constantly evolving and should be tailored to their surroundings! The Council and contribution system that I’ve described here has been working well for us so far, but if you have any changes or different approaches then we’d love to hear about them! Likewise if we make any changes — we’ll be sure to write about it for you.
This article is part of our Design System series: a 5-year overview, 4 false assumptions, getting buy-in, governance & chaos (part 2), adaptive colour systems and surviving. Watch this space for more!
