In the last two years, the Design System concept has been an extremely hot topic.
In fact, the term actually started trending in 2016 and interest in it has gained steadily since then, whether within the UX/UI community or more broadly in the digital sphere, as the graph below tends to show.
Figure 1: change in the number of searches for “design system” on Google Trends from November 2012 to December 2019.
The initial idea of the Design System – or the foundation on which this concept is built – was that designers would need to start adopting a strategy for creating guidelines which could be adapted for a number of different products (which many were already doing) and were scalable.
Prior to Design Systems, the standard was the sacrosanct graphic charter; that is, a deliverable that is extremely exhaustive, yet:
- frozen in time;
- requiring a significant time investment to update;
- sometimes suited only to a few specific media types;
- often produced “by” and “for” (graphic) designers.
Even today, it is not uncommon to find IT departments in large manufacturers, or more modest organisations, who – at the start of a digital project – are only too keen to supply a graphic charter for print that needs to be adapted to suit various different devices (computers, smartphones, tablets) and digital technologies (programming languages, CMS, etc.). In many cases, the development teams are the ones required to carry out this task of adapting design rules. And – let’s be honest – there are plenty of other tasks developers are better qualified, and more enthusiastic, to take on. Quite simply, interpreting/adapting design rules is not within their brief.
The Design System has thus appeared as a solution to the problems faced by users of graphic charters with the proliferation of digital media forms (devices) and shorter design cycles – shared between the project’s various stakeholders – which agile methods have introduced.
But what exactly is a Design System?
To give a generic definition, it could be said that a Design System is:
A set of resources used to design all of a company’s digital products or services in a homogeneous way that is accessible by everyone, on a single platform.
The Design System definition has been refined and extended over time to cover fields other than the mere graphical representation of interface elements, colours and logos. It has started to incorporate concepts of interactive design, corporate values and goals and human language, and to represent the functional and technical rules governing the behaviour of the components, or even of the code itself!
Generally speaking, a Design System takes the form of a website via which it is possible to access the various resources.
But before going into detail about content, let’s start with a look a the guiding principles of a Design System.
The basic principles of a good Design System
living
A Design System is a living product that evolves and improves over time. It is a continuous process rather than an end deliverable. This implies that a design system should be considered as a product in itself, and a governance system and roadmap set up to ensure it is maintained and developed in the long term.
agnostic
A Design System must have the ability to be compatible with all technologies, or at least adaptable to all the technologies used within a company. It is possible to create a very generic “source Design System” and multiple “child Design Systems”, each suited to a precise technology (web, iOS, Android).
atomic
A Design System is not seen in terms of pages, but rather as components which can be assembled to create pages.
universal
A Design System needs to make use of a set of standards that mean users are not required to keep adopting new practices to discover the company’s products. It also needs to be able to address issues relating to internationalisation, whether in terms of usage or language.
inclusive
The Design System must be planned for the use of everyone, regardless of usage context, social determinants or users’ digital maturity levels. It needs to incorporate the main rules of usability and accessibility so that it can take users’ potential specific physical, perceptive and cognitive characteristics into account.
What does a Design System contain?
Having established the foundations, let’s take a closer look at the content of a Design System. What are the famous resources that the project’s stakeholders need to be able to access?
Figure 2: Structure of the content of a design system proposed by Audrey HACQ in her excellent article (in French).
identity
The identity section presents all the elements that make the brand recognisable. This section often needs to be created as a collaboration between marketing, UX and DA.
It contains information often found in graphic and ergonomic charters, such as:
- Colours
- Typography
- Visuals
- Logos
- Animations
- Sounds
- Tone of speech
brand or company values
Incorporating the brand’s values can often seem superfluous, but it offers genuine benefits, especially when external companies or service providers are approached to create content. These values act as a compass to guide the design of a homogeneous user experience, regardless of the point of contact between the user and the brand. They make it easy to identify the essential areas to be highlighted, regardless of the product.
These values contain elements such as:
- Ideals
- Founding concept(s)
- State of mind
- Precept(s) to be followed
the components library
One of the first misconceptions to forget when talking about a Design System is the fact that it is not limited to a library of components, but encompasses various types of content. This is a very important distinction to make... but to be fair, components are THE main content of the Design System. They are the main point of contact around which the other types of content will revolve. They will also form the interface between the UX/UI team and the technical teams.
As a general rule, components are created using a central principle which needs to be mastered before creating a Design System: Atomic Design.
So don’t panic: you aren’t being asked to draw upon any skills in nuclear physics! Instead, you just need to rethink the way in which interface elements work together!
Atomic Design is a principle based on breaking down interface elements. It was proposed by Brad Frost as a way of thinking of the design interface not in terms of pages, but as modules, or rather as components that can be assembled. It therefore draws upon the metaphor of atoms that can be combined into molecules (which in turn can become organisms) to describe the way in which the interface elements must be designed.
For this reason, the smallest (indivisible) interface elements are referred to as “atoms” (labels, checkboxes, buttons, icons, etc.). Components consisting of several atoms are known as “molecules” (forms, search bars, etc.). Molecules can be arranged in “organisms” (pop-ups, headers, etc.). Molecules can be used to build “templates” (form pages, article pages, etc.). And lastly, these templates can form part of a “pattern” (signup process, purchase tunnel, etc.), which is most often a use case.
What makes this technique so powerful is that it is possible to create an infinite number of templates and patterns from a very limited number of starting atoms.
Figure 3: Example of molecules and organisms created from the same atoms
Generally speaking, components are created using design software such as Sketch, Adobe XD or Figma, creating “symbols” which are gathered together in a folder acting as a library. So it is important to make the component library folder available in the Design System and to keep it accessible and updated, enabling designers working on the project to use it. The simplest way of doing this is to have a cloud-synchronised file using a tool such as Abstract for Sketch, or natively in the case of Figma.
Another advantage of components is that, depending on the technology used, the code for a component can be incorporated directly into the Design System.
This working method is particularly well suited to projects developed with component-based frameworks such as Angular and React.
Angular or React components are created on using the graphical components and documentation found in the Design System, giving information about their behaviour. They are then made available in the form of a library which can be used with multiple React or Angular projects.
The advantages of having components developed in the design system are numerous:
- Interface elements are identical across all pages of a product, and even across multiple products from the same company. The way they are represented and interact with one another is consistent across all pages. This allows users to learn the internal logic of a product more quickly and be better able to predict the behaviour of the brand’s other products, so they never feel lost. It also avoids being presented with components that look alike but work differently from one page to another, which is often the case when several teams are working on different pages of the same product and have access only to the design of the components.
- If a component’s design is changed in the Design System, all that is required is to update the component’s code in the library. The component is then updated across all pages that use it. In this way, you can minimise regressions within your projects. There is no need to go back to each page that uses the component and modify every instance of it.
- Economies of scale when creating new pages. Once components have been developed, the front-end development time saved when creating a new page is considerable. Developers simply need to choose the right components, wire them up and configure them, in a similar way to a CMS.
- The team in charge of the Design System considers the technical feasibility of the proposed designs, behaviour and interactions at an upstream stage in the process. These points are discussed and, when a decision has to be made, all parties are involved.
Certain tools such as storybook allow components from an Angular/React library to be viewed, and even enable web pages using them to be created. It is therefore possible to create the Design System directly in the storybook, attaching contextual documentation for the components.
best UX practices
Best practices are closely linked to the components. They should be considered as an instruction manual. They offer descriptions of how components should behave and interact with one another, and how to assemble them correctly. These instructions are very important as they allow the creation of similar user experiences on totally different devices created by different teams. In this way, users can adopt consistent habits of use from one product to another without experiencing any differences, starting an interaction using one of the brand’s products (e.g. website) and continuing it on others (e.g. mobile application, interactive terminal).
The following elements are often found:
- Rules for using components and templates
- When and why you should use one component rather than another
- Do’s and Don’ts
- Adapting components to suit specific media/devices/resolutions
How do you set up a Design System?
This is naturally the question that comes to mind once the need for setting up a Design System in your organisation becomes clear.
When getting started, many questions need to be considered:
- Who will use it (devs, designers, etc.)?
- In how many teams?
- Just in-house, or externally?
- What processes and governance systems need to be implemented?
- Who will contribute to it and keep it up to date?
- How much time/effort should be spent on it?
- What types of media will it be used for? Will it be used with different technologies and devices?
- What platform(s) will it be made available on?
Conclusion
Each of these points deserves to be expanded upon. Not all organisations have the same needs, and the most important thing is to identify the processes, structures and media that gain the most support from stakeholders, in order to create a Design System that is used and maintained over time. That’s why it’s important for the Design System to be co-created by the teams who will actually use it, and by strategic management. In any case, this is the conclusion I’ve come to in my work supporting the implementation of the Design Systems that I’ve created for our customers.