I put a significant effort into ensuring a seamless transfer of assets, such as fonts, images, and design tokens, between myself and the developers. Although it may seem like mundane tasks, the result of these meticulous efforts can be seen in the flawless execution of pixel-perfect websites. In other words, behind every successful website is a lot of hard work and collaboration between designers and developers.

When I started building the design system at Zoomcar, one key metric we were tracking was the design system's adoption rate. To ease the load on designers and developers, I decided to automate a couple of boring stuff we had to do multiple times.

Here are the few things we created at Zoom that made our lives a little better as designers and why we built these tools.

🔤 Icon Font System

We used font icons for all three platforms, iOS, Android & web, to render all icons as it allowed us to style icons pretty quickly on all the platforms.

Grunt Work

Since we didn't get a premium Icomoon account, we could not use their feature to save font mapping to cloud storage, and the free version allowed font mappings to persist in the local storage of the users. It means

• Only one person can upload Icons to the Iconmoon
• The person in charge can never wipe out the local storage since it will delete all the font mapping in Icomoon.

These problems started to daunt as we scaled to 5 member design teams and did this same process again, and again every time we added new icons, I found it nothing more than stupid.

Solution

When we started to design the tool, we started with few principles.

1. There should be less or no learning curve for adopting the new tooling we introduce to our design process.
2. The tools should be abstracted enough such that anyone can use them without understanding their underlying system.

With these principles in mind, we put together a system that was something like this. When anyone merges a branch to master Abstract triggered an event that I used to run a Netlify build system. The build system did four things.

• It uses abstract API to scan all the Artboards in sketch files and export all icons from sketch to a folder in SVG Format. Since we follow a specific naming pattern for the Icon Artboard, I could export just the icon Artboards from sketch files.
• The system also performed a few string functions to get the naming of icons to match Zeplin. The way Zeplin always remain a single point for truth for the developers.
• With the help library system converted all icons to font files, CSS, and JSON.
• It generated a micro-site display of all the heroes and created a few platform-specific syntaxes, which developers can easily copy and paste.

Outcomes

To share any new icons with developers, designers create a design in sketch and merge it with the master branch. That's it. Everything else is automated by code.

Demo

Future Changes

When the Icon system started to evolve, it started creating problems on the web since font bundle size increased, affecting performance. To solve this, I will be adding a feature that export icons to react components this way developers can import icon on need base.

😌 Eleva

For Zoom, Zeplin is a great platform that acted as a single point of truth for all the developers. When Zeplin introduced style guide features, we added tokens like color, font, spacing to Zeplin. Although at the time, Zeplin didn't have tokens for shadows values

Problem

We had shadow tokens naming dp1,dp2, dp4, etc., in the system we used in our design. Communicating these token values to developers became very painful. We had 8 - 10 front-end developers who wanted to know which shadow token we should use in that particular design they are working on.

Solution

Zeplin had extension APIs, allowing me to show certain things based on a developer's selection.

The logic part was straightforward Zeplin extension API returned with a javascript object with selected layers properties like color, shadow values, fonts… Etc. All I had to do here was to maintain our shadow values and map to design tokens that we had in the system. If the shadow values matched the value in our extension, it displayed the sketch's design token. It looked something liked this.

Outcomes

We deployed the extension Zeplin Extension Library so that all developers can add it to their Zeplin. Once the adoption was 100%, we never had to communicate shadow tokens to designers. It looked something liked this in Zeplin.

I will open-source this project for anyone who wanted to add their shadow tokens to Zeplin.

Future Projects

• Artboard Name Lint: We are using a standard naming for artboard names. Based on the rules we set, we wanted to check with all designers are sticking to the rule help of Sketch Assistant API
• Contrast Checker: Using Sketch Assistant API, we want to warn designers to use colors according to Accessibility Guidelines.

Final Thought

Dedicate some time to zoom out and reflect upon how designers are working. Keep track of the problems. Put forward these problems in the team discussion. Not all issues require coded solutions. Sometimes even an excel sheet will also work. In the end, consider the design team as a product that keeps on evolving.

Resources

• Zeplin Extensions API
• Abstract API
• SVG to Font Convertor

Feel free to reach out to me, @jothachil, on Twitter.