Простой

12 мин

1

Привет! Меня зовут Рома. С 2023 года я отвечаю за технику и архитектуру дизайн-системы в Туту, а с 2025 — возглавляю саму команду. 

За это время я понял: дизайн-система — это сложный и местами болезненный компромисс между кодом, дизайном и бизнесом. Написать гибкие компоненты и собрать UI-кит — лишь 20% успеха. Остальные 80% — это долгие детальные переговоры и поиск точек соприкосновения. Продуктовые команды тоже хотят делать качественный продукт, но их главный ресурс — время.

В этой статье я расскажу про наш нетривиальный путь: как мы от проектирования архитектуры компонентов пришли к договору о базовых правилах игры и сделали так, чтобы дизайн-система действительно помогала командам ехать быстрее, а не воспринималась как обуза.

Тут небольшое ЧаВо для тех, кто не очень погружён в мир дизайн-систем. (все зеленое под кат)

Что такое дизайн-система

Дизайн-система — единая система из дизайнерско-технических решений, которая позволяет создавать, изменять внешний вид и базовую функциональность: поведение, анимацию приложений за счет набора стандартов, правил и связанных зависимостей.

Основная цель дизайн-системы — сделать так, чтобы разделенные команды одной компании создавали единые с точки зрения стилистики решения в своих продуктах и делали UX бесшовным.

Второстепенная, но также важная цель — снижать стоимость на воспроизведение и сопровождение элементов дизайн-системы.

Кому нужна дизайн-система

Компаниям, где есть 1+n продуктов и продуктовых команд, у которых должен быть общий UI/UX — дизайн система необходима, а вот небольшим компаниям/командам, где все UI/UX решения решаются и имплементируются небольшой группой человек она точно без надобности.

Таким командам отлично подойдет обычный UI-kit в разработке и его несвязанное отображение в компонентах Фигмы.

Какие бывают дизайн-системы

Дизайн-системы, как правило бывают двух типов:

1. Общего назначения — такие как Ant Design или Material Design, они универсальны и нацелены на широкую группу потребителей.

2. Специализированные — дизайн-системы, которые создаются внутри организаций для использования исключительно в рамках этой организации. Все фичи опираются на потребности узкой группы потребителей.

Какая дизайн-система подойдёт именно вам

Я выявил достаточно точные принципы, которые позволят определиться с выбором дизайн-системы. 

Дизайн-системы общего назначения:

1) Вы делаете MVP и вам важна скорость. Потом можно хоть целиком переделать проект.

2) Вы делаете админку и внешний вид и единообразие не ваши основные критерии/метрики.

3) Вам нормально зависеть от опенсорс-решения, когда развитие, поддержка и/или доступность могут свернуться.

4) Не планируете делать какие-то уникальные штуки, что-либо переделывать под капотом.

Специализированные дизайн-системы:

1) Продуктовые решения в вашей компании должны быть единообразны.

2) Интеграция и развитие планируется на годы вперёд.

3) Нужны универсальные фичи и подходы, которые из коробки не дают остальные ДС.

4) Нужно иметь возможность дорабатывать и переделывать любые части ДС.

5) Вам важно контролировать вашу дизайн-систему как продукт — не зависеть от внешних разработчиков/компаний/коммьюнити.

Опыт в Туту: от UI-китов к Design driven системе Kite

В 2023 году когда я пришел в компанию, повсеместно использовался свой UI-kit под названием Order (Порядок, но ниже буду называть его Ордер) с такими особенностями:

1. Большая степень легковесности — в наборе были только самые атомарные штуки из которых команды собирали то, что им нужно.

2. Dev-to-Design подход — разработчики «кодят визуал», а дизайнеры впоследствии обогащают свой эквивалент Ордера в Фигме.

3. На каждой платформе web/ios/android свой Ордер, своя структура и нет никакой связанности между ними.

Так как связанности с дизайном фактически не было — не было общей системы токенов — о быстром редизайне или масштабной правке визуала общих компонентов не могло идти и речи. 

