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.
date_range
2019 - Present
lock_open_right
Open Source
TEAM
child_care
child_care
child_care
face_4
face_3
face_2
face
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.
Problem
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 -
sync_problem
Inconsistencies
Which reduce the quality of the product.
history_off
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.
😤
The Foundation
Excuse me, why do we need a design system?
The answer to this question was fairly easy -
Reusability
(To ‘down’ the amount of time spent
building the same things from scratch)
+
Consistency
(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.
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 -
Why do they need a new component or pattern?
Can we anticipate it being used somewhere else? Can we validate this by looking at other products?
Should this even be a component or should this be a custom solution for your case? etc.
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
Go through our products to find out where it or something like it is being used already.
Take the relevant screenshots and paste them in a Miro board.
Rearrange and segment the screenshots if needed.
Identify the patterns.
A typical audit board for a component
🤗
Research
Desk research to find out the best practices for the component in consideration.
Research around accessibility covering the WCAG 2.0 guidelines.
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 -
Material Design
Carbon Design System
Lightning Design System
Polaris Design System
Proposal
Create a detailed proposal draft of the desired component which includes (wherever applicable) -
Overview
Structure
Types
Variants
Sizes
Appearances
States
Usage guidelines, which should also include the why behind the design decisions.
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 -
Text alternative - providing a text alternative for non-text content e.g. for icon buttons.
Distinguishable - contrast ratio
Keyboard accessible - navigating through a keyboard and having clear focus states.
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.
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.
This bottom divider was configurable in design but not in dev
😒
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).
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 Short
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 205,399 instances in a week in Figma.
For a screen with a table, avg. time saving* of ~23 min.
