Leverton Design System
One of the biggest challenges we often face when building any software is creating consistent experience. We were not different in Leverton. The same things got built over and over again. It was getting harder and harder to maintain things and almost impossible to speed up the process.
Our main goal with this project was to bring the order into the chaos. To do so, we had to rethink the way we were building our product.
How we built our design system
1. Made a list of current UI components
2. Built the color palette
3. Created text styles and chose icon’s library
4. Created components and guidelines
5. Made design system easily accessible
1. List of current UI components
First step was to collect different examples of UI components, colors, text styles and icons that we had in our product. Only when we put all of them together, we realized how inconsistent our user experience was. We had at least 17 different shades of gray, 3 icon’s libraries and there was almost no consistent text style. The situation with UI components was even worse.
There were no standards to follow. Without the guidelines or any principles how to develop or use elements, decisions between teams become arbitrary and difficult to critique. It was becoming very painful to continue developing product on this way.
2. Color palette
From around 40 colors that were used throughout the product, after testing, we succeeded to identify 3 primary, 3 functional and 3 neutral colors. Later we had to add label’s colors and few more shades of neutral colors but from 17 different grey colors, we reduced to 5.
We wrote a clear guidelines how to use colors. For example, what color is used for links, primary text, special buttons, background, border, hover effect etc. We also decided on new naming conventions so for example our #182D5A became @primary-blue. In this way it was easy changing it later across apps if needed.
As one of the apps had mostly reports and graphs, it was important testing colorblind accessibility as some of the graphs would not be readable if we use wrong colors. We used Strark as a colorblind simulator and contrast checker. We also recommended a maximum of six colors per chart.
3. Text styles and icon’s library
Ultimately our goal was to build a scale of typographic elements that will fix the existing and future inconsistencies. When defining a scale it was important to define not only the size of the font, but also weight, line-height and other properties. Same as with colors, we started using naming conventions and wrote guidelines on how and when to use each style.
From several libraries that were in use we had to chose one that will work the best and be consistent between product. In this case, we also wanted to align it with marketing. We decided to go with material design icons library.
4. Component library and guidelines
… most Design Systems are really just Pattern Libraries: a big box of UI Lego pieces that can be assembled in near-infinite ways. All the pieces may be consistent, but that doesn’t mean the assembled results will be. Your product is more than just a pile of reusable UI elements. It has structure and meaning. It’s not a generic web page, it’s the embodiment of a system of concepts. Emmet Connolly
It was not hard to convince everyone that we need design system in place but was very hard to get all designers agree on the UI patterns we wanted to keep. Each team wanted to keep the ones they developed in the past. Initial plan was that we finalize all the patterns in a one or two sprints, but with that approach we would have to stop developing new features for a while. Therefore, we decided that each sprint we will select few components that we will improve and gradually correct all the inconsistencies in the product. Before adding any UI component in the library we had to review and test it.
Even if we use the same components across the teams that does not mean we would combine them in the same way. That is why we had to make sure to document usage and introduce a shared set of principles and rules to follow. We also created templates and examples of how components would work together.
Over the course of 2 months, our designers and developers created and organized style guide and component library that now lives in our Storybook and Zeroheight. We documented the usage and implementation guidelines and also gave examples of how components work together. We finally achieved our dream – a consistency across the product. Not only that we achieve consistency but we were able to reuse components and build faster products at scale.
Copyright © 2019 Miroslava Jovicic