Masala Design System

Innovaccer — 2020-22

What's in a name?

This documentation is a work in progress.

TEAM

child_care

child_care

child_care

face_4

face_3

face_2

face

My Role

Lead Designer - Responsible for Strategy & Execution, Research, Interaction Design, UI Design, Usability Testing, Accessibility Adherence, Content Writing, Documentation Framework

Overview

Architecting a design system - the backbone of a wide spectrum of products - meeting the needs of 100s of users, designers & developers.

A few variations of page headers designed by different folks.

Context

Excuse me, why do we need a design system?

For years, the designers and developers at Innovaccer were building the same things again and again from scratch for different projects which resulted in —

sync_problem

InConsistencies

Key reason for low user satisfaction and frustration.

history_off

Lack of Reusability

Wasting time = Wasting money.

accessibility

No Support For Accessibility

Which eventually led to more usability issues and frustration.

A few variations of page headers designed by different folks.

A few variations of page headers designed by different folks.

😤

Small steps…

We did not have a dedicated design system team. Hence, the designers took the initiative to at least have a UI kit at the design side to save time and consequently have consistency.

A small UI Kit in Sketch is how it all started.

A small UI Kit in Sketch is how it all started.

🥺

…for big changes

With the help of the UI kit, designers were able to design sales demo at a fast pace.

WIN

Benefits of a simple UI kitthe org was growing, and realizing the benefits of the UI kit, the leadership agreed for a dedicated design system team.

Foundation

Hold on, take a deep breath first

Before going all in, the team had a few concerns —

data_table

Adopting another system?

Our products rely heavily on tables which no other system had nailed completely. I insisted for having our own system which also meant greater flexibility in general.

line_start_diamond

Start from scratch?

We already had a base on the design side, hence I insisted on continuing from there.

open_with

Restrictive or Flexibile?

We decided to keep it a bit open for more flexibility and came up with our guiding principle of — "Simple should be easy and complex should be possible."

cell_merge

Merge product & brand Design?

Our customers and users are different, hence we opted to not do it.

public

Home for the Guidelines?

I had earlier proposed that we should have our own website. But it meant additional overhead, hence we went ahead with Zeroheight for its simplicity.

Initial foundation

😍

Lead me, guide me, walk beside me

This foundation helped set our very own torchbearer, our guiding principle which helped me in times of ambiguity.

Guiding Principle

Simple should be easy and complex should be possible.

One stone, two birds

My mantra for the design system started taking shape — focus on reusability, consistency will follow.

My mantra

🤞

Users…

…and the consumers

Designers and developers use the Masala Design System to create products for the consumers —physicians, nurses, care managers, coders, data engineers, etc. The feedback from these products than flows back to guide the design system.

A few variations of page headers designed by different folks.

Users & consumers of the Masala Design System

Started from the bottom…

…with the atomic design approach

I. Colors

I first started with generating a brand new color palette from a set of colors that we already had. The idea was to create a consistent and accessible color palette. I used the HSL color model to ensure different shades of the same color could be easily created by just adjusting the Lightness factor while Hue remains the same.


The palette was generated by testing the contrast ratio as per WCAG 2.2 guidelines.

A few variations of page headers designed by different folks.

Creating a consistent & accessible color palette using HSL color model

II. State Logic

Once the colors were finalized, the need of the hour was to create a state logic so that the same state i.e. hover, etc. of different components ideally look and behave the same.


This logic worked for most of the components. Exceptions were made where it did not work.

A few variations of page headers designed by different folks.

State logic so that same shades could be used to represent the same state in different components

III. Grid

Majority of our products are web based and demand responsiveness. We decided to go ahead with the industry standard 12 columns grid. Although instead of a single 16px gutter, we made 8px of gutter on both sides, part of the column itself.

A few variations of page headers designed by different folks.

State logic so that same shades could be used to represent the same state in different components

IV. Accessibility

I wanted to prioritize accessibility from the outset and adhered to the contrast ratio guidelines while creating the color palette as well. While covering the entire spectrum of WCAG 2.2 guidelines was essential, due to time constraints, I focused on just three of them —

1

Text alternative - providing a text alternative for non-text content e.g. for icon buttons.

2

Distinguishable - sufficient contrast ratio.

3

Keyboard accessible - navigating using a keyboard and having clear focus states.

Figuring out what to build first

Auditing the existing products

  • One time process of auditing and evaluating the products our users are building.

  • Basis on the frequency, list the components down in descending order.

  • Sit with the entire team to do the impact effort matrix exercise.

A few variations of page headers designed by different folks.

Prioritization matrix

😍

Interviewing the users

Figuring out the pain points

Interviewing the users was a crucial part in the journey of building the design system. We would interview around 10 users at the end of each quarter to figure out the pain points in using the design system.

If the component is being requested from a user i.e. a designer, then I talk to them about what their expectations are and ask questions like -

  1. Why do they need a new component or pattern?

  2. Can we anticipate it being used somewhere else? Can we validate this by looking at other products?

  3. Should this even be a component or should this be a custom solution for your case? etc.

