We have been hearing the term ‘design systems’ everywhere, even when it is not even remotely close. This article will take you through what a design system is, the right questions to ask, best practices and some tips on how to release a design system effectively.

What is a design system?

A design system is a single source of truth which groups together all elements that allow teams to design, realise and develop a product.

However, it is good to understand that design systems are not just a haphazard collection of visual components; the identity, principles and best practices of the brand for which the design system is being developed should be integrated. This is because all the products will be built based on this technical and visual living bible, and they need to be an organic part of the brand that they represent – as organic and natural as your hand feels to be part of your arm and the rest of your body. It is good to compare design systems to living organisms, and this article is definitely not the first one to do so. Brad Frost – the author of Atomic Design – is the thought leader in regarding design systems as dynamic creations and, inspired by chemistry, in the book he mentions that “Atomic design is atoms, molecules, organisms, templates, and pages concurrently working together to create effective interface design systems.”

Furthermore, the components need to come together as patterns in different scenarios (or screens) within a product (or more likely several products), so more often than not in the case of design systems there is more than one version of the same puzzle.

While some might think that design systems are property or responsibility of UX and UI designers, the reality is that it is a responsibility shared by multiple teams, including UX and UI designers developers, BAs, QAs, Product Managers and so on. These teams are also the main stakeholders for who the design system is built, as they are the ones who will use it the most and apply changes to it during several product development sprints.

This means that a design system is much more than the components and patterns that are extracted from it: it is a deeply connected collection of functional documentation, design and development effort and technical documentation. All of this to ensure the 3 things a design system should be:

Consistent;

Maintainable;

Scalable.

What are the Right Questions to Ask?

1. What is our current tech stack?

Or in some cases, tech stacks. Although it is far from the best practice, many companies use multiple tech stacks for their products, and knowing which ones you are dealing with is the best place to start understanding the amount of work coming your way and how flexible and adaptive your design system will need to be code-wise. Other questions which fall under this technical category include:

• Which technologies need to be considered and which are should be prioritised?
• How many different products need to be aligned?
• What are the existing tools that we are using relevant to this project?
• What other tools could we introduce to successfully implement this?

These neatly tie in the main stakeholders and you will get an insight of their maturity in terms of this new way of working being proposed and any foreseeable blockers or techniques which can be adopted to make the process easier and more effective.

2. What is our brand purpose?

Integrating the company’s purpose and shared values in the design system and codifying it is key. If the business operates in a certain way, it is important for the design system on which all of the business products will be based to be built mirroring that methodology, in ways which are relevant to design systems of course.

This also leads to the requirement of design principles to be added, to guide the teams and help them reach the purpose of the product and the business goals through design. For example, Medium’s principle is ‘direction over choice’, which via their UI design it translates into a simpler interface. Its strong point? A clear understanding of how to navigate the website and help the users find what they are looking for.

Brand identity and tone of voice are also considered to be an important part of a design system, as the visual component and UX writing involved in building the system needs to be in line with the existing brand guidelines which will determine the level of consistency. Examples include the colours and fonts used, and the kind of copy that will be on the button components and in the fields as placeholder text.

3. What kind of design system will be a good fit for our product needs?

This very much goes hand in hand with the previous two questions, as in order to be able to answer it the teams need to be on the same page from both a technical and brand perspective. A design system can be strict (which means that it needs to be followed to the letter) or loose, which provides more flexibility, and this side of the system is mostly determined by the nature of the products offered by the business and the product roadmaps that are in place.

Another characteristic is modularity. A modular design system can be used across several products with differing functions; multiple solutions utilising the same puzzle pieces. However it can also be integrated, meaning that it is dedicated for a specific product and further developed along a single roadmap. It is important to note that the strongest point of a design system is how it provides a framework of consistency and incredible efficiency when applied across products falling under the same brand, however business requirements should be considered at this point.

A final addition to this question is whether the proposed design system will be centralised or distributed. In this case, this feature is determined by the present workflow in between teams and whether any changes will be introduced. A centralised design system is managed by a single team, with changes mostly being confirmed and applied by the same group of individuals, while a distributed system requires multiple teams to be in charge of its maintenance.

Design Systems Best Practices

1. Set up a meeting with the stakeholders and determine team experience, tech resources and system scope.

As mentioned earlier in this article, the main stakeholders of the design system are the teams that will be using it, including designers, developers, product managers and so on. Understanding the level of maturity of the various individuals in this area, their relevant experiences and skills will come in handy while building the design system. It is practically useless designing something which will not be used, therefore understanding how they think and the work methodology will guide the workflow towards building the design system.

