Making design system governance a breeze — not a bottleneck
Letting a design system evolve without blocking the people that use it.
ScottishPower’s design system started like many others, a small team of designers and developers deciding to tackle inconsistency and duplicated work across our products. Our team ended 2020 with the beginnings of our design system — Breeze.
We’d worked hard to align our design and front-end libraries and we were ready to start the rollout. It’s been great to see the impact Breeze has made since then, with all squads and new features created using Breeze. Our next challenge was how to handle requests from the team, such as changes to existing components or adding new ones.
After attending Figma’s Schema Design System conference, it seemed like a dedicated design system squad was the most common approach. However, we’ve been experimenting with allowing the squads making the request to take the responsibility for that work. So far it seems to be working for us, and removes the potential bottleneck of waiting for a separate team to action your request.
Here’s how we’re managing our current design system process, of individual squads taking ownership of their own design system requests.
I’ll caveat this post by saying, we’re a relatively small team based in the same time zone. This might not be the right approach for larger distributed teams.
1. Consult the decision tree
The first step in the design system update request process is consulting the decision tree. We have a decision tree to help determine whether we should use or modify an existing component, or if a new component is required. These discussions should also be happening at design crit and backlog refinement sessions.
2. Raise your ticket on the Breeze Kanban board
In Jira, we have a project set up with an Epic for each component e.g. buttons. Stories are added to these epics when the request is to modify an existing component library. If the component request is for something brand new, then a new Epic is added.
The columns on the board allow tickets to progress through the library update for both design and development:
- To do design
- In design
- Design review
- To do development
- In development
- Review / Design QA
- Done
3. Link the tickets from the Breeze board
Ideally, the squad making the request should be the one that is contributing to the libraries. To do this, we link the tickets that have been raised on the design system board with the related ticket on the squads board and mark them as a blocker.
So for example, a squad wants to allow customers to add optional extra products in a sales process, and they need small buttons to do this. The squad raises a request for the design system to add small buttons. That ticket is then linked to the original story for adding optional extras on their board.
During refinement sessions, it’s important for squads to identify when a change to the libraries will be required, and ensure the tickets are raised and linked correctly. Sometimes they might want to plan that bit of dev work ahead, so that the component is ready for their sprint.
Slack channels
We now have a couple of dedicated Slack channels for Breeze (one for web, one for mobile apps). These are for discussions between designers and developers about components, patterns or just to ask open questions.
Library updates are also shared by developers in these channels outlining what’s new.
Removing the bottleneck, not opening the floodgates
By using Slack discussions, the decisions tree, design crits and backlog refinements, we’re evolving the design system with guidance. We don’t want to end up back in a place where there’s inconsistency and unnecessary components creeping back in.
This collaborative approach allows our squads to contribute and share responsibility for the design system updates. Improving collective understanding and enabling the core design system group of designers and developers to give more consideration to the future of Breeze.
