Litres is a large e-commerce platform across iOS, Android, web and mobile web, built by separate teams with 10+ years of legacy. I started its design system as an internal product: I interviewed developers, designers and PMs, won support from three department heads, and led the team that built the first version. Feature delivery time improved x3 (at average), and the system became a company-wide standard.
YEAR
2021-2022
ROLE
Design Director
SERVICES
Design System, Leadership, Internal Product
Litres is large multi-platform product — design team supported several apps on both iOS and Android, as well as web and mobile web design, and satellite products, all developed by separate teams.
The main expectation from the design team is consistency across all products.
Because we didn't have any kind of design system, consistancy was mainly seen as "not allowing any changes" (because it would create design debt as well as tech debt).
But in the end it led to situation where:
everything looks old (as a consensus among the users)
any changes are very expensive and very hard to track
time-to-market is months to a year (⊙ _ ⊙ )
Innovation and fast tests are almost impossible
pixel-perfect approach
Pixel-perfect approach doesn't work
Because with every mockup everyone is concentrated on finding the smallest inconstancies and perfecting the same small details all over again: "…let's make this padding a liiiiitle bigger, and are you sure you used the right hue of orange, and don't you understand how expensive it is to change the checkbox style?…"
All of this are system questions, and should be governed systematically
Because first and foremost the Design System idea came out of cataloguing pains of people who were part of the process.
Me and teams of designers gathered and formalized requirements from designers and PMs;
And interviewed key developers:
React Architect of main LitRes, responsible for future move from XSLT stack to React
Head of Mobile Development to gather systemic problems
Android and iOS developers to understand more specific problems
Selfpub developers to understand their struggles with legacy stack and discuss future plans for React move
Very large product, several large teams, each with their own frontend
Technical debt. On web apps — old stack, not easy to change (10+ years of legacy)
Heavy workload — so no extra time to think on improvements
Very long TTM — agile approach almost impossible
The product's reputation suffers
A product is a big e-commerce, so changes have to be cautios — the price of mistake may be very high
Long Time to Market in our case was measured in years
Consistency built on a basis that everything should be the same and never change
Design is very constrained because any UI change is expensive
Very long TTM
Design debt
UX suffers because it is impossible to implement modern solutions
In the end, designers were demoralized, because they can’t fully apply themselves and often didn’t see impact of their work
Devs:
Must stop adding new design and technical debt: new UI is built from shared elements, not one-off styles
Must fit into work teams already had (the React migration and Selfpub rewrite) instead of adding a separate workload
Must make a future UI restructuring a change in one place, not screen by screen
Products:
Must shorten the time to ship big features
Must make small UI changes cheap enough to run experiments
Must make changes predictable and low-risk in a high-stakes e-commerce
Designers:
Must give designers a shared UI layer they can control and evolve
Must keep consistency while allowing change
Must keep web, iOS, Android and Selfpub on the same principles, even though each is built separately
The project grew out of shared understanding and need for systemic changes, but to start real work on it we needed three things: allies, resources and a first real use.
We had a team of designers working on basic principles of future design system, but to start implementing it we needed development resources — meaning we needed allies.
Head of Mobile Development allocated time and resources of iOS and Android developers
CPO of Litres allocated time of all designers
CPO of Selfpub allocated developer time and decided to move the Selfpub rewrite together with the design system
The CPO of Selfpub and one of its React developers liked the idea, because Selfpub was considering a move from its legacy frontend to React. Together we organized a team and spent the first stage on the foundation: base principles and the structure of tokens and components.
In parallel, we started working with the people who would use the system. We talked to developers and built a feedback loop with designers, collected feedback and started processes with them, so the system was shaped by the teams, not handed over to them. This also brought the first big extension: a design system for mobile apps.
Selfpub became the first real use. They were planning a frontend rewrite anyway, their CPO was on our side, and their React developers had been part of the work from the start. The Selfpub remake was built by their dev team on our design system.
Selfpub remake: the first product built on the design system, with the fastest TTM in the company.
We started with audits of all product surfaces, to see what we really had: how many versions of the same element existed, where styles had drifted apart, and what the platforms shared. Then we built the foundation.
Colors and attributes. A color system built around attributes, not raw values, including attribute pairs for the dark theme on the mobile apps.
Text styles. A new text style system, built on a new font PT Sans.
Breakpoints and grids. One set of breakpoints and grids for web and mobile web, so layouts follow the same rules.
On top of that foundation we set a hierarchy for the design system:
Tokens
Components
Complex components and page components
Patterns
Each level is built only from the one below it, so a change at the bottom reaches everything above it.
Tokens → components → complex and page components → patterns
The design system changed how fast and how safely we could change the product.
Time to market improved drastically, especially for global changes like rebranding.
After the pilot we kept growing the system and started bringing the same principles to other teams. Developers from different teams began petitioning to form a team dedicated exclusively to the design system.
Developers from different teams were asking for a team dedicated exclusively to the design system.
Litres is a large e-commerce platform across iOS, Android, web and mobile web, built by separate teams with 10+ years of legacy. I started its design system as an internal product: I interviewed developers, designers and PMs, won support from three department heads, and led the team that built the first version. Feature delivery time improved x3 (at average), and the system became a company-wide standard.
YEAR
2021-2022
ROLE
Design Director
SERVICES
Design System, Leadership, Internal Product
Litres is large multi-platform product — design team supported several apps on both iOS and Android, as well as web and mobile web design, and satellite products, all developed by separate teams.
The main expectation from the design team is consistency across all products.
Because we didn't have any kind of design system, consistancy was mainly seen as "not allowing any changes" (because it would create design debt as well as tech debt).
But in the end it led to situation where:
everything looks old (as a consensus among the users)
any changes are very expensive and very hard to track
time-to-market is months to a year (⊙ _ ⊙ )
Innovation and fast tests are almost impossible
pixel-perfect approach
Pixel-perfect approach doesn't work
Because with every mockup everyone is concentrated on finding the smallest inconstancies and perfecting the same small details all over again: "…let's make this padding a liiiiitle bigger, and are you sure you used the right hue of orange, and don't you understand how expensive it is to change the checkbox style?…"
All of this are system questions, and should be governed systematically
Because first and foremost the Design System idea came out of cataloguing pains of people who were part of the process.
Me and teams of designers gathered and formalized requirements from designers and PMs;
And interviewed key developers:
React Architect of main LitRes, responsible for future move from XSLT stack to React
Head of Mobile Development to gather systemic problems
Android and iOS developers to understand more specific problems
Selfpub developers to understand their struggles with legacy stack and discuss future plans for React move
Very large product, several large teams, each with their own frontend
Technical debt. On web apps — old stack, not easy to change (10+ years of legacy)
Heavy workload — so no extra time to think on improvements
Very long TTM — agile approach almost impossible
The product's reputation suffers
A product is a big e-commerce, so changes have to be cautios — the price of mistake may be very high
Long Time to Market in our case was measured in years
Consistency built on a basis that everything should be the same and never change
Design is very constrained because any UI change is expensive
Very long TTM
Design debt
UX suffers because it is impossible to implement modern solutions
In the end, designers were demoralized, because they can’t fully apply themselves and often didn’t see impact of their work
Devs:
Must stop adding new design and technical debt: new UI is built from shared elements, not one-off styles
Must fit into work teams already had (the React migration and Selfpub rewrite) instead of adding a separate workload
Must make a future UI restructuring a change in one place, not screen by screen
Products:
Must shorten the time to ship big features
Must make small UI changes cheap enough to run experiments
Must make changes predictable and low-risk in a high-stakes e-commerce
Designers:
Must give designers a shared UI layer they can control and evolve
Must keep consistency while allowing change
Must keep web, iOS, Android and Selfpub on the same principles, even though each is built separately
The project grew out of shared understanding and need for systemic changes, but to start real work on it we needed three things: allies, resources and a first real use.
We had a team of designers working on basic principles of future design system, but to start implementing it we needed development resources — meaning we needed allies.
Head of Mobile Development allocated time and resources of iOS and Android developers
CPO of Litres allocated time of all designers
CPO of Selfpub allocated developer time and decided to move the Selfpub rewrite together with the design system
The CPO of Selfpub and one of its React developers liked the idea, because Selfpub was considering a move from its legacy frontend to React. Together we organized a team and spent the first stage on the foundation: base principles and the structure of tokens and components.
In parallel, we started working with the people who would use the system. We talked to developers and built a feedback loop with designers, collected feedback and started processes with them, so the system was shaped by the teams, not handed over to them. This also brought the first big extension: a design system for mobile apps.
Selfpub became the first real use. They were planning a frontend rewrite anyway, their CPO was on our side, and their React developers had been part of the work from the start. The Selfpub remake was built by their dev team on our design system.
Selfpub remake: the first product built on the design system, with the fastest TTM in the company.
We started with audits of all product surfaces, to see what we really had: how many versions of the same element existed, where styles had drifted apart, and what the platforms shared. Then we built the foundation.
Colors and attributes. A color system built around attributes, not raw values, including attribute pairs for the dark theme on the mobile apps.
Text styles. A new text style system, built on a new font PT Sans.
Breakpoints and grids. One set of breakpoints and grids for web and mobile web, so layouts follow the same rules.
On top of that foundation we set a hierarchy for the design system:
Tokens
Components
Complex components and page components
Patterns
Each level is built only from the one below it, so a change at the bottom reaches everything above it.
Tokens → components → complex and page components → patterns
The design system changed how fast and how safely we could change the product.
Time to market improved drastically, especially for global changes like rebranding.
After the pilot we kept growing the system and started bringing the same principles to other teams. Developers from different teams began petitioning to form a team dedicated exclusively to the design system.
Developers from different teams were asking for a team dedicated exclusively to the design system.
Litres is a large e-commerce platform across iOS, Android, web and mobile web, built by separate teams with 10+ years of legacy. I started its design system as an internal product: I interviewed developers, designers and PMs, won support from three department heads, and led the team that built the first version. Feature delivery time improved x3 (at average), and the system became a company-wide standard.
YEAR
2021-2022
ROLE
Design Director
SERVICES
Design System, Leadership, Internal Product
Litres is large multi-platform product — design team supported several apps on both iOS and Android, as well as web and mobile web design, and satellite products, all developed by separate teams.
The main expectation from the design team is consistency across all products.
Because we didn't have any kind of design system, consistancy was mainly seen as "not allowing any changes" (because it would create design debt as well as tech debt).
But in the end it led to situation where:
everything looks old (as a consensus among the users)
any changes are very expensive and very hard to track
time-to-market is months to a year (⊙ _ ⊙ )
Innovation and fast tests are almost impossible
pixel-perfect approach
Pixel-perfect approach doesn't work
Because with every mockup everyone is concentrated on finding the smallest inconstancies and perfecting the same small details all over again: "…let's make this padding a liiiiitle bigger, and are you sure you used the right hue of orange, and don't you understand how expensive it is to change the checkbox style?…"
All of this are system questions, and should be governed systematically
Because first and foremost the Design System idea came out of cataloguing pains of people who were part of the process.
Me and teams of designers gathered and formalized requirements from designers and PMs;
And interviewed key developers:
React Architect of main LitRes, responsible for future move from XSLT stack to React
Head of Mobile Development to gather systemic problems
Android and iOS developers to understand more specific problems
Selfpub developers to understand their struggles with legacy stack and discuss future plans for React move
Very large product, several large teams, each with their own frontend
Technical debt. On web apps — old stack, not easy to change (10+ years of legacy)
Heavy workload — so no extra time to think on improvements
Very long TTM — agile approach almost impossible
The product's reputation suffers
A product is a big e-commerce, so changes have to be cautios — the price of mistake may be very high
Long Time to Market in our case was measured in years
Consistency built on a basis that everything should be the same and never change
Design is very constrained because any UI change is expensive
Very long TTM
Design debt
UX suffers because it is impossible to implement modern solutions
In the end, designers were demoralized, because they can’t fully apply themselves and often didn’t see impact of their work
Devs:
Must stop adding new design and technical debt: new UI is built from shared elements, not one-off styles
Must fit into work teams already had (the React migration and Selfpub rewrite) instead of adding a separate workload
Must make a future UI restructuring a change in one place, not screen by screen
Products:
Must shorten the time to ship big features
Must make small UI changes cheap enough to run experiments
Must make changes predictable and low-risk in a high-stakes e-commerce
Designers:
Must give designers a shared UI layer they can control and evolve
Must keep consistency while allowing change
Must keep web, iOS, Android and Selfpub on the same principles, even though each is built separately
The project grew out of shared understanding and need for systemic changes, but to start real work on it we needed three things: allies, resources and a first real use.
We had a team of designers working on basic principles of future design system, but to start implementing it we needed development resources — meaning we needed allies.
Head of Mobile Development allocated time and resources of iOS and Android developers
CPO of Litres allocated time of all designers
CPO of Selfpub allocated developer time and decided to move the Selfpub rewrite together with the design system
The CPO of Selfpub and one of its React developers liked the idea, because Selfpub was considering a move from its legacy frontend to React. Together we organized a team and spent the first stage on the foundation: base principles and the structure of tokens and components.
In parallel, we started working with the people who would use the system. We talked to developers and built a feedback loop with designers, collected feedback and started processes with them, so the system was shaped by the teams, not handed over to them. This also brought the first big extension: a design system for mobile apps.
Selfpub became the first real use. They were planning a frontend rewrite anyway, their CPO was on our side, and their React developers had been part of the work from the start. The Selfpub remake was built by their dev team on our design system.
Selfpub remake: the first product built on the design system, with the fastest TTM in the company.
We started with audits of all product surfaces, to see what we really had: how many versions of the same element existed, where styles had drifted apart, and what the platforms shared. Then we built the foundation.
Colors and attributes. A color system built around attributes, not raw values, including attribute pairs for the dark theme on the mobile apps.
Text styles. A new text style system, built on a new font PT Sans.
Breakpoints and grids. One set of breakpoints and grids for web and mobile web, so layouts follow the same rules.
On top of that foundation we set a hierarchy for the design system:
Tokens
Components
Complex components and page components
Patterns
Each level is built only from the one below it, so a change at the bottom reaches everything above it.
Tokens → components → complex and page components → patterns
The design system changed how fast and how safely we could change the product.
Time to market improved drastically, especially for global changes like rebranding.
After the pilot we kept growing the system and started bringing the same principles to other teams. Developers from different teams began petitioning to form a team dedicated exclusively to the design system.
Developers from different teams were asking for a team dedicated exclusively to the design system.