Это была большая боль.

Как мы оказались в точке Dev-to-design и зачем развернулись на 180 градусов

Когда стало понятно, что без связанности с дизайном работать очень сложно, было решено собрать отдельную команду Дизайн-системы. Я, как техлид, присоединился к  команде в 2023 году и мы с руководителем сразу же поняли: нужно описать процесс как новая дизайн-система будет выстраиваться, какие будут принципы зависимостей, кто и что, и кому будет диктовать изменения.

Так возникла идея сменить подход с Dev-to-Design на Design-to-Dev — когда основная работа по исследованию и «обстукиванию» будущих компонентов, доработке актуальных ложится на плечи дизайнеров дизайн-системы и продуктовых дизайнеров.

В Туту сильная дизайн-гильдия, которая объединяет под собой все продукты. Именно поэтому у нас была возможность быстро формировать видение будущих компонентов общего назначения: кнопки, тексты, панели, чтобы сделать их подходящими для всех.

Мы и по сей день продолжаем эту практику с компонентами дизайн-системы, которые зачастую рассчитаны только на определенную группу продуктов.

Так мы пришли к нашей нынешней дизайне-системе — Кайт.

Его мото гласит «Легкий, Динамичный, Контролируемый» — эти характеристики мы заложили в нашу дизайн-систему, когда определяли ее будущую философию.

С какими сложностями в майндсете столкнулись

Сложности для дизайнеров:

• Сложно въехать как использовать компоненты. Дизайнерам всегда хочется кастомности, возможности показать «свой почерк».

• Хочется любые хексы, а не ограничения в виде списка переменных.

• Не хочется зависеть от поставок команды дизайн-системы — продакт требует сделать макет уже вчера.

• Хочется системы, но в то же время свободы.

Сложности для разработчиков:

• Хочется максимально атомарных вещей без сложных конструкций.

• Хочется, чтобы ВСЁ можно было переопределять под свой вкус.

• Хочется лёгкую миграцию на новый кит.

• Хочется, чтобы было легко и понятно использовать кит.

Разумеется, тут надо вообще вспомнить, зачем дизайн-система нужна, ведь её основная бизнес-задача — принести единообразие продуктов и ускорить общую разработку продуктовых решений. Вот от этой задачи и нужно отталкиваться.

И уже только ПОСЛЕ рассматривать ожидания и желания дизайнеров и разработчиков. В этом моменте как раз и происходили основные коллизии. 

Дело в том, что дизайн-система — это не набор чисто технических решений, а сложный элемент широкой системы, на базе которой собираются продукты, а потому лёгкого порога входа как в универсальных дизайн-системах вроде Bootstrap/AntDesign ждать не стоит. 

Тут всё-таки организационно-специфическая система. В ней не должно быть, кроме атомарных, простых компонентов без определенной системы настроек, в которых даже школьник сходу разберется. Она на порядок сложнее — мы ускоряем создание комплексных систем и продуктов.

The tech part: что под капотом у системы

Самое интересное кроется как раз в этой части «Из чего же состоит дизайн-система корпоративного уровня» вроде Кайта.

Система токенов как сердце дизайн-системы

Токены как абстракция уже давно используется и дизайнерами, и разработчиками в разных компаниях. Дизайн-система не исключение. В основе всего лежит закрытая от потребителя логика связей между неймингом и значением.

Мы выстроили глубокую систему токенизации:

• Базовая, скрытая для внешнего использования, система палеточных (цветовых) токенов.

• Система базовых публичных токенов: сайзинги, отступы, семантические цвета.

• Система компонентных токенов (Публичные токены — доступные к использованию потребителями дизайн-системы: разработчики, дизайнеры. В отличие приватных токенов, это токены конкретных цветов которые нельзя напрямую использовать потребителям).

• Система токенов по типу QoL — последовательно связанные токены контрастности.

Последний тип токенов особенно полезен, потому что позволяет дизайнерам и разработчикам не переживать о таких вещах как контрастность текста на белой или серой подложке с точки зрения Web Vitals — мы уже всё замерили и настроили для разных случаев.

