Are design systems too slow?

SPOILER ALERT: We have a problem with our design system. It’s too slow!

The pace of design systems has been written about before by Josh Clark back in 2023. Josh made the case for design systems to be intentionally slower in order to support faster delivery.

When a design system expert is saying that design system teams should embrace going slow, it may seem strange that I’m then writing about our design system being too slow. Should I not just embrace Josh’s expert words?

…a design system is supposed to improve the efficiency (and quality and consistency) of user interfaces by delivering a library of solved problems. And so of course it feels like a fundamental failure if this supposedly efficient system is instead a bottleneck.

Josh Clark — Ship Faster by Building Design Systems Slower

Embrace the work, not the pace

The problem we have is not the pace of the MoJ Design System team. Our design system is slow — NOT the team. This is an important distinction to make.

Our design system is slow because the team’s pace is determined by the work, and the work is large, impactful, and far reaching.

The bulk of our work is to release, maintain, and improve components, and we aim to make components as robust as possible. This is why the work is large, because making a robust component isn’t quick, easy, or simple. Making a robust component includes:

• Thorough discovery to understand a components usage.
• Working far beyond accessibility compliance.
• Designing components to be useful by as many teams as possible.
• Building components to be used at scale.
• Focusing on details that matter at a systems level like consistency of interaction states, strict code standards, and thorough documentation.

The MoJ Design System currently has 20 components sitting in a backlog ready to be worked on and brought into the design system for reuse by product teams. Our current cadence for releasing a robust component is anywhere between 4 to 12 weeks, depending on size and complexity, which means, even if all 20 components were at the simpler end, it would be two years before all those components were present in the design system and available for reuse.

Let’s think about that 20th component on the design system team’s backlog for a moment. If it’s going to be a minimum of 2 years before that component is centralised, that’s 2 years where there’s a chasm of invisibility around the component. Teams that could benefit from using that component won’t be able to for a long time. I think that this ‘chasm of invisibility’ is the problem to solve, not the speed of the design system.

The problem to solve

The chasm of invisibility is the time between a team contributing a component into a design system and that component being made available for other teams to reuse.

What it looks like is:

1. Team A creates a component. Let’s call it ‘Component X’.
2. Team A then has Component X in their product/service.
3. Team A contributes Component X to their organisations design system.
4. Design System Team adds Component X to their backlog.
5. Team B needs a component that does X.
6. Team B asks (on Slack) if anyone has a component that does X.
7. Team A says they have Component X.
8. Team B then has Component X in their product/service.
9. Team C needs a component that does X.
10. Team C asks (on Slack) if anyone has a component that does X.
11. Team A and Team B do not see Team C’s question.
12. Team C creates a component. Let’s call it ‘Component Y’.
13. Team C then has Component Y in their product/service.
14. Team D asks (on Slack) if anyone has a component that does X.
15. Team A says they have Component X. Team C says they have Component Y.
16. Team D uses Component Y.
17. Team D then has Component Y in their product/service.
18. Design System Team works on Component X and makes some changes to ensure robustness and usefulness.
19. Design System Team releases an updated Component X to the design system. Let’s call it ‘Component Z’.
20. Team A, B, C, and D, all need to decide whether to adopt Component Z, and if so, prioritise the work in their team’s backlog.

The chasm of invisibility is the time between points 4 and 19 where a contributed component isn’t centrally available for reuse. This chasm creates product debt across an organisation. Product debt is hard to undo, and the larger the organisation, the larger the debt.

A symptom of the problem

Product debt is the symptom of a design system’s chasm of invisibility. In large organisations, the chasm creates a space that teams will fill. Product teams are resourceful, and they need to be delivering. If they need a component, and it doesn’t exist in their organisations design system, they’ll make it. There’ll be attempts to see if another team has created something already, but this isn’t a reliable process when you have 40–50 teams. When you have Team A and B using Component X, and Team C and D using Component Y, that’s adding to product debt.

Solving the chasm of invisibility

There is a perceived easy and maybe obvious solution.

• Have a bigger team!
• Have multiple teams!!
• Have as many teams as it takes to get those 20 components into the design system as quickly as possible!!!

This isn’t realistic as a long term solution. We have 20 components on our backlog, but we know that there are more out there amongst product teams ready to be potential candidates to go into the design system. We also know that components are only one part of our design systems roadmap, and there are other reusable building blocks like patterns and page templates that will come into the design system. Throwing people and money at the backlog isn’t a solution that solves the problem.

So, what is the solution?

We’re not pretending to have the answer, but we think we have a good idea, so we’re going to work in the open and share what we plan to do as we go.

Our plan

A driving principle of our plan is: If a component is on a live product or service then it’s suitable for reuse.

A caveat: components created by product teams won’t have had the same time spent on it that a component in a design system would have. A product team has a product to design, build, and maintain — they shouldn’t be spending their time on systemising components. That’s the job of a design system team.

The result of less time being spent on a component may mean it doesn’t follow exact code standards of the design system, or it may not have full documentation, or it may not be entirely consistent with other components. But, if it’s in a live product or service then it should still be of a very high standard and it should be more than suitable for reuse.

So, rather than a team contributing a component to the design system, and then the design system team working on it to release it for reuse, we want to develop a service where teams can share a component that they have on their live product/service and it quickly becomes available in MoJ Frontend, the MoJ Figma Kit, and on the MoJ Design System documentation website.

We don’t want a component sitting on a backlog. Instead, we want it to be quickly centralised for reuse.

Improve and maintain

Earlier I wrote “the bulk of the [MoJ Design System team’s] work is to release, maintain, and improve components”. We think this will change after developing a ‘contribution service’ (name very much yet to be decided).

Once a component has been contributed and is released for reuse, the component would be in an early state — let’s call it Alpha. When a component is in this Alpha state it can be reused by product teams, but we’ll need to communicate to them that the component hasn’t been worked on by the MoJ Design System team yet. I think this will be an interesting design challenge that we’ll need to test and iterate on. Teams need to be able to decide whether to use a component or not, and we’ll have a duty to make them aware that an Alpha component may not be as robust a component as one that is in a more developed state.

But, it’s important to reiterate a point I made earlier, which I firmly believe in — “If a component is on a live product or service then it’s suitable for reuse.”

Alpha / Beta

Once a component is released at an Alpha state it will then sit on the design system team’s backlog to be developed further to a Beta state — a more robust and stable component than at Alpha.

The shift we hope to see in the design system team’s work is that they will no longer be releasing new components, but they will work through the backlog to develop components from an Alpha state to a Beta state.

We think a Beta state is where the component has been worked on by the central MoJ Design System team. The team would develop the component by carrying out a thorough discovery to understand how it’s being used, and then design, build and document a robust component. And when ready, release an update which teams can then adopt. This release would then move the component from an Alpha state to a Beta state.

And, whilst the MoJ Design System team is working to release the Beta component, product teams will be able to reuse the Alpha component instead of creating their own, thus minimising product debt and closing the chasm of invisibility.

Following, not innovating

We’re not the first to have looked at this, and we’re taking inspiration from others. Other design systems are doing interesting work in this space already:

• The Intelligence Community Design System (MI6, MI5, GCHQ) have Canary components and Beta components.
• Github’s Design System (Primer) has a component lifecycle and a status page to show where each component is at.

Working in the open

As we work on this contribution service, we’ll update in the open as much as possible. And, if you have experience solving a similar problem or have anything to share, do get in touch. We’re keen to reuse rather than reinvent!