In mid 2020, we had around 40,000 seller base on our platform.

Today, we have rocketed to 600,000 sellers on the platform — a growth of 15x! 🚀

This breakneck growth comes with challenges — especially for engineers. Let me explain.

Every team has its own set of projects. Keeping our mantra of Speed Over Perfection in mind, invariably, there are changes.

Think of the small changes: padding, font-height changes, or any other small details — anything that deteriorates the user experience had to be mended.

At one point of time, we had huge inconsistencies on our platform. This included differing buttons, colours and shades, and even entire models.

We revisited this — such inconsistencies make it difficult for the end user to relate it all to Meesho as a single platform.

With our rapid growth, these inconsistencies (unfortunately) grew as well.

This called for a standardised model which both designers and developers could use for future projects — adopting a common design pattern was the only solution.

The solution

Following Brad Frost’s Atomic Design, we decided to break the whole page into smaller elements starting with atoms, molecules, and so on. A quick throwback to our Mesh Design framework where we spoke about atomic design system.

Implementation Details

We decided to implement the design system through react Storybook.

What’s Storybook?

Storybook is a tool for UI development.

Why did we use Storybook?

  • It makes development faster and easier by isolating components.
  • This allows you to work on one component at a time. You can develop entire UIs without needing to start up a complex project.

Importance for us:

  • Storybook helps you document components for reuse and automatically visually test your components to prevent bugs.
  • Easy collaboration with developers, designers and product owners.
  • Will give the code for the components there itself.
  • A nice way to collaborate and document.
  • You can navigate between different states of components.

Storybook was an easy choice to make. Now, let’s look at what we needed to make this happen.

Every component needed these files (and for these respective reasons):

  1. Component.tsx - implementation
  2. Component.stories.tsx - Story file
  3. Style file - For styles
  4. Spec file - For test
  • There are two basic levels of organisation in Storybook: the component, and its child stories. Think of each story as a permutation of a component — you can have as many stories per component as you need!
  • The component structure looks like this:
  1. Component
  2. Story
  3. Story
  4. Story
  • To tell Storybook about the component we are documenting, we create a default export that contains:
  1. Component: the component itself,
  2. Title: how to refer to the component in the sidebar of the Storybook app.
  • To define our stories, we export a function for each of our test states to generate a story. The story is a function that returns a rendered element (i.e. a component with a set of props) in a given state---exactly like a Functional Component.
  • As we have multiple permutations of our component, it's convenient to assign it to a Template variable. Introducing this pattern in your stories will reduce the amount of code you need to write and maintain.
  • Arguments or args for short, allow us to live edit our components with the controls addon without restarting Storybook. Once an args value changes so does the component.
  • When creating a story we use a base task arg to build out the shape of the task the component expects. This is typically modelled from what the true data looks like. Again, export-ing this shape will enable us to reuse it in later stories, as we'll see.
  • Actions help you verify interactions when building UI components in isolation. Oftentimes you won't have access to the functions and state you have in the context of the app. Use action() to stub them in.
  • Decorators are a way to provide arbitrary wrappers to stories. In this case we’re using a decorator `key` on the default export to add some `padding` around the rendered component. They can also be used to wrap stories in “providers” –i.e. library components that set React context.
Storybook view of crystal

Development as a standalone package

The initial work was done. However, more was left to do!

We wanted to leverage this design system on other projects as well. So, we decided to develop this as a standalone library, which can be imported in any other project as well.

We are using verdaccio as a proxy registry and hosting it within Meesho internally. We used typescript for type checking given the fact that we wanted this library to be strictly typed.

Additionally, rollup was being used as a module bundler.

How has it made the developer's life easier?

As the whole seller platform is a huge platform in itself involving so many frontend developers. This setup has definitely brought them together to a common shared understanding of components being used.

The collaboration between designers and developers has become a lot easier, thanks to storybook. The testing of individual components can be done alone and not to be waited till the entire feature comes up.

Since the components are already built it has sped up the development process

Future Plans

We realise that we have a long way to go for improving the whole design system. But the few major points we need to work on right away are implementing tree shaking, tokenisation, improving the storybook interface by using relevant add-ons apart from which are being used right now and improving more on the documentation front.

This whole thing would not have been possible without the whole web team collaborating along with the designers. A huge shoutout to everyone involved in the process. With the pace we have developed this we adhere to Meesho mantra of “Speed over perfection”!