A few variations of page headers designed by different folks.

Interview session with a user

🧐

How I built things

The process of building a component as simple as a button or as complex as a table starts with the design evaluation of existing products.

Audit i.e. Interface Inventory

  1. Go through our products to find out where it or something like it is being used already.

  2. Take the relevant screenshots and paste them in a Miro board.

  3. Rearrange and segment the screenshots if needed.

  4. Identify the patterns.

A few variations of page headers designed by different folks.

A typical audit board for a component

🤗

Research

  1. Desk research to find out the best practices for the component in consideration.

  2. Research around accessibility covering the WCAG 2.0 guidelines.

  3. Look at other design systems to see if they already have something similar and what are the usage guidelines around it. We typically refer to -

    1. Material Design

    2. Carbon Design System

    3. Lightning Design System

    4. Polaris Design System

Proposal

Create a detailed proposal draft of the desired component which includes (wherever applicable) -

  1. Overview

  2. Structure

  3. Types

  4. Variants

  5. Sizes

  6. Appearances

  7. States

  8. Usage guidelines, which should also include the why behind the design decisions.

A few variations of page headers designed by different folks.

An example of what a proposal could look like

🤩

Accessibility

Because of our end users, the proposal is also required to fulfil some of the accessibility checklist -

  1. Text alternative - providing a text alternative for non-text content e.g. for icon buttons.

  2. Distinguishable - contrast ratio

  3. Keyboard accessible - navigating through a keyboard and having clear focus states.

A few variations of page headers designed by different folks.

Following the WCAG 2.0 guidelines

👀

Validation & Testing

  • This proposal is then reviewed within the team and if needed, with the designers who requested the component at first place.

  • At this moment, the component in Figma is also in a draft state ready to be tested. It is then reviewed by a senior designer i.e. me.

  • If the component or pattern in concern is complex, then we test it with the end users e.g. while coming up with the pattern of applying filters in a table, we did a series of usability testing to validate our design decisions.

  • If everything goes well, this proposal is shared with the design system developers so that they can have an overview of what they would be building in coming sprints. They also share their input and feedback.

Release

The component is then released on design.innovaccer.com and Figma but it takes another sprint or two for it to become available to the developers.

A few variations of page headers designed by different folks.

Releasing a component in a version on design.innovaccer.com

🎉

Challenges

A series of challenges and overcoming them

  • Documentation - In the beginning, design system developers did not know what properties were configurable and what were not for a given component .
    I started adding ‘Configurations’ table in the documentation. Also started having a general document structure across all components.

  • Shared vocabulary - Same entities were being named differently by the designers and the developers causing confusion. Eliminated this situation by having a thorough documentation for the developers.

  • Getting feedback from the users - Started conducting weekly open hours, quarterly surveys and interviews with the users.

  • Version control - Ambiguity in source of truth. Solution? Moving from zeroheight to our own website.

  • Designers feeling restricted - Started making the newer components more flexible so that this situation does not arise again.

A few variations of page headers designed by different folks.

This bottom divider was configurable in design but not in dev

😒

A few variations of page headers designed by different folks.

A uniform documentation structure

😍

Impact

Some of the impacts of having an extensive and mature design system

Reduced Building Time

I ran a controlled experiment where for a simple screen with a table, designers saved approximately 23 minutes with design system usage. Read more about it here.

  • Reduced building time

    • I ran a controlled experiment where for a simple screen with a table, designers saved approximately 23 minutes while using the design system.

    • Took us a few weeks (~6-8) to build the first version of a project which would have taken a few months otherwise.

Finished the first version before estimated deadline.

  • Adoption

    • Our design team is > 30 now and using the design system everyday. These inserts numbers are huge and tell a lot about the adoption.
      (This does not include the analytics from the partner teams, which we can’t track unfortunately).

A few variations of page headers designed by different folks.

Library analytics from Figma

🤩

Takeaways

Documentation is very crucial.

Can’t emphasize this enough.

Communication and transparency is the key.

Talk to your users more often.

Adherence might be difficult.

Until the folks see the advantage of using a design system.

Building a design system is a journey.

It’s not a destination.

CONTENTS

In a hurry? Don't worry

open_in_full

Lead Designer - responsible for building the system from scratch.

Typical process involved - auditing existing products, interviewing users, competitive research, usability testing, etc.

Established the documentation framework.

Peak usage of 332,089 instances in a week in Figma.

For a screen with a table, avg. time saving* of ~23 min.

S

G

X

T

O

J

K

D

E

S

I

G

N

Q

+

B

Z

W

P

A

M

M

A

K

E

R

S

U

Y

O

L

O

H

G

V

Work In Progress. More to come.

Last updated on 16 Mar 2025

© 2016–2025

, Anagh Sharma.

Handcrafted with 🤍.