Knowing what tech stack(s) you will be working with and the tools and skills you have available is essential in determining technical feasibility and independence: there should be no re-architecting of the stack to adapt the design system, but only a quick re-factoring or lateral jump, such as switching from Angular to React.

Application pilots are a good foundation to battle-test the design system’s design and code. There is a sweet spot for this in between the Planning and Code sections of the design system roadmap. See if there is a potential for common components and patterns that can be reused elsewhere and use that as your pilot. It has to be something which is accomplishable in a suitable timeframe within the sweet spot, such as a page of the website, or a small section of an app.

2. Find a suitable champion to boost your marketing efforts.

You could design a design system which parallels Material or Apple’s HIG, however if your teams are not excited about it, they will not be of much help in building it, nor will they encourage its use. Finding someone coming with a political and cultural standpoint from within the company to collaborate with you while building the design system will not only test you but also be an evangelist of the design system – and his or her voice will be heard. Adopting the design system approach is not a small challenge, and it is important to note that its success depends on how much the teams and management are ready to be flexible and change their way of developing products.

3. Create a UI code environment.

Create an environment that focuses on the front-end code, such as Pattern Lab, Storybook (for Javascript), or Fractal, all of which help teams visualise and zero-in on components. Screens with different states (such as different member types, logged in and out states and so on) can be designed there too. From this workshop the design system evolves and is fed into the pilot product mentioned in the first point.

4. Unify the development team in spirit – and in code.

Get developers, software architects, project managers and all the relevant individuals to discuss how the design system is going to be coded, and how the architecture will be organised. Codify the best practices of the organisation in the design system.

Ask the team to build a component using CodePen to see the actual workflow of the developers and make sure they are aligned; clean, organised code is objective code, which means that anyone else can continue working on it. This is essential to ensure the design system’s portability across different code stacks (trusty old style sheets might just do the trick!). Tools such as CSS Lint and Prettier can help in keeping the coding method aligned. Brad Frost has an article about CSS architecture for design systems in terms of building for websites, and also a Front-end Developers Questionnaire which summarises the current methodology and details of your coding team.

It is also important to come up with a naming system which is consistent across the design system to develop a common language. When this tactic is not implemented, it is very easy to not realise you are disagreeing on the something only because you are caught up in pesky terminology which was not pre-determined.

5. Use what you already have

You can build a system through the lens of an existing product, where you would have the design system feeding into the product and vice-versa, ensuring interconnectedness. Taking this approach saves time as you do not have to start understanding the product from scratch. Tools such as superposition.design can help you extract styles such as fonts, colours and so on, providing you with the basic framework for your design system.

6. Never forget UX and Accessibility.

Embedding best UX and accessibility practices in each component – like a sort of package – will ensure that the patterns born from that design system are automatically following the universal WCAG3 guidelines for great user experiences across multiple audiences. From the technical point of view, this can also be implemented as a range of validations which do not let invalid Javascript values pass through. It is like a safe net to ensure that development of components does not deviate from the high standards that have been pre-set. This is great help for developers, especially for screen readers and aria-describedby fields. PropTypes is a tool which can help you out with this.

7. Design tokens are your friends.

Design tokens are the visual design atoms of the design system – they are named entities that store visual design attributes to be used in place of hard-coded values (such as HEX values for colours, or px value for spacing) to maintain a scalable and consistent design system for UI development. Use design tokens to feed common design properties into different platforms, and to also bridge the gap between web and native environments. A couple of tools which can help with this are designtokens.dev and diez.org.

Releasing and Maintaining a Design System

A design system is deployed into actual applications, however it is always an ongoing project. This is why we have been referring to it as a dynamic, living organism. Maintenance is crucial as many products are based on this same system, and in order for development to keep up with the required updates, semantic versioning is the ideal method. It determines the cadence, versioning, breaking changes and dependencies of the design system updates.

Semantic versioning naming consists of three digits separated by a dot, and each digit’s position refers to the level of change that the release has brought about. Look at the below semantic versioning example:

1.3.6

• The 1 stands for major incompatible API changes (something will definitely break).
• The 3 stands for minor backward-compatible features.
• The 6 stands for patches, which are backwards-compatible bug fixes.

This versioning style gives a clear idea of the kind of updates that have been applied, and the kind of development efforts that are required to get the products up to date.

Conclusion

As we have seen throughout this article, building a design system is no easy feat, and it needs the input of multiple teams in order to be effectively implemented. Although it is mostly discussed in the UX and UI design circles, developers, product managers and the like have an integral role in its success. Always remember: whatever you are designing or building, needs to fulfil the needs of those who will use it, the way they understand it.