Masala Design System

What's in a name?

Building the design system at Innovaccer from scratch to speed up the design and development process and consequently ensuring consistency.


2019 - Present


Open Source









My Role

Product Owner

Lead Designer

Content Writer

Before you begin

Building a design system is a journey, it's not a destination. It is not easy to put the countless hours spent over the years in a single case study. What I have tried here is to explain the overall general process that I followed in the journey.


What sparked this project?

For years, the designers and engineers at Innovaccer were building the same things again and again from scratch when moved to a new project.

and these were the outcomes of this practice -



Which reduce the quality of the product.


Lack of reusability

Wasting an important resource - time, in building the same things again and again.

A few variations of page headers designed by different folks.

A few variations of page headers designed by different folks.


The Foundation

Excuse me, why do we need a design system?

The answer to this question was fairly easy -


(To ‘down’ the amount of time spent

building the same things from scratch)



(To ‘up’ the quality of the products)

Initial Explorations

Before going all in

Once it was clear that having a design system will eliminate the problem of inconsistency and wastage of crucial resources in our organization, the team explored a couple of options.

Should we just start using another system e.g. Carbon Design System?

No. I insisted that our products rely heavily on tables (and eventually healthcare specific patterns) which no other system could fulfil entirely. Also, having our own design system meant flexibility.

Should we start from scratch?

No. I proposed that we shouldn’t since we already have many components ready in design which could give us a bit of a head start.

Should we merge product and brand design to create a unified experience?

No. Our customers and users are different, hence we opted to not do it since it would extend the timeline.

How should our users access the guidelines?

No. I had earlier proposed that we should have a website of our own. But this meant managing a lot of work and hence we went ahead with Zeroheight.

Should we make our system restrictive or open?

We decided to keep it a bit open for more flexbility and came up with our guiding principle of - “Simple should be easy and complex should be possible.”

Guiding Principle

"Simple should be easy and complex should be possible."

It was necessary.

Who are we building for

Internal Users

  • Designers

  • Developers

External Users

  • Designers

  • Developers

End Users

  • Physicians

  • Nurses

  • Patients

  • Data Analysts

  • Care Managers

  • Call Centre Executives

  • Leadership

  • Data Engineers

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 their pain points.

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



  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


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



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.


The component is then released on 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



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



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



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.


In Short


  • 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 205,399 instances in a week in Figma.

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




































Work In Progress.

Last updated on 14 Feb 2024

© 2016–2024

, Anagh Sharma.

Handcrafted with 🤍.