TWIN: Product Design and Design System from Scratch

In 2018, I joined the TWIN team to help the company move from a legacy interface to a modern product design foundation.
At that time, the product already had working functionality, but the interface was built on top of an outdated front-end and legacy constructor components. The system was difficult to scale, the visual language was inconsistent, and new product directions required a unified design approach.
My goal was not just to βredesign the interface,β but to build a scalable foundation for the platform: the user account, operator panel, bot script editor, chat widget, voice bot calling tasks, marketplace, and other product modules.
ββπ» My Role
I was responsible for building the product design almost from scratch: from the visual language and component system to prototypes, product libraries, and team documentation.
β
βMain areas of responsibility:
β
- Creating a branded design for the user account
- Building a system of components and styles.
- Prototyping key platform sections.
- Preparing a design system for product scaling.
- Creating a design token system for designers and developers.
- Documenting principles so the team could develop the product faster.

π¨ Visual System
I created a color system that helped the product feel consistent while remaining flexible for different interface states.
β
The palette was divided into several functional groups:
β
- contrast colors for key interface elements;
- accent colors for important actions;
- informational colors for statuses, notifications, and system messages.
β
The color system was designed to work not only in the main user account, but also across future product directions.
𧬠Component System

The interface was based on the atomic design approach: simple elements were combined into more complex components and product patterns.
β
The main goal was to help the team solve as many interface tasks as possible with a limited set of components. This accelerated development, preserved visual consistency, and reduced manual work in design files.
β
Components were designed not as isolated UI elements, but as parts of a larger system that could be reused across different sections of the platform.
β
π οΈ Design System Architecture

I structured the libraries using a βcore and product layersβ model.
β
The core contained the basic design system: styles, components, tokens, and shared rules. Product-specific libraries were built on top of it for separate platform areas: the user account, operator panel, bot script editor, chat widget, and other modules.
β
This approach allowed the product to scale without losing control. Changes in the core system were automatically reflected across connected design files, so the team did not have to manually update dozens of screens.
β
π§© Design Tokens

I developed a design token system that described colors, styles, typography, and other interface properties through clear semantic variables.
β
This made the design language easier to understand for both designers and developers. The team could understand the purpose of a style by reading the token name, without constantly checking documentation.
β
Tokenization also simplified interface maintenance and opened the way for future improvements: theme switching, dark mode, and user account customization for white label clients.
β
π Result
As a result, TWIN received a solid product design foundation: a visual system, component library, design tokens, and team documentation.
β
This system helped the team launch new product sections faster, maintain a consistent visual language, and reduce development dependency on constant designer involvement in routine interface tasks.
β
New designers and developers received clear rules for working with the interface, while the team was able to scale the user account and related product directions faster and more predictably.
β
At the time of writing, the TWIN user account remains an actively used product area, with 14.1k MAU, 5.03k WAU, and 1.48k DAU.
β

