The Design System at Infoedge is a unified system to define, design and develop products to embrace the production at scale keeping consistency and reusability at the heart of the process, in order to deliver seamless, meaningful and delightful experiences to our consumers across all our products.
Infoedge started in 1995, with a classified recruitment online business, naukri.com and we’ve been constantly expanding since then. Today, it is India’s premier online classifieds company in recruitment, matrimony, real estate, education and related services. Currently we have around 8 core products and new products keep coming every now and then.
In such, it has become harder to design and ship at this massive scale. One hand doesn’t know what the other hand is doing and worst happens when you multiply this many people, times many projects, times many teams and times many years. All this has resulted in a sprawl of design solutions everywhere resulting in a lot of inconsistency & inefficiency in our production and poor experience in our products.
It was clear that we needed to organise ourselves and optimise the way we work. There was an urgent need of a Design System.
Starting out with a Pilot Project
Once we knew that we needed a design system, there was another requirement to get a buy-in from key stakeholders for the allocation of resources and bandwidth but taking into account the apprehensions that people might have because of the unsuccessful attempts made in past to incorporate similar ideas. We went with the approach of ‘show over tell’.
So, Design Team internally decided to work on and test the idea of design system on one of our projects.
We started with our research on design system, referring to atomic design theory and carefully studying and analysing design systems of several organisations followed by realising our own needs.
We identified following as the core objectives that we wanted to achieve with our design system.
1. Faster Production at Scale
One of the core objectives behind the idea of the design system was to increase the overall speed and efficiency of design, development and collaboration within and across teams to embrace the faster production at scale. Having reusability at its core, we wanted a system that is composed of smarter styles and smarter components that can provide ways to iterate and test concepts faster hence improve and optimise the speed and efficiency of production.
2. Consistency in Experience of a Product
Because of obvious reasons, there prevailed a lot of inconsistency in several infoedge products within and across platforms.
We needed a system that act like a single source of truth for designers, developers, product managers and other stakeholders to constantly refer to and act accordingly in order to drive consistency .
3. Infusing Brand Personalities
For a longer period of time, our products have been purely functional. They carry little to no personality of their brand in order to appeal to the target consumer segment.
We wanted a system that can help to infuse brand personality into the products while keeping the usability & consistency intact.
Creating the Design System
Learning from other people’s efforts and based on our requirements, we planned a step by step process for our design system.
1. Product Audit — Hunting for Inconsistencies
The process began by hunting down the inconsistencies and sprawl across the product. We collected different product patterns, atomic level components and styles and carefully analysed them to seek opportunities to introduce re-usability and bring in consistency across styles, components and layouts.
2. Defining Design Principles & Exploring the Visual Directions
We knew from the beginning that the problem of inconsistencies & lack of reusability that we’re trying to solve will come again if we don’t define a visual language based on some underlying principles that everybody agrees and adheres to. So we started exploring several visual styles and jotting down the principles that synthesise a consistent visual language comprising of guidelines for using colour, type, shape, elevation and spacing in UI. This led us to identify and establish the scope of what we now call as reusable properties.
3. Reusable Properties
Reusable Properties are style (CSS) properties that are used again and again across several styles, like colours, elevations (shadows), border radii, font-size, font-weight or line-height, paddings, margins etc. Different permutations and combinations of these properties are used several times to define styles (or classes)for various UI components like Buttons, Cards, Texts etc. These properties may exist as style variables in CSS, SASS or any other stylesheet language.
4. Reusable Styles
Reusable styles are the sets of different permutations and combinations of the style variables or Reusable Properties like colour, border, shadows, padding, margin etc. that apply to the various UI Components. They include Card Styles, Button Styles, Text Styles, Input Field Styles etc. These styles can be achieved with various css classes using, parent-child and / or sibling relationships.
Taking our inspiration from atomic design theory, we identified and defined the basic building blocks of our interface and called them as Primitives — the atomic level components that inherit reusable styles and are to be used to build any no. of complex level UI components. Primitives comprises of the atomic level UI elements that cannot be further broken down like Buttons, Labels, Tags, Tabs etc.
Once We had all the primitives in place and styles defined, we started playing around with them taking into consideration the reusability of primitives and styles while constantly adhering to the principles that we defined for ourselves. We started to work on a bit more complex parts of UI and referred to them as components like input fields, list items, dropdowns, notification banners etc. Components are required to be modular in order to serve various use cases and need to stay very versatile how they can be used.
7. Product Patterns
After components, it was time to assemble primitives, components and styles all together in a modular fashion to create even more complex and meaning pieces of interface that can adapt as per various pages and/or use cases. We called such interface components as product patterns. They are composed out of primitives, components or even individual styles like cards, Tuples, widgets, filters etc.
Templates refer to a set of certain product patterns that appear on a set of pages in the exact same layout. The can reused across pages or use cases.
Pulling it all together in a Sketch File
Sketch features like text and layer styles, symbols, plugins like anima, runner etc were used to create Styles, Primitives and Components in a sketch library file and shared with the team members to use the design system in their design files giving them the ease to use pre-built components to create their flows and comps, the product patterns were constantly added to the library file further adding to the re-usability of the ui kit. This helped designers to quickly create mocks and concepts while preserving the consistency even with different designers working on the same file. Since everything was a symbol or style instance from ui kit, it also became a lot more easier to iterate in terms of concepts and visual style and overall it helped a lot to increase the efficiency and speed at which we were designing the pages.
Aligning Stakeholders for an Organisation-Wide Design System
Once our pilot project was successful, It was time to expand the design system across the organisation and show how design system can transform the way we design and develop products. Several meetings were conducted with design and dev. team of different products to demonstrate the power of design system and how it can be implemented to increase the overall speed and efficiency of production.
Scaling the Design System
While building our very first design system for the pilot project, a lot of problems were also discovered in the implementation of the system, falling in the major categories of issues related to performance & usability, documentation & reference, communication, cross-teams collaboration, File-system management, updates & fallbacks. Thus few improvements were required before it expands across the organisation.
Because of a lot symbols of primitives, components and product patterns, in one sketch file, we were experiencing a lot of lag while using the sketch library. So it was decided to have different pattern libraries. Further new styles and components were added in order to address the needs of different products.
One of the objectives of our design system was to infuse brand personalities into our products while embracing the reusability of design and code components.
It was evident that with mere changes of reusable style properties like colour, border radii, typeface, elevations(shadows), spacing etc into the base ui kit the primitives and components can very quickly transform to the look and feel of different products. So we built upon this hypothesis and introduced theming into the design system.
We defined theming as a systematic approach to customise the look and feel of a product by changing the basic style properties (better known as design tokens) driven by the core principles of our design system yet preserving the reusability of design and code components. Theming helped tremendously to use and re-use the design and code assets across the products and teams resulting in a lot more faster and efficient production while maintaining the individuality of the product.
Making It More Usable
One of the major lessons, we learnt from out pilot project was that it’s not easy to get started with using the design system. It seemed a like a major workflow change. It was like asking someone to suddenly start writing with his left hand when he/she has grown up writing with right. It was clear that our design system had to be more usable. we identified the major pain points of the designers while using the design system and took the following measures to make it more usable.
Documentation: Not everyone was aware of the design system. Even after initial demonstration of what to use when and how. It was very much needed to provide designers with a documentation that they can continuously refer to.
We solved this issue by documenting our design system with the help of a tool called ‘Zeroheight’ which now has ended up being our single source of truth that everyone across teams and departments refer to.
Zeroheight was great to refer as a styleguide website but we also wanted something that can give designers a contextual hint what to use when and how while they’re working on concepts. For this we used sketch plugin called Stickers that allowed a drag and drop functionality of components while also providing some contextual information about the component.
Finding & Using Components : Once matured properly, there were a lot of components, primitives and styles in the design system. It was becoming harder to find and use the right component. Sketch plugins like ‘Runner’ and ‘Stickers’ helped a lot to search and use the components quickly and helped to make the design system more user friendly.
Using the Data in Designs: Once we had the reusable styles & components, we also wanted to automate the process of populating our design mocks with data. We used Sketch Data for this purpose. For a bit more complex product specific patterns where data required some manipulation we used the plugin Sketch Data Populator to fetch data from an excel sheet via json.
Centralised File System: It was clear that Design system requires constant updates for addition of newer components and Styles, improvements in the existing ones and removal of the components that are no longer in use. Design System is accessible to all It should be easily available to and used by all the designers in the team. This collaborative nature of a design system requires a shared file system. So we used Microsoft OneDrive to store, share and collaborate on files across the team.
Managing the Design System
Design System is clearly a living system. It keeps evolving with your product, with your team, as your philosophies change. It is not a one time task, it is constant mutual effort to make things work in an organised and efficient manner.
Expansion of Design System presented obvious challenges of how will it managed, who all will work on it, how much bandwidth will it need etc. etc.
When we thought of building our team, few things were certain that a single centralised team won’t be able to solve the challenges of a constantly evolving design system that caters to a variety of products because the members of a centralised team might have a deep understanding of design system and the way it functions and all, but they may lack the in-depth understanding of the products it will apply to.
Also a federated team would present challenges of bandwidth clashing between their product timelines and design system timelines.
In such we decided to go ahead with the Cyclical Team Model for our design system where there is a centralised team of designer, developers and others that constantly contribute to evolve the design system and then there are individual design system representatives in each product team to constantly collaborate with the centralised team to ensure the smooth application of design system within their products.
Further Slack Channel was created and set up for smooth communication and resolution of bugs and fixes.
As mentioned earlier Infoedge is growing at a tremendous scale, a lot of existing products are getting revamped and new products are coming up too. This has resulted in a too much work for both designers and developers. In such, having a design system has significantly improved speed and efficiency of our workflow and completely transformed the way we design and develop products.
For Designers, it has helped to
- Wireframe with primitives (atomic & molecular) and components for new Concepts/features in existing products or entirely new products.
- Exploring, creating and applying visual theme for the ui components and the overall product.
- Create final concepts with real-data (using the data api) and expand the component base (creating patterns) as per the product-specific requirements.
- Deliver and hand-off the theming guidelines (or update design tokens) with developers.
For Developers, it has helped to
- Use and re-use the base components (atomic and molecular level) to prototype the wireframes at early stage to test the new concepts.
- Use the theming engine (with design tokens) to apply the product-platform-specific visual language to create production ready prototype.
- Use the data-api to map front-end code with dummy / or real data to create high-fidelity prototype for market / user testing.
and hence it has increased the overall efficiency & speed of the production at scale.