Dream11
Design System
About
Dream11.com
Dream11 is India's largest sports fantasy platform. Users create a virtual team of real life players and earn points based on the performances of these players in real matches.
To ensure that all 120+ million users experience the same brand value and everyone in the organisation shares the same vocabulary, we worked towards building a design system.
.png)
Problem
Each platform at Dream11, maintained their own copy of design values and components. There was no standardization among user interface components. This led our teams working on different features to create the same components with different names, which caused redundancy.
We raked through the new, the old and the ugly, to bring together a system that could be used, maintained, and easily updated internally to make the addition or modification of new features, pages or products a piece of cake.
Mission
Design System as a single source of truth.
As our product was being used by millions, we understood that prioritizing a design system was imperative to the product's scalability and reach the following goals:
​
It is important to point out that design systems shouldn't be written in ink. The point is not to limit a designer's creativity. Rather to open the door for a collaborative document that can be tracked and maintained by the entire group. There's an awesome new shadow style we'd like to use? Great, let's update the design system so that all shadows use it, consistently.
Audit
This was like a magnifying glass for our brand's visual elements. We took a hard look at everything the company put out there, ensuring the brand's image, vibe, and messaging are rock-solid and consistent across the board. We conducted a thorough audit to capture every asset currently in use across the app.
Figma as the main platform : We took screenshots of everything that crossed our path, recording the most critical user flows and processes. We assembled everything into Figma, scribbled notes all over the place, and played detective, hunting down any visual or functional flaws.
Inventory
After dissecting the product and examining every detail, we put it together in one place. A clean, straightforward and thorough description of the elements in use. Explaining where to use them and how to use them again.
.png)
Documentation
Structure
We adopted Brad Frost’s Atomic Design Pattern for our design elements. The smallest units are attribute values like color, dimension, font, etc. These are treated as atoms of the design system, which then combine to form molecules. These, in turn, combine to form organisms and so on.
.png)
Atomic Design Pattern
Next, we grouped components by purpose. When considering if the component is valuable enough to be part of the design system, we asked ourselves:
.png)
Based on the answers, we built an essential library.
Structure
Component library
Like most successful design systems, we set up a base structure with simple design templates that included: Typography, Colors, Iconography, Components, Imagery, Spacing, Content Structure, etc.
With the building blocks in place, we could refine an existing feature or could build a new one element by element.
Design Tokens
Instead of using hard codes like color hex codes or pixel sizes, we gave them names. These names, or 'tokens', stored design details in a simple, easy-to-read way. They worked with all style files in our system, making our design consistent and easy to scale.
Global tokens are the primitive values
Alias tokens relate to specific content
Component-specific tokens relates to a component.
Together, it works like a charm
.png)
naming conventions: The Token below is a complex one, but it narrates a story. Without looking at the documentation or the value, both designer and developer can tell it is a color token, meant to be used on the background of containers like cards or sections, for example. It also communicates that there might be different variants that convey hierarchy, and it also communicates that it is targeting a specific state of that surface.
Collaboration
So the flow goes like,
-
Designer updates a style in a design library.
-
A design tokens generator updates a centralised repository creating platform-specific files (JSON/YAML)
-
Developers extract the new repository , add any new tokens, and automatically update the project’s styles.
-
Developers/Designers collaborate on a management platform like Atlassian or Jira, where they can manage the existing components, tokens and request for new ones.
Key performance indicators: We have a clear bias towards having a design system to work from. Here are some of the KPIs ours afforded us:
.png)
It's a great example of painting the back of the fence. Doing the hard and sometimes tedious work of setting up an organized structure makes the quality of the product design speak for itself.
Design System
design system is alive
Like a living organism, the Design System is meant to evolve. Good design systems are dynamic entities that adapt seamlessly to a company’s growth and changes. The real magic of a design system is in minimizing the duplication of effort by the designers and engineers who bring a product to life.
The future of design systems lies in no-code — an environment that blends the roles of designer and engineer, eliminating the friction of the traditional handoff.
Credits
3 teams, countless contributors
Design Team
Engineering Team
Product Team
Differentiating JioSaavn's music discovery experience View Project
Taking personalisation to a different level. View Project
