Oleksii Tsarevskyi

Rebuilding the design system behind Privat24

I led the audit and design of foundations, tokens, components, documentation, and migration.

RoleSenior Product Designer
Scale25M+ users · 10+ services
PlatformsiOS · Android · Web

Context

The system no longer supported current work. Designers and developers bypassed it because local components and overrides were faster.

I rebuilt the connected layers: foundations, tokens, themes, components, library structure, documentation, contribution rules, and Figma-to-code links.

What was broken

01

Mixed foundations

Raw values, semantic roles, and component decisions were mixed. Names described appearance, not purpose, making reuse difficult and change risky.

02

Inconsistent controls

Similar controls had different properties, states, and structures. Logic lived in one person’s head, with no rules for components, themes, or local solutions.

03

Local workarounds

Designers recreated patterns, while developers received similar designs implemented differently. Without shared rules and documented ownership, the library became difficult to maintain and scale.

Foundations

Before

Flat foundations

Colours were stored directly alongside components in a single Figma file. All values lived in a single flat layer. Raw values, semantic roles, themes, and component-specific decisions were mixed together, making updates difficult and inconsistent.

After

Semantic model

The new model separates primitives, semantic tokens, component tokens, and aliases. Primitives store base values, semantic tokens define interface roles, component tokens map them to specific UI elements, and aliases resolve values by platform, mode, theme, state, and density.

Coverage

Beyond colour

The system was extended beyond colour to typography, dimensions, spacing, sizing, grids, radii, borders, elevation, blur, and icons. A separate component-token layer maps foundation values to specific UI elements.

Name light dark junior
primaryColor
primaryLightColor
primaryDarkColor
primaryBackground
secondaryColor
secondaryLightColor
secondaryDarkColor
secondaryBackgroundColor
successColor
successLight
successDark
successBackgroundColor
badgeColor
errorColor
errorLight
errorDark
errorBackgroundColor
warningColor
warningLight
warningDark
warningBackgroundColor
21 of 86 old variables shown Select a value to copy

OKLCH was integrated into the palette-generation process to create more predictable colour scales and maintain consistent lightness and contrast across themes.

Components and patterns

Before

Component debt

Components contained too many nested layers, overrides, and duplicated elements. Even simple edits required navigating complex internal structures, which slowed designers down and made components easy to break.

Structure

Property model

Button replaced separate component families with one property model for layout, appearance, state, and icon-only use. Optional icons remain part of the same component. The model works across themes and platforms.

Audit

Library reduction

Usage across product flows was audited, and overlapping or rarely used variants were removed. Four separate button families were consolidated into one Button component. Primary, Secondary, Tertiary, and Danger are now appearance values, while fill, hug, and icon-only layouts remain part of the same model.

Previous Figma button library split across raised, flat, icon, and link component families

Slots

Slots replaced deeply nested content layers. Teams can insert or replace content while the parent component retains spacing, alignment, states, and responsive behaviour.

Platform logic

iOS, Android, and Web share the same component anatomy and property model, while platform-specific behaviour is handled separately.

Figma slot structure showing a replaceable contract card placed inside a controlled mobile layout

Figma and code

Tokens

Shared naming

Figma variables and code tokens were aligned through the same naming model. Aliases and modes handle themes in design, while component properties follow the structure of production components.

Dev Mode

Code Connect

Code Connect links Figma components to their production implementations. Dev Mode shows real component code and maps properties such as variants, text, booleans, nested instances, and slots.

Documentation

Usage rules

Design and engineering review the same component structure, properties, behaviour, and implementation examples. Documentation focuses on usage rules and exceptions instead of repeating specifications for every screen.

Figma Code Connect view mapping a text field design component to its Flutter implementation

Migration and governance

Sequence

Layer by layer

Migration follows the redesign: foundations, core components, composed patterns, then product flows.

Deprecation

Without a forced switch

Legacy components remain during migration. Deprecations include replacement paths and planned removal, avoiding a forced switch.

Governance

Traceable releases

Every contribution started with a reuse check, followed by design and engineering review, documentation, and release. Figma branches isolated changes for review before they were merged into the main library. Versioning, release notes, and decision logs kept releases traceable.

Result

Several times faster

Designers could assemble complete product flows several times faster by reusing documented components and patterns instead of rebuilding common structures.

Fewer local decisions

Clear component roles, usage rules, and shared patterns reduced unnecessary invention. Teams made fewer one-off decisions, improving consistency across services.

Near-zero review issues

Shared component contracts and closer Figma-to-code alignment simplified implementation for developers. Design inconsistencies found during design review dropped to near zero.

Back to selected work