Style Dictionary или самописное решение

После определения структуры токенов возникает резонный вопрос: «как и чем мы будем собирать и преобразовывать токены в готовое решение под платформы?». В целях быстрого запуска MVP на старте проекта был выбран готовый сборщик Style Dictionary. Он с небольшим количеством настроек позволял обрабатывать простые структуры токенов в те самые нужные платформенные решения.

Когда я ознакомился с состоянием структуры токенов и возможностями работы этого сборщика, то сделал следующие положительные выводы:

1. SD хорош для простых и типовых решений без перегрузок по внутренней логике у токенов.

2. Он может быстро показать рабочую систему, чтобы проект можно было двигать дальше и не стопориться — так что SD вполне пригоден.

3. Если команда небольшая и нет возможности поддерживать свое гибкое решение — SD подойдет до поры до времени.

Но наша дизайн-система Кайт планировалась масштабная и со своими хитрыми особенностями обработки ряда случаев, поэтому стали очевидны и минусы SD:

1. С любыми нетиповыми преобразованиями нужно идти с issue/PR в сообщество, а это не быстро.

2. Сложно масштабировать.

3. Не гибко и не управляемо — нельзя под себя сделать какую-то встройку посреди процесса сборки, сообщество может не понять и не одобрить.

В этот момент приходит понимание — нужно делать свое гибкое решение, которое будет отвечать техническим и бизнес-требованиям в любой момент.

CSS Vars или CSS-in-JS

В вебе UI-kit Order исторически базировался в своей стилизации на SASS-переменных — это было продиктовано SEO-first, когда веб-приложение отрисовывается нулевым или минимальным вмешательством JS. 

При разработке Кайта мы продолжили двигаться в том же направлении, но сместили акцент на CSS Vars как на более нативное современное решение, которое к тому же отлично работает с мультитемизацией и различными скоупами и условиями.

Если бы SEO не был бы нашим ключевым фактором, скорее всего любое CSS-in-JS решение было бы предпочтительнее, поскольку такой подход позволяет влиять на результат рендера в зависимости от контекста. 

Mother-of-tokens: генерируем готовое API под платформенные UI-киты

В нашей дизайн системе Mother-of-tokens это и репозиторий с токенами, и сущность — не только источник знаний для потребителей дизайн-системы Кайт, но ещё она определяет как будут генерироваться и в каком виде будет отправляться токенизированные значения в платформы.

С точки зрения кодогенерации — это набор готовых, разбитых на модули расширяемых скриптов, которые позволяют собирать как несколько бандлов под нужные платформы, так и индивидуальные артефакты.

Схематический пример модулей сборки

Мы собираем бандлы для Web/Android/iOS, а также отдельный набор для MailKit. Такой подход с самописными модулями позволяет изменять части, которые влияют на общие элементы сборки и в то же время дают возможность тонко настраивать правки для конкретных платформ.

И есть ещё один важный плюс, который позволяет такому подходу буквально сиять — о нём дальше.

White-label readiness: как мы с помощью прокси сделали возможным мультибандлы

В начале 2025 года на уровне компании появилась цель: разработать интеграцию наших продуктовых решений с партнёрами, когда решения наши, а визуал соответствует стилистике партнёра.

Дизайн-система Кайт была одним из ключевых элементов на пути к успеху подобной задачи, потому что иначе объём работ каждой продуктовой команды увеличивался бы кратно.

Благодаря принятым нашей командой решениям, как: 

• собственной гибкой системе генерации токенов;

• доработкам в виде системы проксирования значений под различные окружения, которые были созданы дизайнерами и разработчиками;

нам удалось в кратчайшие сроки преобразовать генерацию в возможность создавать рядом white-label бандл, с частичной или полной заменой токенов и их соотношений для неограниченного количества white-label решений.

Микропример системы проксирования

Именно поэтому дизайн-система стала бустером продуктовых команд, а не блокировщиком процессов.

