OD Design System


I am currently working as a UX Designer for a product company called OneDirect in India. Onedirect designs and builds technology that help improve the customer experience (CX) of the brands. Our goal is to help brands to create delightful customer experience across all the digital touchpoints.

Instead of telling about how we built design system, I will tell how got to the point where we needed design systems.


I joined the office during mid-2017. At that time, we had 3 product vertical which was on the same design language. I was assigned to work on one of this vertical. I got the sketch file from my fellow designer. It looked something liked this:

It was tough to find the artboard you're looking from this mess. There was not even a single instance of symbols in this document. One global level component change requires me to make a change in every single artboard.

I immediately went to my manager and asked time to refactor the design file and componentize using sketch symbols. I got an immediate NO from my manager. He was not able to visualize the benefits it can bring to the table at that time.

Not to be demotivated I went back to my desk and still went ahead with refactoring my sketch documents in my free time.


Pioneered by Brad Frost, the Atomic Design methodology is a hierarchical way of organizing design patterns. On the base level (Atoms), there are simple design patterns, like a button, a text box, or a label. An email submission form which combines the button, text box, and label into a more complex pattern is at the next level in the hierarchy (Molecules). Each ascending level in the hierarchy builds upon the simpler patterns found in the levels below.

The benefits of this methodology are twofold. First, when documenting a design pattern like an email submission form, the designer doesn’t have to rewrite how buttons or text boxes work. Second, the email submission form provides a real life case study of how to use the button, text box, and label effectively. Atomic Design makes it easier to learn how patterns in a design system work while also making it easier to create content for the design system.

After a month I was able to refactor 80% of the file. As a result, I had this large sketch symbols page. It can be easily inserted anywhere in the document. When I converted most of the components to symbols, I was able to iterate and create UI very rapidly.

My manager started noticing this but still not convinced by this idea. There were a few things I needed to bring culture to think regarding the components of the company.

  • My Co-working designers needed to learn regarding components
  • Need a way to prove the business value I can bring If I spent time on creating for past and future projects.

The first part I was able to get it done with a few sessions with my fellow designers.
Second Part I got lucky around the time we were working with SDK partnerships with banks. It consisted of changing our UI style guide to banks UI guidelines(Color, Font, Branding,). This task without symbols was taking around one day for one designed. When I pitched in idea symbols, I was able to do the same job in 30mins. Management was happy, and we ended up doing around 30-40 bank UI designs.


Why a Style Guide?

During this period the design system was something far from our thoughts since it required too much effort and nobody could visualize any business benefits of doing it. Following were the reason to go ahead and create a design.

01 No central place for truth.

There was no place for both the designer and product manager to see what is the correct design. Also in development, I started noticing lots of inconsistency across the different product, border color was not the same, shades of grey were different etc.

02 Introduction of Sketch Library

Sketch introducing library was a big thing for us. It helped multiple designers to share a single sketch file which we can maintain separately.

03 Onboarding New Designer

Since we were hiring fors designers on the team. Each designer took a very long time get adjusted with UI patterns followed in the product.

04 Faster Iterations

With Runner + Sketch creating UI became so fast. Once UX part is done the amount of time to produce UI was cut short significantly, since the designer can just drag & drop components using runner plugin in the sketch.

01 Identifying all the components and its states.

Two of designer our designer worked on this including me. We created the Airtable sheet to map out all the components in the product. We started with most used component first this way we can carry on with rest of the process on other elements later.

02 Finding the inconsistency and UX Problems across the product.

All elements we discovered at the first phase was compared across all the product, and we created the sheet with the screenshots of the different version of the same components. Also noted the problem with existing UX.

03 Finding solutions to inconsistency & UX Problems.

This process is where we took a long time since we needed to rethink a few functionalities across all the product. For example filters, we had different filters designs across the products

04 Creating Sketch UI Library
Communicate updates

To make sure any change in style guide is known to the rest of the team I uploaded all the style guide to Zeplin. This way any updates to style guide I update in Zeplin which is connected to a slack channel this way all the people channel get notified of the changes.

Zeplin also helped developers to act as spec document for all the components we used.


Why a Design System?

As applications and their team's aged, they build debt. The debt is acquiring by building for the short-term. Design debt is made up of an excess of non-reusable and inconsistent styles and conventions, and the interest is the impossible task of maintaining them. Over time, the accumulation of this debt becomes a great weight that slows growth. Following where few significant problems we faced:

01 Code Quality

Since we had 4 UI Engineering team working on four different product, there was no unique place where all the team could refer to the code guidelines for particular components. It leads to inconsistent UI across different product verticals, also duplicating code for the same component among different groups.

02 UI Reviews

Designers started spending 1-2 days on reviewing design made by UI developer to ensure it done according to the style guide. Since this process happens for every release, it started becoming the unproductive use of designers time.

03 Scaling

Since we had plans for two more product verticals, it started to become very prominent problems to manage consistency across all the verticals. So much time is wasted on building the same component again.

Selling to Stakeholders

Once I knew we couldn't scale of design with existing workflow, I decided to propose the design system as a solution.

I was confident of two things one we can't allocate a dedicated team for creating a design system since we can't stop building feature for the brands. Second, developing and maintaining a design system requires a team effort from designers and developers.

I talked with the tech team they were happy about the idea as they were also getting frustrated with code quality in UI. To obtain approval from management, I devised a plan where I created a long list of all the components and its states in the product. Prioritised the list based on the elements which are being used by 80% of the time. I pitched to the management we would take up design system task parallel with the existing project they are doing.

We got the green flag for 16 man hrs/week for a month.


We already had done most of the groundwork like setting design as component wise and creating design style guide. We only needed to take care of creating components in code and its documentation.

Since the existing front end was made on top of PrimeNG angular framework, we didn't need to start from scratch. We needed to modify to match our style guide and add a few extra functionalities.

One month down the line we are able built 10 component including its a crude version of the documentation.


  • All the 10 components is used across our 4 product vertical from a single source
  • Faster Iterations. As the startup, we do experiment a lot few things we have to put out there in the world and see how it works. If we didn't get the expected outcomes, we would change it.
  • Both developer and designer started thinking in terms of resuable components. Both the developer and designer started thinking in terms of reusable components. It increased both code and design quality.