A design system consists of tangible outputs like UI components and assets that can be reused in different combinations. But it doesn’t end there. To ensure that it brings all the benefits we set out to achieve, it needs to be maintained and it needs to be adopted by everybody.
The goals of our design system are to:
- Bring consistency between our interfaces
- Improve speed and efficiency of development
Without adoption, we can’t achieve our goals.
Last year I started the role of product manager on a design system. Before that I was a front-end developer and my work focussed on building component libraries for other companies. For each one I built, I was involved in the start of the system’s life and worked with the team I was handing it over to. Now my focus moved from the start of the system’s life to maintaining a design system.
To get started, I spent some time analysing the successes and challenges of our design system. Then I compared it with our products. It became clear that our design system was also a product. A living design system that is consumed by other teams is an internal product.
It belongs to everybody
The design system has users, customers, buyers, stakeholders. It usually has many stakeholders because it unites teams.
- Users = Internal developers
- Customers = Product teams, Product Managers
- Customer’s customers = The product’s customers
- Buyers = The organisation
- Contributors = Internal designers and developers
Our design system “belongs” to everybody, in the sense that everybody has a reason to invest in it, or at least understand it.
- Designers create our design language
- Developers use the system and build the system
- Product managers are customers of the system
- Sales representatives can talk to our clients about the user experience created by the system
- Client services representatives provide support for the interface
- Marketing teams communicate our work in the design industry
- The people and culture team hire talented people who are attracted to working on a design system
- The leadership team are the buyers of the system
Features
It has features. These are components, design assets, design tokens and any tangible outputs which deliver customer value and are consumed by customers. We can get requests for new features and updates.
Features are largely driven by designers. Product designers represent our customers (product teams). As the product manager, I gather requirements for the design system, which means working closely with designers. I also manage the priority of feature development if our central team builds them.
Developers inform our requirements too. They are the users; they consume and experience the product, so we need to know how to make the journey as seamless as possible. How do we release new components and architecture with as little impact and disruption as possible? What tools do developers currently use? Which languages are products written in? Familiarity improves the rate of adoption.
To gather requirements from designers and developers, we hold weekly catch ups to present and discuss work in progress — both in the design system and around the organisation. This gives the design system team visibility on what could be in the pipeline. We also encourage teams to approach us when they need something so we can collaborate as soon as possible.
We can measure adoption of features. I want to know the following:
Instances in products
- How many times is each component is used in products?
- Which component is used the most?
- Which component is used the least?
- How many bugs are raised for each component?
Snowflakes
- How many overrides are placed on each component?
- How many snowflakes (components not in the system) exist in products?
- Why were snowflakes added? Are they still snowflakes or do other teams also use them?
Contributions
- How many code contributions are made to each component?
- Who makes contributions to components?
- How many contributions are made by each team?
Roadmap
Our design system has a roadmap which communicates the outcomes we want to achieve. It’s pretty simple in design as our items are organised in three sections: what we are working on “Now, Next and Future”. Then we have a separate page for documenting ideas and requests for work, which are not in the roadmap but they may be explored at a later date. Given that our users are internal and work so closely with us, it makes sense to give them a space to offer feedback and make suggestions for work.
A roadmap is important to our design system for the following reasons:
- It shows how we will deliver value
- Our priorities are transparent and available for everyone to see — this is important when working with product teams who each have different interests and priorities
- Our team are able to communicate effectively what we are working on to users, customers and others in the organisation — an internal product is consumed by people we talk to every day
Team model
Our design system is managed by the Design Ops team. Design Ops is a buzz word which has been floating around for a short while and it really needs a separate post to cover it. It is a new team for us, which is growing and we are still figuring out our way.
Our Design Ops has a Team Lead, Tech Lead, developers and a Product Manager. It’s organised much like a product team, but we are a team that is shared with others, and we never work in silo.
The core team maintains the system and the codebase, but we also have contributors from product teams. We work closely with these teams to help their designs align to the design system. At the same time they undertake their own research and experiments, so their designs help evolve our system.
I like how Jina describes it in her post about the team model at Salesforce:
The Design System informs our Product Design.
Our Product Design informs the Design System.
It is also how our model works.
We don’t have a dedicated designer in the Design Ops team, but we represent the shared design language defined by the design collective as a whole, which has a leader. For this, collaboration is key. In Design Ops we have many methods of facilitating collaboration, which are usually managed by me:
- An open chat room for real time questions and discussions
- Weekly cross discipline catch ups
- Regular stand ups which are open to all
- Regularly discuss our roadmap in design meetings and developer meetings
- Writing blog posts about our work
- Pull requests are encouraged and welcome
- Talking to each other — we have a friendly, collaborative team
We make sure that all of the developers in the Design Ops team have experience with the product codebases too. With an internal product we have the luxury of seeing how our users work, we can get right into their shoes and learn everything about them. When our developers can go on the same journey as our users, they develop empathy for them and they can make better technical decisions.
Open source codebase
Our design system is an open source codebase. When designers raise needs for new components, it’s usually part of their team’s work, so they can pair with developers on their team to make a code contribution, via pull requests which are reviewed by our core team. We find this to be faster than raising requests for our team’s backlog. When teams manage their own contributions, they can prioritise them.
Priorities in Design Ops are informed by product teams, so as a team we are flexible and adapt our focus where necessary. You can’t get bored in Design Ops — things change all the time!
Marketing to product teams
A big part of my role is getting to know the product teams, their roadmaps, launch dates and priorities. Developers and Product Managers need to know different things about the design system, so I have to communicate the right things to the right people and speak their languages.
Releases
We release frequently, multiple times per week. This is to release components as soon as they are finished so that teams can access them as soon as possible. We don’t like to save up too many changes to release at once. It also accommodates different priorities of teams because they can incrementally update the versions they consume without taking large chunks of time out.
The very beginning
Thinking back to my work on starting design systems, I didn’t realise straight away that I was working on a product. Yet, the questions we ask are similar to those we ask of any product when we start out. We make decisions on things like: design, architecture, tooling, user experience, code, releases, consumption, communication, and more. We should ask the following questions:
- What is the goal of the design system?
- What problems will it solve in the organisation?
- What does success look like and how do we measure it?
- Who are the users and how do they work?
- Who are the customers and what problems are we solving for them?
- Who are the buyers and how do we communicate the benefits to them?
- How many teams will use the system and what are their priorities?
From this we can document requirements and make decisions.
