What it takes to keep the largest Conversational AI platform running?
Published: 2021-10-11 06:59:45

## Introduction

I would love to share some of our real-world learnings gained over years of experiment in a high-growth environment, none other than [Jio Haptik](https://www.haptik.ai/).

## 500K+ LOC.

> We are still very young and constantly evolving to the demand of Conversational space

At Jio Haptik, we currently have four internal tools to monitor and build bots. They are namely,

* **Smart Agent Chat**
* **Intelligent Analytics**
* **Conversation Studio**
* **and Admin Tools**

The above tools internally use our Component Libraries. Namely, _Relements_ (a custom open-source lib) and _Haptik/Helpers_ (Also a component library, but very specific to Jio Haptik).

With this humongous code base, _we are clocking somewhere near **250+ components**_.

On top of that, we are still very young and constantly evolving to the demand of Conversational space. Which means we spend a lot of time designing and developing new features.

That brings us to a new challenge. How do we maintain a consistent look-n-feel and behavior across our toolkit? Let's talk about it in detail.

## Challenges

> Then the most underrated part of a product life-cycle is design hand-off to developers.

Since we've started building our application, there have been multiple pivots(recently, we moved from B2C to B2B). So, naturally, we receive new product requirements, which have to be shipped. Concurrently, we keep modifying our existing application as and when we receive the client's feedback. Otherwise, based on data.

While _7+_ pods working rigorously to ship products, we run into several of these challenges.

More often than not, new designs or implementation deviates from our original theme. It's not due to communication or lack of understanding, but an urge to experiment and bring in new creatives.

Even though our internal component libraries powering tools, the designer often needs a newer toolkit to realize their creativity. **They need freedom and flexibility.**

Then the most underrated part of a product life-cycle is design hand-off to developers. How do we make sure we don't miss out on edge cases? And reduce back-n-forth; optimize development speed?

And above all, how do we keep our UI consistent without oppressing the designer's freedom or compromising the speed of development.

With years of hit-n-trial, we found the best way to sustain such high-speed growth is to **stay lean on infrastructure.**

## The lean design system approach

A year and a half back, we invested heavily in creating our design system.

Firstly, we simplified the contract or a common language between designer and developer using tokens. Tokens represent an atomic value of the design spec. For example, a dark blue color, a thick border, a 3px corner radius, or a specific type of drop shadow can be considered a token. 

In the beginning, we only **focused on assorting colors, typography, and space tokens**. We use comparable nomenclature in design as well as in development. To make sure the team is abiding by these rules, we even make use of _design-linters!_

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b3ofm57v424is9aovr89.png)

To make things easier, we have created three layers of the component hierarchy -

1. **Base Components**, like `<Box/>`, `<Text/>`, etc
2. **Primary Components** like `<Buttons/>`, `<Inputs/>`, `<Tables/>`, etc
3. **Tertiary Components** or custom components that use a combination of the above

With these many components, we make sure we have **minimal surface APIs**. That implies we use similar prop names across Components.

```
<Tooltip value={TOOLTIP.USERNAME} variant="alert"/>
// or
<Accordion.Item value={Details} variant="active"/>
```

#### Let's talk about flexibility

Our token-based themes are all extensible. In the case of Components, whenever we see a change requirement -

* for more than _40%_ of its look or behavior, we create a new Component
* if it's less than that, then we mostly add a new **variant** for the existing ones.

> ## 📚 Quick link
>
> I've tried to put together the **technical knowledge** into a
carefully curated course, which you can learn in **[Udemy](https://www.udemy.com/course/design-system-from-scratch/?referralCode=A565E637F26610179C2A)**.

# Caveats for future

* Right now, we bake in the behavior and animations inside our components. Generalizing those will add an extra layer of flexibility which we want to explore soon.

* Finding a sweet point between design flexibility and speed is still a blind spot for us. _The purpose of having a design system in the first place is to put certain boundaries_. But in an ever-evolving environment, we cannot keep these boundaries strict. For now, being lean helps us. Let see if we find any other framework of thought that will help us achieve the same.