Design tokens > Governance

Test the governance, approval process, and efficacy by making changes and additions with an understanding to the downstream impact. In other words, make some changes or additions to the design tokens to see how they impact design on a global scale.

Make a way for product teams to engage with the design systems team

Currently there are no formal ways of requesting additions or edits to the design system. The current contribution model allows anyone to add items to gitlab-ui, design.gitlab.com, or the UI kit. Although these go through maintainer review, the maintainers aren't always on the design systems team, and often only have knowledge of their domain. As a result decisions can drift out of sync, and wider context and direction can be lost.

Make the design systems team responsible for design token decisions

The proposal makes Category:Design System the DRI* for design tokens. I think this closer governance will be needed at the start while we figure this out.

*DRI isn't quite the right word, we'd still need an individual person to be the DRI

At the very beginning, I think all tokens would need the approval of @jeldergl @danmh @sdejonge , with a need to expand this responsibility to the rest of the design system team asap.

Create a defined workflow for identifying the need for new design tokens

A clear path to engage with the design systems team to modify tokens will enable greater collaboration, efficiency, and adoption.

This is a large (but in my opinion needed) change to the way the design systems team works today. If we see success here, we could have a similar model for all types of design systems team engagements.

The following is based heavily on the template created by Dan Mall in Design that scales (p.108).

image

ℹ️ Image might be out of date, see the most recent in FigJam →

Q&A

  • Does the same process apply for exploratory work (for example, growth experiments) or MVCs?

    Yes. Exploratory work would either use existing, highlight a broader need that we would support, or create and support their own solution.

  • How is a product team aware of tokens to begin with, or the need to engage Foundations?

    This flow assumes that has already been figured out. It is noted in the 'other stuff is needed' section.

  • At what point could/should a team just use available utility classes from Tailwind (or elsewhere)?

    There is nothing to stop teams using base tokens or utility classes. However, these will not have built in provisions for changing mode. When dark mode is beta, things breaking across modes would block MRs and make designs incomplete.

Outcome

Some other stuff is needed, but is not in this proposal

  • A release process and playbook
  • A token decision making guide
  • A review custom 'tokens' process and playbook
  • Mechanisms for 'how' product teams should have these discussions
  • Additional help for product teams to transition to this way of working
  • Additional help for our team to transition to this way of working
Edited by Jeff Tucker