© 2024, All Right Reserved ✦ Last update Jul 2024
DS
Dom.ru Design System
Team Objectives
1. Accelerate the design development process. Make components flexible and adaptive.
1. Accelerate the design development process. Make components flexible and adaptive.
2. Document components to bring clarity to their use and speed up the onboarding process.
2. Document components to bring clarity to their use and speed up the onboarding process.
3. Establish lifecycle management for components and tokens.
3. Establish lifecycle management for components and tokens.
4. Simplify and speed up the processes related to handing off designs for development.
4. Simplify and speed up the processes related to handing off designs for development.
5. Improve communication and collaboration. The design system can serve as a single source of truth for the entire team. The rebranding experience showed how processes can become desynchronized across different teams.
5. Improve communication and collaboration. The design system can serve as a single source of truth for the entire team. The rebranding experience showed how processes can become desynchronized across different teams.
Business Goals
1. Accelerate scaling and growth. A design system would simplify the addition of new products and features by providing ready-made solutions for developers and designers.
1. Accelerate scaling and growth. A design system would simplify the addition of new products and features by providing ready-made solutions for developers and designers.
2. Reduce costs and increase efficiency. Cut down the time spent on developing and maintaining interfaces, as many solutions are pre-designed and tested. This reduces development costs and simplifies product maintenance and updates.
2. Reduce costs and increase efficiency. Cut down the time spent on developing and maintaining interfaces, as many solutions are pre-designed and tested. This reduces development costs and simplifies product maintenance and updates.
Starting Point
1. Roadmap
Initiated meetings with designers, product managers, and developers. Discussed the prioritization of various tasks related to the system, how they would fit into the overall product development, and feature implementation.
Initiated meetings with designers, product managers, and developers. Discussed the prioritization of various tasks related to the system, how they would fit into the overall product development, and feature implementation.
2. Finding Common Ground
Products such as Movix and Smart Home coexist and evolve within the same ecosystem as Dom.ru. Each design team had a UI-Kit where some elements were stored. Conducted a brief research and found commonalities among some components, leading to the creation of a unified library — 🥑 Core. This library includes all covers, standardized buttons, social media icons, navigation elements, and more for designing layouts in Figma.
Products such as Movix and Smart Home coexist and evolve within the same ecosystem as Dom.ru. Each design team had a UI-Kit where some elements were stored. Conducted a brief research and found commonalities among some components, leading to the creation of a unified library — 🥑 Core. This library includes all covers, standardized buttons, social media icons, navigation elements, and more for designing layouts in Figma.
3. Structure
Created a general structure for all future libraries in the project, allowing for an assessment and grouping of all existing libraries.
Decided early on to separate key elements (typography, icons, etc.) into individual libraries to allow flexible integration and avoid overloading Figma files when working with many screens or different platforms.
Created a general structure for all future libraries in the project, allowing for an assessment and grouping of all existing libraries.
Decided early on to separate key elements (typography, icons, etc.) into individual libraries to allow flexible integration and avoid overloading Figma files when working with many screens or different platforms.
4. Developer Coordination
4. Developer Coordination
Began communication with developers early on. Organized several meetings to identify needs and issues with current processes.
Found some enthusiasts within the team to help untangle the legacy in the react library. Delved into the existing documentation and entrenched processes.
Began communication with developers early on. Organized several meetings to identify needs and issues with current processes.
Found some enthusiasts within the team to help untangle the legacy in the react library. Delved into the existing documentation and entrenched processes.
Creating a New Design System
1. Tokens
Following the principles of atomic design methodology, began creating the new system from the smallest particles – tokens. Initially, tokens were in Storybook and used only by developers. However, they were not organized, and many were redundant. The process of working on new tokens was complex and required significant refactoring in the code. Everyone understood that this foundation was essential for creating a truly consistent and flexible system. Over six months, naming and prefix structures were refined, significantly speeding up all processes around development.
Following the principles of atomic design methodology, began creating the new system from the smallest particles – tokens. Initially, tokens were in Storybook and used only by developers. However, they were not organized, and many were redundant. The process of working on new tokens was complex and required significant refactoring in the code. Everyone understood that this foundation was essential for creating a truly consistent and flexible system. Over six months, naming and prefix structures were refined, significantly speeding up all processes around development.
Hierarchy
First-level tokens — brand tokens — project brand code
Second-level tokens — components tokens — responsible for specific values of specific components
Token Set
Components tokens
Opacity
Color
Border Radius
Font Size
Border
Brand tokens
Font Family
Font
Color
Spacing
Naming
Together with developers, defined and described a clear prefix system in naming. Each token has certain characteristics, which were kept simple. Here are a couple of examples:
Shadow
type - inner/drop
blur - none/low/normal/medium/high spread - none/low/normal/medium/high
Font
size - title - h1/h2/h3…
size - paragraph - p1/p2/p3…
weight - regular/medium/bold
style - uppercase/normal
JSON
All tokens are exported and less frequently imported through the JSON format. This format is simple for storing and transmitting data between server and platform.
2. Colors
2. Colors
After the 2022 product rebranding, a new color palette for Dom.ru was defined. Together with the design team, created a set of colors used in the product and brand design. The new palettes help maintain visual style consistency and ensure uniformity across both interfaces and graphic elements.
After the 2022 product rebranding, a new color palette for Dom.ru was defined. Together with the design team, created a set of colors used in the product and brand design. The new palettes help maintain visual style consistency and ensure uniformity across both interfaces and graphic elements.
Palette
The palette consists of four color gradients and one neutral (black-and-white).
The palette consists of four color gradients and one neutral (black-and-white).
Color Tokens
Tried different matrices of characteristics for defining color tokens in specific elements. There was a group of colors directly for typography, a group for labels, and so on. Experimented with combining states (pressed, hover, disabled). To avoid numerous overlapping token lists, settled on a flexible and universal model. The essence is that semantics remain only at the most basic color characteristics. Combining them yields predefined colors.
Tried different matrices of characteristics for defining color tokens in specific elements. There was a group of colors directly for typography, a group for labels, and so on. Experimented with combining states (pressed, hover, disabled). To avoid numerous overlapping token lists, settled on a flexible and universal model. The essence is that semantics remain only at the most basic color characteristics. Combining them yields predefined colors.
Light/Dark Theme
Light/Dark Theme
Implemented a palette for the dark theme in the mobile app. Colors are deep and rich, maintaining accents and individual app style. Active elements retain hierarchy and accessibility for users with color vision deficiencies.
For convenient work with semantic and abstract palettes, separated them into different files. This approach prevents mixing and provides flexible support and application in Figma.
Implemented a palette for the dark theme in the mobile app. Colors are deep and rich, maintaining accents and individual app style. Active elements retain hierarchy and accessibility for users with color vision deficiencies.
For convenient work with semantic and abstract palettes, separated them into different files. This approach prevents mixing and provides flexible support and application in Figma.
3. Typography
Font
The product font is CoFo Sans. Neutral in character and versatile in application. Used in three styles – regular, medium, and bold. Adjusted kerning and leading for each size. Paid special attention to headings.
The product font is CoFo Sans. Neutral in character and versatile in application. Used in three styles – regular, medium, and bold. Adjusted kerning and leading for each size. Paid special attention to headings.
Different Font Libraries
Font styles and components differ for web and apps due to several reasons:
• Screen size and resolution;
• Interaction model (touch/non-touch);
• Technical system limitations.
Font styles and components differ for web and apps due to several reasons:
• Screen size and resolution;
• Interaction model (touch/non-touch);
• Technical system limitations.
Font Styles
Consist of three main categories — Headings, Body, and Active. The latter was initially intended only for active interface elements but started being used widely by designers over time. Slight token adjustments were made, but it did not affect style usage in Figma.
Consist of three main categories — Headings, Body, and Active. The latter was initially intended only for active interface elements but started being used widely by designers over time. Slight token adjustments were made, but it did not affect style usage in Figma.
Heading Components
Developed a component for convenient and quick work with headings. It consists of a paragraph token, spacing, and the heading itself. Supports both Desktop and Mobile versions with proportional tags. These transitions are documented in a separate responsive.json.
Developed a component for convenient and quick work with headings. It consists of a paragraph token, spacing, and the heading itself. Supports both Desktop and Mobile versions with proportional tags. These transitions are documented in a separate responsive.json.
4. Icons
The project uses its own pack of 378 icons. New ones are rarely added following the existing guide. Icons are cross-platform and have a linear style. Each has gone through a specific refinement process in Figma, allowing them to be implemented and used in any components without losing color styles and size.
Standardized sizes are 16px, 20px, and 24px with a uniform line thickness of 1.5px.
The project uses its own pack of 378 icons. New ones are rarely added following the existing guide. Icons are cross-platform and have a linear style. Each has gone through a specific refinement process in Figma, allowing them to be implemented and used in any components without losing color styles and size.
Standardized sizes are 16px, 20px, and 24px with a uniform line thickness of 1.5px.
5. Grid
5. Grid
The grid system is a fundamental component of the design system. Though previously not used in the project, compiled existing breakpoints with developers and top user devices with analysts. Approved a new grid system for the web with the art director and developers.
The system consists of 5 grids for different screen resolutions and various container allowances. Organized them in responsive-react. Up to tablet resolutions, it’s a standard 12-column grid. Mobile resolutions connect additional constraints and switch to a 4-column grid. The entire system is in 8px increments.
The grid system is a fundamental component of the design system. Though previously not used in the project, compiled existing breakpoints with developers and top user devices with analysts. Approved a new grid system for the web with the art director and developers.
The system consists of 5 grids for different screen resolutions and various container allowances. Organized them in responsive-react. Up to tablet resolutions, it’s a standard 12-column grid. Mobile resolutions connect additional constraints and switch to a 4-column grid. The entire system is in 8px increments.
6. Components
Components are the lifeblood and the most helpful part of the design system. Creating and implementing these components involves many processes. Thus, laid a solid foundation from the start.
Components are the lifeblood and the most helpful part of the design system. Creating and implementing these components involves many processes. Thus, laid a solid foundation from the start.
Location
Components for web and apps are in separate libraries. They are not divided into separate files within these libraries, as is often convenient in large projects, but are semantically separated within their file.
Components for web and apps are in separate libraries. They are not divided into separate files within these libraries, as is often convenient in large projects, but are semantically separated within their file.
Component Structure
• Components - The component with all possible variations.
• Documentation - Documentation on the component: what it is, where/when to use it, states, links to Jira/Storybook, applicable platforms.
• Anatomy - Component specifications.
• Examples - Component examples in context with links to mockups. May include links to prototypes or animations.
• Components - The component with all possible variations.
• Documentation - Documentation on the component: what it is, where/when to use it, states, links to Jira/Storybook, applicable platforms.
• Anatomy - Component specifications.
• Examples - Component examples in context with links to mockups. May include links to prototypes or animations.
Lifecycles and Statuses
Process:
• Ensure the component doesn’t already exist and is necessary in the design system.
• Approve the new component with the art director.
• Create the component following specified requirements.
• Publish the new component in the design system with an assigned status:
🟡 - component handed over for development
🟢 - component fully ready for use
• Handover to development (create a task for the development team in Jira)
• Testing,
• Design review,
• Change status,
• Notify teams of the new component.
Process:
• Ensure the component doesn’t already exist and is necessary in the design system.
• Approve the new component with the art director.
• Create the component following specified requirements.
• Publish the new component in the design system with an assigned status:
🟡 - component handed over for development
🟢 - component fully ready for use
• Handover to development (create a task for the development team in Jira)
• Testing,
• Design review,
• Change status,
• Notify teams of the new component.
Processes
Throughout working on the design system and beyond, created various documentation sketches. Realized it would be a crucial step for effectively implementing and maintaining all processes around the design system.
As mentioned, part of the documentation is in Figma for designers and developers. It includes information on tokens, components, grids, etc. Additionally, there are checklists and documentation in Notion, primarily for product managers and onboarding new specialists.
Throughout working on the design system and beyond, created various documentation sketches. Realized it would be a crucial step for effectively implementing and maintaining all processes around the design system.
As mentioned, part of the documentation is in Figma for designers and developers. It includes information on tokens, components, grids, etc. Additionally, there are checklists and documentation in Notion, primarily for product managers and onboarding new specialists.
Results
The results have exceeded expectations. The design system has become a nearly independent internal product, despite often being secondary and not having a dedicated team. Significant progress has been made, with most of the roadmap completed. As the product evolves, new needs for systematization and description arise. For instance, now actively integrating 3D illustrations and animation into the interface, organizing them into guides.
The results have exceeded expectations. The design system has become a nearly independent internal product, despite often being secondary and not having a dedicated team. Significant progress has been made, with most of the roadmap completed. As the product evolves, new needs for systematization and description arise. For instance, now actively integrating 3D illustrations and animation into the interface, organizing them into guides.
Let’s go over the stated goals:
Speed up the design development process. Make components flexible and adaptive.
Undoubtedly, this is the first and most obvious improvement enabled by our developed design system. Thanks to well-designed components and checklists for adding them, designers have accelerated the development of new interfaces and modifications to existing ones.
Undoubtedly, this is the first and most obvious improvement enabled by our developed design system. Thanks to well-designed components and checklists for adding them, designers have accelerated the development of new interfaces and modifications to existing ones.
Document components. This will clarify working with them and speed up the onboarding process.
During the work on components, the approach to their description and specification has changed several times, including the location of these documentations. Now, with EVERY component and token, we have standardized documentation in Figma for designers and managers, and in Storybook for web developers. The mechanisms of component usage and associated limitations have become transparent.
During the work on components, the approach to their description and specification has changed several times, including the location of these documentations. Now, with EVERY component and token, we have standardized documentation in Figma for designers and managers, and in Storybook for web developers. The mechanisms of component usage and associated limitations have become transparent.
Establish lifecycle management for components and styles.
After several iterations, we have developed effective checklists for creating and adding new components/styles to the web or app design system. Guidelines have been established on what to do with “local” components in working files and how to publish them in the general library. We have implemented a status system that allows tracking the implementation of components.
After several iterations, we have developed effective checklists for creating and adding new components/styles to the web or app design system. Guidelines have been established on what to do with “local” components in working files and how to publish them in the general library. We have implemented a status system that allows tracking the implementation of components.
Simplify and accelerate processes related to transferring layouts to development.
A design system is, first and foremost, code and everything that doesn’t just live in the Figma UI-kit. Throughout the development of the system, we worked closely with the development team. Continuous communication and collaboration led to the point where most (though not all) components are duplicated in Storybook and test applications. Designers are confident that the components will look and function exactly as intended, and developers are confident that the components have been tested/reviewed and can be used without hesitation.
A design system is, first and foremost, code and everything that doesn’t just live in the Figma UI-kit. Throughout the development of the system, we worked closely with the development team. Continuous communication and collaboration led to the point where most (though not all) components are duplicated in Storybook and test applications. Designers are confident that the components will look and function exactly as intended, and developers are confident that the components have been tested/reviewed and can be used without hesitation.