Куда развивать дизайн-систему

Как и любая система, дизайн-система Кайт в определенный момент достигает состояния устойчивости: когда все самое необходимое в ней уже создано, система внедрена или внедряется в продукты и основным фокусом становится саппорт и доработки. 

В этот момент стоит задуматься куда двигаться дальше в развитии дизайн-системы.

Паттерны и анимации

Схема дизайн-паттернов и анимаций

Дизайн-паттерны — комбинации наиболее часто встречающихся между собой сочетаний компонентов и вариаций их объединения. Это огромный пласт работы дизайнеров дизайн-системы с дизайн-гильдией компании. Такие паттерны специфичны для каждой организации, поэтому каждый их определяет для себя сам.

Анимации — wow-дизайн и всевозможные адекватные попытки добавления интерактивности создают приятную атмосферу для пользователей продуктов, повышают Retention и прочие клиентские метрики, увеличивая тем самым конечную прибыль. Это как и в случае с паттернами достаточно специфичная и важная область пост-развития дизайн-системы.

Документации и примеры

Хорошая документация значит: больше лояльных пользователей дизайн-системы, быстрее скорость разработки, меньше обсуждений с командой дизайн-системы на тему «а как что-то работает». 

Регулярное обновление документации как дизайнерской, так и разработческой — это must-have практика любой команды дизайн-системы. В эпоху стремительного развития ИИ это стало делать еще проще — вам остается контролировать/валидировать результат, а само написание можно по сути делегировать машине. 

Я считаю, это помогает побороть лень. ИИ отлично решает проблему нехватки времени: когда спринт заполнен, но объемную документацию писать нужно.

Пример с документацией утилит

Помощь командам с внедрением

Внедрение любой дизайн-системы, а также замена одной на другую — процесс трудоёмкий и долгий. Наверняка у многих есть задачи, связанные с переводом чего-то на новые рельсы и визуальным улучшениям, которые относятся к задачам типа «Техдолг» и чаще всего они пылятся на дне беклога с невысоким приоритетом.

Именно в этот момент разработчики дизайн-системы могут взять на себя эти «второстепенные» для продуктовой команды задачи на внедрение компонентов дизайн-системы в экранах пользовательского флоу. А в это время продуктовые разработчики могут сфокусироваться на приоритетных бизнесовых задачах.

Именно так мы и сделали в нашей команде, когда основные компоненты и доработки были сделаны, а ресурс разработчиков начал высвобождаться — мы использовали таскшеринг, договаривались с продуктовыми командами, какие задачи у них можно забрать себе, которые решали частично бизнес-задачи, но по большей части вели к смене визуала со старых компонентов на новые. 

Как итог, от такого подхода начали выигрывать все:

1. Бизнес по ряду направлений начал получать больше фич за то же время, при этом стало ускоренно повышаться единообразие всего продукта.

2. Команды получили возможность закрывать больше важных фичей.

3. Мы как команда смогли нивелировать скорость накопления беклога задачами от дизайна к разработчикам за счёт привлечения сторонних смежных задач.

Улучшения + редизайн

Возникает резонный вопрос: вот мы все переделали, что же делать дальше?

А дальше мы переходим к бесконечному анализу того, что уже сделано в продуктах, улучшаем, смотрим по сторонам и в чужие дизайн-системы, вдохновляемся и пробуем внедрить, экспериментируем. 

Ну и вишенка на торте — бизнес обязательно придет с редизайном раз в пару лет! И хотя наша дизайн-система Кайт уже готова к подобным изменениям, это эпизодическое мероприятие так или иначе все равно потребует ресурсов.

Разумно применять ИИ

С каждым днем ИИ-инструменты все больше и больше развиваются и позволяют улучшать, убыстрять и автоматизировать всю вышеперечисленную работу: от автоматизации сборок до автодокументации и уведомлении команд об изменениях в дизайн системе. Например, автоматизированный сбор ченджлогов + отправка в специальные каналы/чаты/системы документирования.

