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.
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.
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.
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.
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.
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.
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.
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”
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.
