During the first six months, I focused on making the best use of the allocated time. I asked our designers to block a full day each week, free from any meetings related to other work. We found that Mondays worked best, as they tended to have fewer meetings and wouldn't disrupt their product work flow. This approach also encouraged higher engagement and fostered a social environment around the work, similar to a hackathon. It made the experience more enjoyable and created an element of accountability.

The initial challenges were mostly structural, so I scheduled working meetings where the team could discuss key decisions like the tiered system, the contributions process, and documentation workflows. As time passed and we refined our strategy, roles became more focused on individual interests and skills, allowing us to accomplish more work simultaneously. However, this also required increased evaluation, steering, and oversight, which led to the need for common rules and practices to scope, track, and review each other’s work.

In conversations with managers and our engineering counterparts, we identified the need for a common source of truth about how our team operates and the standards for collaboration and work. This includes aspects such as work estimation and accurate time tracking, as well as unifying our meeting notes and providing a single document that anyone could reference to understand our goals and shared culture.

This playbook included some key pieces of information:

• General information about the group: a charter outlining the team’s purpose, a list of members and their roles, our recurring meetings, and all relevant links to resources like our Figma folder, code repository, and more.

• Project planning practices: our standards for tracking work in Jira, along with a domain classification framework to give structure to our sub-project names and provide a reliable way to understand the work being discussed at any given time.

• Other sources of truth: beyond team rules, we also needed to document solution specifications for stakeholder approval, which we compiled in a document called Brain; and a dedicated space for documenting work intended for our design system site, which we called “Design Systems Index”.

• Meeting notes: all non-project-specific meeting notes, such as standups and stakeholder updates, were documented in this section.

• A shared sources list: a collection of readings that have shaped our understanding of the project over time.

This document became the foundation of our ways of working and was later adopted and developed further by other working groups within the company.

To deepen our knowledge of design systems, we consistently referred to key thought leaders in the field, such as Nathan Curtis and Nate Baldwin from Adobe Spectrum. We also drew lessons from established systems like IBM’s Carbon, the GOV.UK Design System, Adobe Spectrum, GitHub’s Primer, among others.

Based on this understanding, I mapped the project to capture every possible area of work needed to reach a good level of completion for the system. I divided the project into three main sections:

• Framework: this includes all the foundational work where we define our theoretical approach and make decisions on structure, processes, and tools. For example, this covers our approach to Figma libraries and key processes like the Contributions process.

• Toolkit: this section focuses on the main ways our users interact with the system. These are the resources that most designers and engineers will consume, and they represent the practical implementation of the Framework decisions. Examples include our libraries, code repositories, and documentation sites.

• BAU (business as usual): both the Framework and Toolkit categories involve recurring work, from the lifecycle management of different elements, to updates based on new data or insights, or general maintenance. This category groups all of that ongoing work.

Each area of the system is composed of pillars of work, which are the main categories we used to group tasks of a similar nature. These are:

Framework:

• Strategy: the vision and adoption plan.
• System architecture: structural decisions, such as tiers, component levels, library hierarchy, etc.
• Operations: processes like the documentation lifecycle or the contributions process.

Toolkit:

• Foundations: the translation of brand elements into tokens.
• Building blocks: essential elements like components, patterns, and modules that designers and developers use to build UIs.
• Resources: assets like the actual libraries and the documentation websites.

These pillars are made up of our projects, also known in Jira as Objectives, within which we organise all the pieces of work required to complete them, commonly known as Epics.

To further understand the sequencing of work in the project, I mapped all dependencies between different projects, which helped us identify what work was blocked by other tasks.

Finally, to provide a timeline of work to achieve an MVP of the new design system, I led a workshop with all key stakeholders (design management, engineering management, brand designer, and the project leads within the working group) to understand the priorities between different pieces of work. We mapped all projects across two axes:

• Effort: understood as the combination of the time the task would require and the amount of uncertainty linked to it.
• Value: the impact this piece of work would have once completed in helping the teams achieve their goals.