Design system management

Design systems can help set out an organised collection of patterns and practices to help bring about a consistent experience across an organisation as well as effiencies for engineering teams with code re-use. Once you've convinced your organisation of the benefit of this system and encouraged its adoption across multiple teams there are many challenges faced in managing, extending and improving the system over time.

Resourcing

One of the first challenges can be providing resource for the system. Design systems can begin to grow organically through passionate engineers and designers that wanted to ensure re-use of patterns and code across applications. This group can form a 'Core Team' to help guide the development of the system, regularly discussing the vision for a collection of shared libraries, making decisions on what should be added to these libraries and how APIs should be structured.

But this maintenance and planning is a full time job. Managing this process proves too much to be done off the side of their desk. Inconsistencies emerge across component APIs, delays in code reviews with disagreements on implementation approaches taken cause developer frustration.

Forming a platform team to take ownership of developing this system and setting out the process for contributions can help solve this. Having engineers fully focused on the long term health of this system can bring consistency and bring clarity to the process of adding to the design system.

Defining the lifecycle process

Taking inspiration from Atomic Design it helps to set out a clear process for making changes to patterns. Some common questions to consider include:

• When do we add a new component vs extending an existing one? What information do we need?
• How do we define maturity of components and communicate this to consumers? If we add a new component are we happy for it to be widely used in production immediately?
• What is our API design philosophy? Do we lean towards a more flexible or constrained API design?
• How do we manage breaking API changes, including deprecating/removing components? What sort of notice do we give to our consumers? Do we have a major release schedule to allow teams to plan?

Ensuring quality

One of the key promises of a design system to other engineering teams is cutting down the work they have to do: use our pre-built components to avoid having to build them yourself! If your changes are regularly breaking how these components are used within their applications it will very quickly lead to frustration as unexpected debugging work falls to these teams.

Storybook can be used to create a range of "stories" to test our components in all the ways they are used by application teams. Stories represent functional/visual test cases and by ensuring all use cases are covered by a story can help prevent introducing issues for consumers. Combining Storybook with Chromatic can also add visual regression testing and an easy way to involve our designers in the review stage. Storybook's play functions allow you to cover those cases that require user interaction.

Writing unit tests using react-testing-library is a good approach for creating maintainable tests that also encourage writing accessible components.

Dogfooding your design system is also a good method of catching issues before they are picked up downstream by your consumers. Maintaining a range of molecules and organisms within your design system can help discover issues at the atom level earlier.

Get feedback and discover future opportunities

As a design system maintainer a question you might be asked is when will the design system be "done". The truth is your design system will continue to evolve as your organisation builds new applications, new use cases are encountered and new patterns emerge. Re-brands and design team direction changes can also create particular upheaval to your system.

You need to regularly get feedback from your users: engineering teams, designers, product managers and end-users. Your design system is a product and someone will need to fill this Product Owner role to ensure your design system is moving in the right direction and continuing to solve problems for all of your users.