Дизайн-система должна стремиться стать максимально автоматизированной в части связи внутренних элементов. Например, источником токенов, системой генерации и доставки платформенных решений (UI-китов), системой документации, системой оповещения (ченджлоги) и тд. 

Это означает, что изменение токена в компоненте должно влечь за собой автопересборку платформенного решения, разумеется, с валидацией на собираемость, и документацию — так мы высвобождаем время разработчиков на решение более комплексных задач, а незначительное изменение способен «раскатить» дизайнер самостоятельно.

Важное направление — подготовка А2А-решения (Agent-to-Agent), когда и дизайнер, и разработчик способны создавать такие решения на базе ИИ + ДС, которые могут быть интерпретированы и сохранены в другой платформе. 

Например, разработчик накодил, а в макете синхронизировались изменения и наоборот. Сейчас, при работе с Figma отличным решением может стать Figma Code Connect — прослойка, которая не только позволяет получать готовый код платформенного компонента из дизайна — можно не пытаться больше интерпретировать пропсы, — но и дает возможность ИИ считывать макет и переносить его в код в точности «слой за слоем» из Фигмы. 

Подобные изменения мы активно внедряем в Туту и это уже начинает давать свои плоды: увеличилась скорость доставки фич в продуктовых командах (ТТМ).

Выводы

Вот мы и подобрались к финалу.

Дизайн-система — это ускоритель компании

По минимальным оценкам различных экспертов ускорение для бизнеса от наличия общей дизайн системы составляет порядка 25-30% относительно отсутствия таковой. Считается, что это достигается за счёт того, что условная кнопка будет разработана один раз и в одной команде, а не своя в каждой. 

Но это значение скорее отражает среднее значение на дистанции, потому что в начале показатели могут проседать, ведь вы только разрабатываете дизайн-систему, привлекаете разработчиков и дизайнеров команд к обсуждению. 

Но дальше с ходом интеграции как кода и дизайна, так и знаний показатель может сильно превышать эти значения. Так что если компания планирует «играть в долгую», то дизайн-система — это обязательный элемент технической системы.

Сложно вначале. Кайфово в движении

В здоровой ситуации, где все собрались создать дизайн-систему, которая принесет как бизнес-эффекты, так и технические облегчения/улучшения в начале наверняка будет душно! 

Будут собираться бесконечные созвоны-грумминги, созвоны-обсуждения и прочие баталии на тему того, как и что должно быть устроено. Это абсолютно нормально, это значит, что участникам, в том числе и гильдиям дизайна и разработки не все равно.

А вот как только вы стартанули, разработали атомарные компоненты, описали какую-никакую документацию и начали внедрять — все те, кто душнили и участвовали начнут быть вашими лучшими помощниками, ведь их ценные замечания и багрепорты будут вам день ото дня помогать делать дизайн-систему лучше.

Важно держать баланс строгости/гибкости

Строгость позволяет избегать разночтений и лишних рассуждений: красный или синий, а может быть бордовый? Нет! Есть primary/secondary/tertiary — дизайнер выбирает кнопку по смысловому назначению относительно самого контекста/экрана, в котором он работает, а у разработчика есть тот же эквивалент в коде и он не тратит время, а просто переносит пропсы и фокусируется на более сложных задачах.

Но все под жесткие ворота ограничений не подогнать. Слоты — это тот пример реализации части вашего компонента, когда вы доподлинно можете не знать, с чем ваш компонент будет работать, например, компонент Panel.

Важно всегда задаваться вопросом во время дизайна/разработки компонента дизайн-системы относительно применимости одного из этих двух подходов.

Можно развивать дизайн-систему на внешние проекты

Как только ваша дизайн-система встала на ноги — появляется возможность применять ее во вне: как отдельно, так и в составе готовых бизнес-решений. 

Это отличная бизнес-возможность и причина завести дизайн-систему. Для самой же команды это означает как правило долгую и безбедную на задачи жизнь.

Успешных запусков ваших воздушных змеев!