In past few years, the topic of Design system has become widespread… but what is this all about.
I read so many blogs, articles & books around it and found no one is talking about the challenges about it. Most of the people who is publishing this articles or blogs belongs to design community or they are more on design philosophy side. I have not seen or heard any practical challenges when they implement the design system on live projects and how they come out form those challenges.
So let’s start from beginning.
What is Design System ?
I keep hearing various definitions, so let me start by saying what a design system isn’t. It is not a Sketch library or no more than a style guide or a pattern library… Actually it’s combination of all of this and beyond this.
So, Design System is the complete sets of design standards, documentations, and principles along with the toolkit (UI patterns and code components) to achieve those standards.
So what is Style guide or pattern library ?
Style Guide: It typically encompass a company’s brand guidelines, which include logo usage, brand colours. It is often wrapped into a deliverable for a company to work with outside vendors and for future development of brand products. Style guide can directly influence the look and feel of a pattern library. Style guides can stand on their own without data, while pattern libraries rely on some data to function.
Pattern Library: Often encompass with static UI elements, e.g. tabbed navigation, dropdown menu, accordion, and even common web page layout, like grid. Style guides do not always care about context, and relationships with data. Whereas UI elements, and their application in the overall user experience depend heavily on context and the interplay with content.
I hope it will be clear for you now, that the style guide and pattern library are just some of the deliverables of a design system.
A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.
A style guide can provide documentation and serve as a helpful resource, but the simple existence of a style guide doesn’t guarantee long-term success for the underlying design system. A design system needs ongoing maintenance, support, and tender loving care for it to truly thrive.
So in nutshell we can say design system isn’t a project. It’s a product, serving products.
So why do we need this ?
There are two ways of looking at it, from an internal and an external perspective.
Internal: It creates a holistic perspective to ensure we’re all adhering to the same methodologies and patterns as a team. Every team member should be in-line with the concept that we’re promoting and should be able to reference the design principles against any project they are currently working on.
External: Having a cohesive design language creates harmony within a platform. For onlookers, standardised colours, interactions and patters creates a sense of familiarity and security. A well planned and well executed design system is the key to a gratifying experience. Familiarity brings a sense of comfort and security to the user. Introducing design constraints on individual elements within a platform creates consistency at a higher level.
A successful Design System will:
- Focus: allow the designer & developer to focus clearly on the project at hand rather than to be diverted by other distractions.
- Clarity: allows the team to think clearly about design beliefs as well as the design constraints in place across the platform.
- Confidence: allow the team to have complete confidence in what they are developing and that it is in-line with others in the team
- Consistency: create consistency across the product which in turn will create a secure, familiar experience across the platform.
- Efficiency: create understanding across the teams, meaning less time consumed concentrating on the less important details.
What in the box ?
The fundamental purpose of design system is to facilitate the work of the teams. For designers, a design system means a library or brand guidelines. For developers, it’s more likely to mean coding standards and documentation that guide precise work.
So the first question we need to ask ourselves is not “what should I put inside my design system?” but “Who is going to use it and how they will use it?”.
Just think what can happen when we break out those silos of designer and developer. In his definition, brand including design standards, documentation, and principle along with a toolkit of UI pattern and code components to achieve the standards. A detailed design system not only describes the product but the process of how it come to the life as well.
Focus & Value: Before starting anything, it is really required to align right team around with a clear vision.
Design Guidelines & language: Design guidelines are so much more than just the visual aspect of the product. They will help the teams to make meaningful design decision. It should covers the following:
- Illustrations & shapes
- Animation & sound
Pattern Library & Components: Components & Pattern library are the heart of the design system.
Components are like a LEGO blocks, they’re used in sketch by designers, and directly coded by developer.
Patterns are the building instructions that will allow us to use these components in a logical and consistent way, across all the product.
I still remember Alla Kholmatova’s book “Design System” which talks about various type of design system. I’ll take those in my blog too
Strict or Loose
A Strict System: A strict system should be very broad in order to cover the majority of cases the teams may encounter.
A loos System: This will leave more space for experimentation. Designer and developers are free to use it or not, regarding their particular needs for their product.
In my opinion we should have right balance between this two if it’s too loos can we still call it as design system? Other side it should not be too strict which might create a repel developer & designer who will not want to use it.
Modular or Integrated
A Modular System: it suits well for project that have to scale quickly as it’s made of interchangeable and reusable parts. This kind of system will particularly fit large-scale product as e-commerce and finance etc. This kind of systems are quite expensive as its difficult to make modules that can be independent while working well together.
An Integrated System: This will focus more on unique context. Under this components & part are not interchangeable. This kind of system will suit for those products that have very few repeating parts.
Centralized or distributed?
In a centralized model, one team is in charge of the System and makes it evolve. This team is here to facilitate the work of the other teams and has to be very close to them, to be sure that the System covers most of their needs.
In a distributed model, several people of several teams are in charge of the system. The adoption of the system is quicker because everyone feels involve but it also needs team leaders that will keep an overall vision of it.
In each case, I advise allowing everyone to participate and make suggestions to improve the system, in order to create a sense of membership. To keep with industry’s best practices and real-world performance, design systems need to be up to date and in trend. Design system moderators can propose changes by adding, removing, or modifying as needed to serve the purpose.
I hope that this article has given you a solid understanding about what design system is and help you bravely tackle this increasingly diverse digital landscape. I hope you and your team can create great things together. Go forth and be atomic!
- Alla Kholmatova’s book on Design Systems
- Designing Systems | Atomic Design by Brand Frost
- Every article of the fabulous Nathan Curtis