Design systems are everywhere but yet there is no formal or unifying definition for a design system within the web community. The definition of a design system may vary depending upon its users.
For example, if you hear a designer talk about design systems they are most probably talking about its benefits in terms of design which may include:
- Designing at scale
- Delivering a consistent brand experience
- A collection of tried and tested components
- Making sweeping changes with ease
And if you listen to a developer they are most likely talking about:
- Writing less code
- Centralizing the repository of components
- Reducing maintenance
- Scaling the front-end development
So what is a design system?
Design Systems are curated from scratch to suit the specific needs of an organization or product. Almost every organization has its design system aimed at solving peculiar problems and creating a unique and seamless user experience. So any attempt to create a rigid definition to explain a design system would always fail because just like each design is a unique specification of the product. Similarly, each design system is a unique product of its environment.
The technical side of the design system:
Technically at its core, a design system is a collection of content and context agnostic breathing UI components that can be reused across different products/websites.
Essentially a design system contains 3 parts:
1. Pattern/Component Library
As the web has evolved we have moved past designing for pages to designing recurring solutions that solve the common design problems. A Pattern library is basically a collection of related reusable components that address common user objectives with sequences and flows. You think of a Pattern library in terms of Lego blocks. Just like you can use Lego bricks to build multiple structures/shapes, a pattern library lets you build from existing elements; the elements could be anything from buttons, to menus and grids. A Pattern library may include:
- Pattern names
- Visual representation
- Design elements
- Code samples
- Use cases
- Related elements
2. Style Guide
A Style Guide provides information about how things should be done across the website. It represents the styles, patterns, practices, and principles that are implemented globally in all areas of the company/brand. Before the web, style guides were usually implemented in print. The 1976 NASA graphics standards manual is one of the best representations of a style guide. It defined how NASA's design standards will be implemented on billboards, magazines, and anything.
3. Design Language
A design language is a set of guidelines aimed to create a cohesive experience throughout every leg of a user's journey. A design language governs the brain story and the visual expressions/vision that is manifested in the elements like:
- Colour palette
- Typography
- Spacing
- Grid
- Motion
- Content
- Accessibility
- Icons
Do you need a design system?
A fully functional design system’s sole purpose is to unify user experience through a shared design language. A user should not have to wonder whether different words, situations, or actions mean the same thing.
So, it's not a question of whether you need a design system or not, but whether you should be intentional about one or as an organization should you streamline the process of creating a consistent, accessible, collaborative, and globally unified experience for your brand.
Benefits of a Design System
As the website grows in size and complexity the arguments for a design system are overwhelming. So are the benefits. Which includes:
- Coherence and predictability within the products
- Reducing design and development time
- Designing and developing for every user and every edge case
- Centralising the best development practices
- Assists in building easier, faster, and better pages/websites
- Higher quality by focusing more on the product by iterating and improving rather than reinventing
- Future friendly and a promising solution for cohesive work practices
Conclusion
A design system is an approach to build digital experiences, not a result. It is an approach that produces particular artefacts, but these artefacts vary depending on several factors related to the client/product's needs. Building a design system is like building a house, you can think about the architecture of the house, a vision of what the rooms should look like but you won't be able to pen down every single material inside the house.
Rather than creating rigid definitions which are limited to certain fields that end up explaining design systems as some kind of a tool or a language, we should emphasize the need for design systems as a methodology that helps teams work together in a particular way to produce a particular outcome. For example: Think of the Agile methodology, it doesn't dictate what the result should be, it just helps teams work together in a particular way. Lots of teams use agile, but they produce different things in the end.
There is no one-size-fits-all approach. Design systems are always evolving, always changing.