Background
When the company was just founded there were no designers, and developers had to ship MVPs without taking into consideration the UX. As the company started to grow in 2015 they hired their first designer. It was easy to maintain consistency across products for one person and there was no need in building a Design System. By 2019 we had 16 members in the UX team and several local UI-kits designed by team-members to make their work easier and faster.
Problem Space
As the team grew inconsistency across products grew with it. There were different solutions used for the same processes and users had to learn new flows in each product.
For instance, client using both Cloud and Dedicated Servers had to memorize where where all important information is located and how to manage each product.
Comparison of Cloud and Dedicated Servers UI
- Different patterns were used to display servers: cards for dedicated servers, table for cloud servers.
- Statuses of servers are presented differently: toggle switch is used for dedicated servers and simple text for cloud servers.
- Different mechanics of interaction with instances: in dedicated servers the whole card is clickable and opens the server page while in cloud platform the server name itself is a link.
Process
Each designer was responsible for several components and patterns. The process consisted of 5 steps: collecting all the current use cases of the component across 40 products in control panel → analysing UX design best practices → creating a draft of component description → design review → editing description. We agreed on sample structure for component description sample:
• component name
• table of contents
• component description
• component types
• specific information
• rules of use
• sizes
• information sources
• component variants
Let's take a look at an alert description I did as an example:
1. Component name, table of contents and component description.
I created clickable table of contents to make navigating though file easier. When describing component I tried to answer the question ”How to use this component?”.
2. Alert types.
In this chapter I listed component variants and cases of use for each of them.
.svg)
3. Specification.
This block is needed to:
• handoff the design of components to development
• choose the right variant when designing a UI solution
• create responsive design
.svg)
4. Component-specific information: alert text.
For each component this block would be unique. For instance, text on alert is an essential part of the component as it helps user to understand what happened in the UI or what needs to be done.
To make the description more clear we used right and wrong examples.
.svg)
5. Sources.
While searching for best UX practices we followed our usual design process and analysed lot of different sources. We created a whole chapter with sources to have an access to it anytime.
6. Component variants.
This part is the most important one for UX team since all mockups and prototypes are designed using components. We tried to take into account all the use cases so that we won't need to make major improvements of our components in the future.
.svg)
In the first iteration I created more components than shown in the picture. Later Figma launched new features that helped to merge several variants of component into a single one. In the video below you can the final version of component set most layers of which are controlled by boolean properties.
Before/after screenshots
Before creating the Design System, we only had a desktop UI. Afterward, we designed responsive UI for all devices.
.png)
UI prior to the creation of the Design System
Responsive UI following the creation of the Design System
