В работе

• Роль: продуктовый дизайнер, владелец дизайн-системы (основной автор и человек, согласующий все изменения)
• Команда: 3 фронтенд-разработчика; бизнес-аналитики, участвующие в согласовании документации по компонентам; периодически — другие дизайнеры, предлагающие новые элементы
• Срок: постоянный процесс на протяжении всего времени в компании — система разрабатывалась и дорабатывалась непрерывно
• Платформа: Web, Mobile
• Макеты: Открыть в Figma ↗

Единая дизайн-система для tass.ru и других цифровых проектов экосистемы ТАСС — библиотека компонентов, токенов и правил их использования, построенная на атомарном подходе (атомы → молекулы → организмы).

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

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

• Универсальная сетка. После замены отдельных компонентов предложила создать единую модульную сетку для всех проектов ТАСС — она легла в основу дальнейшей вёрстки и избавила команду от сборки каждого проекта с нуля.

• Атомарный подход. Дизайн-система выстроена по методологии atomic design — атомы, молекулы, организмы — что позволяет собирать новые страницы и блоки из уже готовых, проверенных частей.

структура атомарного подхода

• Токены и темизация. Разработала цветовые токены и отдельные темы для разных проектов ТАСС, чтобы визуальный стиль можно было варьировать, не трогая структуру компонентов.

цветовые токены и темы для разных проектов

• Передача в разработку. Для каждого компонента разработчики получают три связанных источника: ссылку на сам компонент в Figma, ссылку на бизнес-требования и ссылку на документацию в Confluence. Документацию — описания возможностей и ограничений каждого компонента — вела лично я.

пример документации компонента в Confluence

• Постоянная синхронизация. Шёл этап согласования всех элементов одновременно на фронтенде, в бизнес-документации с аналитиками и в самой Figma, чтобы все три источника не расходились между собой.
• Ревью новых элементов. Другие дизайнеры периодически добавляли в систему новые элементы. Любое такое добавление предварительно согласовывалось со мной как с владельцем дизайн-системы и с фронтенд-разработчиками — некоторые элементы требовали сложной технической реализации, и это нужно было оценить до того, как компонент попадал в общую библиотеку.

• Если компонент нужно было доработать, дублировала его с пометкой rev-2 и вела доработку параллельно с действующей версией. После внедрения и тестирования старый компонент переносился в отдельный файл-архив (draft), а у нового убиралась пометка rev-2. Так в библиотеке всегда была только одна активная версия каждого компонента, а история изменений не терялась.
• Токены называются по схеме Категория / Роль / Состояние (в основном 3 уровня, изредка 4), категории — background, text, element, stroke (например, element/primary accent/default). Блоки называются по формуле [Modifier][BusinessEntity][Layout]Block — например, MaterialCarouselBlock: Material (бизнес-сущность) + Carousel (способ отображения) + Block. Модификатор (Accent, Main) добавляется, только если действительно нужен для различения. Такой нейминг остаётся устойчивым при расширении набора блоков и не требует переименования при появлении новых вариантов отображения.
• Прежде чем добавить новый компонент, сначала проверяли, нельзя ли закрыть задачу уже существующим. Если нет — компонент проходил проверку по чек-листу, который я разработала.

чек-лист приёмки нового компонента

• Базовый набор, который прорабатывался системно для всех компонентов: default / hover / active / disabled / focus visible. Для отдельных типов (например, FileUploader) набор состояний расширялся под их специфику.

• Библиотека компонентов выросла большой и легла в основу нескольких продуктов экосистемы ТАСС.
• Сборка новых страниц ускорилась: у дизайнеров это теперь занимает до 1 часа — почти под каждый тип страницы уже есть готовый шаблон.
• Дизайн-система уже используется в трёх продуктах из этого портфолио — «Редизайн tass.ru», «Сборка B2B-страниц из блоков», «Сервис Конфигуратор (CMS)» — общий фундамент виден на практике в разных проектах.