Datavisor Design System

The Problem

Design team is spending a lot of time doing painstaking visual QA.

Pain: Developers hate pixel-twiddling. Product managers hate moving slowly.

The beautiful mocks somehow morphed on their way into production.

Pain: Developers hate to make guesses about fuzzy mocks and specs. Product managers hate shipping broken features that no one feels good about.

The product has 8+ different types of dropdown menus that all behave slightly differently.

Pain: Developers hate reinventing the wheel. Product managers hate inconsistencies. 

06

# of Products

02

Development in 2 Countries

150+

Screens

10

Front End Engineers

Resulting in

  • 8+ Versions of Buttons, dropdowns, etc

  • Inconsistent product experiences

  • A lot of time spent on fixing UI issues

  • Multiple versions of code for the same components 

  • Designers having to spend a lot of time on reviewing and logging design issues

Making a business case for ROI on UX and Design System

As a startup, we were mostly in “move fast and break things,” or “launch it now, fix it later” mode. And our vision and the requirements for the product are always in flux. Coming up with a style guide under such slogans and fluctuating priorities was challenging, but a must if the product’s design is to succeed in the long run. 

 

As a designer, I had always pushed for the need for the design system and making a point how it will be helpful in the long run. Since the priority was to build products/features faster at the beginning, the design system project took a back seat. But as our products evolved, we were actually fixing a lot of UI issues like inconsistencies in interaction and visual look and feel and also since the components were not global, if there was an issue we had to fix it in all the places. It was simply overwhelming and unnecessary work. After getting the buy-in from PM team for the design system project I did a design workshop to highlight the importance of having a design system and below is one of the highlights of that presentation.  

Design Principles

Our design principles affect everything from our visual design to our motion guidelines to our UI content. Whenever we create something, we ask ourselves 3 questions.

Is it simple?

We deliver delight and satisfaction through a clean, focused experience every time.

Is it fast?

We reduce friction and empower people to achieve success.

Is it clever?

We strive to be thoughtful, intelligent, and intentional.

//Inspired from Workday's Canvas design system

Also, Worked closely with your front-end engineering team to be an advocate for creating a library of components. 

Colors

Overview

Datavisor color palette across the platform to ensure consistency, readability, and appropriate branding.

Color Pallete

All of the colors are defined at their base as a Sass variable, such as $dv-color-code

Typography

Overview

Roboto is the standard typeface used on the Datavisor platform, providing consistent look and feel among all applications.

Font families

The font weights Light, Regular and Semi-Bold from the Roboto family are used on the platform. 

aA
aA
aA

Fonts

56px Display 1

34px Display 2

28px Header 1

24px Header 2

20px Header 3

16px Header 4

14px Body

13px Caption

Chart Specifications - Snippet

Chart Hovers

Choosing Charts Guidelines (Snippet)

UI Components - Snippets

Since we were fast paced and had a small engineering team, in the interest of speed and quality, we decided to use angular as the UI framework to take advantage of material design components. We used the base material design components and styled them according to our brand guidelines.

 

Since our applications are data and visualization heavy, one of the issue we faced with material design was that it did not have enough components which were suitable to the needs of our application. One example is the data table, displaying information as a list is a very common scenario in our applications and sometimes the data is so complex and large that it might have close to a 100 columns with the need to filtering, sorting, searching, customizing, etc for every column. As material design did not have such robust data table, we decided to build our own. We took the same approach for several other components where material design was not good enough.

Data table

Buttons

Some of the other components are;

  • Modal Windows

  • Guidelines for icons

  • Select Components

  • Input Components

  • Select Controls

  • Progress indicators

  • Voice and Tone guide

  • Calendar, Score Sliders, Chip Selectors

  • Filter and Search Components

Measurement of Success and Course Correct

Reduced Time Spent In Sketch 

Design system reduced time spent mocking up individual features since there’s a set of patterns built that holds up against tested use cases common throughout your product.

Development Simplified

Since now we had a library of components, all of them configurable and reusable, it drastically reduced the amount of development time required to build new screens. This was measured by the increase in development velocity captured on JIRA.

Build A Consistent Product

Finally, a design system allowed our product to work in a consistent way, improving overall usability.

Conclusions and forward takeaways

From this experience I have learned that a design system is not limited to a pattern library or even a website. It is an inclusive system that brings together all teams and elements of a brand. It needs to be designed for scalability and evolution.

We have implemented DatavisorDesign System 2.0 and its evolving as we solve more complex problems. An extensive Sketch pattern library has been built, and is used for every UX/UI project to keep consistency among the designs. We are working on creating a digital brand guidelines that contains branding information, UX/UI patterns, code snippets, and copy guidelines. This will be shared company wide and with third party agencies.