Head of design for Paytm Insider   •   2018—2020

A design system that evolves like a language

Paytm Insider is a event ticketing platform. It sells tickets for music, comedy, sports, movies and sells experiences through workshops, travel and more. It is also a digital events platform allowing event partners to run ticketed events online through streaming interactive video.

My role
  • Create the design system
  • Oversee adoption
  • Improve design consistency
Results
  • Increased work output
  • Improved morale
  • Engagement with other teams

The challenge

Design for daily use

Paytm Insider is rapidly scaling and evolving as a business, from its history in live event ticketing, to movies, sports and interactive video and games.

For marketing, we wanted the large amount of daily work producing banners and emailers to be simplified, with improved consistency—empower all levels of designers to produce work that fits the brand well and is ready for release with minimal oversight.

For product, we wanted to reduce decision making around font sizing, margins, etc. to improve consistency across apps and create a shared language between design and development. Give both team building blocks for prototyping new features or updating older parts of the app.

The team

We formed a design system team involving two marketing designers, two product designers, and an external branding agency. We worked closely with our development teams on iOS, Andriod and Web.

Fast learns, slow remembers

Pace layers divide types of design work by their resistance to change

From the beginning, we wanted to make sure the system was ready for change. Big decisions like brand colours and fonts might remain more fixed, while fast moving components like ads and new features would need to be nimble enough to experiement and set new standards.

Borrowing from architect Frank Duffy’s ideas about the layers of a building, we divided design work into the pace at which they were likely to change. Deeper layers change slowly and need more consideration while higher levels change with the season and can be trendy.

Moving the centre needs more effort and involves more stakeholders since it forces everything around it to change as well

Core branding

Design can be broken into grammar (colours, fonts) and vocabulary (components, modules)

Rather than start with a set of use cases, we wanted to give ourselves rules to work with. The core layer then is a system, or grammar, not a library. It is a set of rules that can be used to handle any new case thrown at it.

We worked with our branding agency to develop the basic building blocks: a colour palette, fonts and patterns that can be combined in a variety of ways.

3 simple rules

Giving elements meaning

Two
Start with 16pt (touch) or 14pt (text)
Four
Mutiply with ⁴⁄₃ to size up
Six
Margins and containers divisible by six

On top of our grid, we developed 3 rules for sizing. This simplified decision making and minimised “pixel-pushing”, creating calculatable design choices over arbitrary preferences. No choosing between 22 and 23 pt size—a headline size can be derived from the body copy based on a formula.

Learning how designers actually work

Once we had a brand grammar in place, we needed to build a vocabulary—see what design elements were most used and test the system. We involved the entire design team, interviewing people on the slowest part of their work, what they got the most pushback on, and their most repeated tasks. This allowed us to prioritise items, test and iterate, building a product workflow on top of our marketing design team’s needs.


Top requests
CTA assets for reuse
Daily ad banners
Shared resources like logos
CTA system  •  creating repeatable patterns to improve reusability

Connecting teams

Refresh, don’t rebuild

As a small product design team, we worked fast, bounced ideas off each other and produced a lot of work. However design solutions could often get disconnected from business goals or development sprints. This misalignment would mean broad ideas languished while more pressing concerns were implemented.

Until our design system overhaul was implemented, we also had to produce two versions of everything: a dream version and a realistic version that works from the current state of the codebase. This was a mistake on our part—we altered design without considering development time. Referencing our pace layers, it’s the friction associated with trying to move the centre wheel and everything with it. It’s slow and difficult by design.

Aside from that, not having developers as part of the design process meant missing out on insights on the best path to implementation. Developers used components when they had semantic meaning—when the logic of why was an intrinsic part of the design and name of the component.

We handled this with “Platform Week”

Silhouettes visually separate components for different sections of the app

Platform Week

Breaking out of the sprint cycle

The regular sprint cycle works on an outer pace layer. In order to make changes lower down, we needed a secondary cycle. We dedicated a week every month for a team member each from product, marketing and development to work together on advancing the platform. We audited the colour and typographic variable names being used in the codebase, created a semantic list that reflected how designers were planning uses and connected Sketch libraries and Zeplin Styleguides.

This meant designers and developers could use descriptive terms like “heading” rather than 27pt bold, giving meaning to design decisions. Developers could see the reason behind decisions, and spot any mistakes in design files. It’s a simple change, but design reviews went smoother, and designers could see the effect of variable changes across the entire app.

This allows continued work on the library while its components are used for production the rest of the month.

Obligatory screenshot of our Sketch library

Improving the product in layers to ensure a smooth transition across the codebase