Building a Design System
How to build a Design System to educate non-design stakeholder?
Role
I worked on this project while being an Associate UX Designer at Mantu Group, under the supervision of the Principle UX Designer.
Overview
In this case study, I would like to share our team’s experience of building a design system for internal Enterprise Resource Planning system at Mantu.
Mantu is an independent global consulting player with 8500 talented people spreading over 60 countries across 5 continents. As a global group, Mantu has developed its own exclusive internal ERP system serving all departments such as finance, IT, human resources, and others. The system has 140+ applications that have been being built for over 10 years.
Team
Principle UX Designer: Waleed Joholee
Senior UX Designer: Salma Chokri
Tools
Adobe XD
Zeroheight
Storybook
Scope
Styleguide
Design System
Why do we need Design System?
For over 10 years, the ERP system was built by different teams to serve a very specific need at a time without any unified style guides.
Meanwhile, not every team has a dedicated UX Designer, and the UX Department’s capacity at that time was focusing on the prioritized products only. Without designers, other 100+ applications continued to be developed based on the inconsistent and outdated UI. As a result:
- It create inefficiencies for employees when using the system as the applications were not intuitive and hard to use
- Newcomers had a really hard time onboarding and trying to be familiar with the system
- The whole company lacked a shared foundation of design language, guidelines, UI and front-end code libraries
- We are wasting resources as every product teams were developing applications in different ways and the knowledge was not transferable between teams
The goals
Improve usability and user trust
by providing a consistent experience across products and allow employees to complete their goals at ease
Educate and empower non-design stakeholders
to be capable of handling simple UX problems without the help of UX Designers
Improve overall product team efficiency
by having a shared and reusable code library across the company
Some principles that we follow
Principle #1
Atomic Design
Using Atomic Design methodology by Brad Frost as our inspiration, we started to build our Design System from the foundation elements (atoms), including color palettes, typography, grid, spacing, icons, or buttons. Later, we moved on to more complex molecules and organisms that are built by atoms, such as form fields, tables, menus, etc. Combining all of the elements together, we generated the so-called “reusable layouts” that include the commonly used layouts across our ERP system. These reusable layouts act as templates that suggest the design patterns and are open to modify based on specific usage.
Principle #2
Responsive
Since our ERP system prioritizes desktop usage, we put great consideration on the fluid grid. A fluid grid has fluid-width columns, fixed gutters and fixed side margins. The fluid grid has a flexible content width that goes edge to edge as per the screen size. In a fluid grid, columns either grow or shrink to adapt to the available space. We use a fluid grid as it uses 100% of the screen’s width. The large and high-definition fluid grids allow for maximum use of screen real estate, and are best used for application workflows and UI.
We also defined breakpoints ranging from large screen (1920px), medium (1366px), small (1280px) to iPad (smaller than 992px). For each breakpoint, we defined a specified grid system to fit the screen size, mostly by changing the gutter and column-width.
Principle #3
States
For every component, we designed all the states that can happen: hover, focus, disabled, active/inactive, selected/unselected, empty/with data, success/error, etc.
How to educate non-design stakeholders?
One of the main goals when building the design system was to educate stake-holders on basic design knowledge and equip them with a component library so that they will be able to handle simple designs without the help of UX Designers.
The design system was built with great consideration put on the users: product managers and developers, who don’t have any design skills. These content were included with the aim to educate non-design stakeholders:
Content #1
Specs
Each component comes with anatomy & specs where we break down the component and specify its technical specifications, such as width, height, padding, font, etc.
Content #2
Usage
Each component also comes with usage guidelines where we list down when to use the component and how we should/shouldn’t use it.
Content #3
UX Bites
These are short, quick and easy-to-consume UX tips related to a specific topic, for example “How to design an empty state?” or “How to make better forms?”.
Buy-in
The design system means nothing if it is just a project within the UX Department. In order for the project to succeed, it is important to involve stakeholders in the building process. We promoted the initiative by:
- Conducting training workshops for product managers about basic UX knowledge and how to use the component library in Adobe XD
- Manage an internal social media group and a Teams channel where we share new updates of the design system, answer questions and collect feedback from stakeholders
- Involve software engineers into the conversation to collect input and build CSS library
Lesson learnt
Building with non-design stakeholders in mind
Building a design system is just like building a product with the users in mind. A design system is not only built for designers, but also for non-design stakeholders, such as product managers and software engineers. It should be built in a way that is easy and informative enough for non-design people to understand and apply the knowledge.
Build to re-build
It is not realistic to expect to have a fixed, complete set of components that act as a firm guideline and never change. Eventually, a design system is built to serve the brands and products. Once it doesn’t make sense on the products, the design system is open to review, test and modify.
Promoting and adopting Design System
Promoting awareness and adoption of DS among the company is one of the most crucial parts. The design system means nothing if it is just a project within the UX Department and no one in the company knows about it. Eventually, it is built for everyone to use to get a better understanding in UX and ensure consistency across the company.
Design System is a long-term investment
While it is clear that it will require a lot of resources and commitments to get the huge system to change, we understood that this project would bring great impact in raising brand awareness, ensuring consistency and improving the overall company’s efficiency in years to come.