Ikon Tyres. Международный портал производителя шин
Design System
B2B
RTL
Компания:
NDA
Роль:
Владелец дизайн-системы
Sorry, this page is currently available in Russian only. I'll translate it soon. 🙏
Проект включал разработку и внедрение дизайн-системы для группы продуктов: маркетплейса (web, iOS, Android), классифайда и медиа-сервиса, с необходимостью учитывать различия между платформами, но при этом выстроить консистентный пользовательский опыт.
Моя роль — владелец дизайн-системы: я инициировала проект, проводила исследование, выстраивала процессы и координировала работу дизайнеров и разработчиков.
Проблема
Продукт развивался долгое время без системного подхода, что привело к накоплению критических проблем:
- Любые изменения в интерфейсе занимали всё больше времени — рос Time to Market
- Интерфейс терял консистентность — снижалась предсказуемость для пользователя
- В макетах и коде накапливались кастомные артефакты — поддержка усложнялась
- Дизайнеры тратили большую часть времени на UI-рутину вместо работы над UX
При этом зачатки дизайн-системы уже существовали, но:
- Не было документации
- Макеты не соответствовали продакшену
- Коммуникация с разработкой была несистемной
В условиях роста продукта это стало ограничением для дальнейшего развития.
Ограничения
- Проект реализовывался в сложных условиях:
- Высокая нагрузка на команду параллельно продуктовой разработке
- Большое количество легаси-дизайна
- Ограничения существующего кода
- Часть ключевых решений в продукте была принята до запуска дизайн-системы
- В приложениях дизайн-система должна была учитывать особенности SDUI
- Всё это не позволяло сразу внедрять идеальные и масштабные решения, поэтому приходилось искать компромиссы.
Задачи и функции
Иницииация
Координация
Стратегия
Дизайн QA
Исследование
Наставничество
Создание гайдлайнов
UX/UI
Аналитика системы
Исследование
Я инициировала исследование, чтобы оценить масштаб проблемы и определить стратегию.
Что мы сделали:
- Провели опрос сотрудников (дизайнеры, разработчики, менеджеры)
- Провели ревизию компонентов и библиотек
- Собрали аналитику по использованию
- Проанализировали более 10 внешних дизайн-систем
- Оценили текущую скорость разработки и проектирования
- Проанализировали текущие экраны и страницы продуктов. Нам было важно понять, какие паттерны действительно используются в интерфейсах, какие решения повторяются, где накопились расхождения, а где одни и те же сущности визуально и структурно реализованы по‑разному. Такой подход позволил не строить систему в отрыве от реального продукта, а опираться на его текущие сценарии, ограничения и точки роста.
- Провели предварительную оценку проектирования и разработки новых компонентов
- Рассчитали потенциальную экономию от внедрения дизайн-системы
Результаты оформили в презентацию и защитили перед CEO, CPO и CTO.
Стратегия
Рассматривали два подхода: внедрение сторонней дизайн-системы и разработка собственной.
От готовых решений отказались по нескольким причинам:
- Сложный легаси-код и ресурсные ограничения не позволяли внедрять систему массово
- Частичная смена интерфейса совершенно новыми компонентами могла негативно повлиять на пользовательский опыт и восприятие продуктов
- Зависимость от сторонних обновлений не соответствовала внутренним требованиям
Выбрали постепенный переход:
- Сначала внедрить дизайн-систему, соответствующую текущему интерфейсу
- Затем использовать её как основу для дальнейшего плавного редизайна
Это позволило эволюционно обновлять продукт без резких скачков.
Подготовка и процессы
Первым шагом было выстраивание процессов. Я синхронизировалась с PM и разработкой, чтобы определить:
- Как компоненты доходят до продакшена
- Как встроить ДС в текущие бизнес-процессы
- Как поддерживать и обновлять систему
- Где хранить документацию
- Сколько мы можем выделить ресурса в каждой команде
- Как организовать тестирование
В результате:
- Получили процесс создания и изменения компонентов
- Создали эпик в Jira, связанный с Figma и документацией
- Определили приоритеты на основе продуктовых задач
Реализация
При создании компонентов и базовых элементов мы тщательно продумывали их применение в нашем продукте. Старались покрыть возможные сценарии и варианты применения на ближайший горизонт продуктовых задач, и при этом не сделать лишнего.
Во время работы мы скорректировали процесс и выработали общие правила, которые учитывали особенности кода и снижали количество итераций на один компонент.
Перед согласованием компонента и гайдлайна с разработчиками я проводила ревью по определённым заранее критериям и отправляла на доработку, если это было необходимо. Тщательная проверка позволила минимизировать ошибки на этапе delivery и очень сильно прокачала команду дизайнеров.
Семантика
Для нейминга в дизайн-системе мы приняли конструкцию, которая подходила под любой элемент. Это было нужно не только для наведения порядка в макетах, но и для того, чтобы сделать интерфейс более управляемым, подготовить его к дальнейшему развитию и упростить перенос решений в код.
Также, это помогло синхронизировать язык внутри команды, сделать структуру библиотеки более понятной и приблизить устройство компонентов в Figma к тому, как они воспринимаются и собираются в коде. За счёт этого дизайн переставал быть «визуальной версией интерфейса», существующей отдельно от разработки, и становился более прикладным инструментом.
Базовые элементы
Мы обеспечили плавный переход текущих применённых стилей на проде на новую систему токенов.
- Расширили палитру для большей вариативности и гибкости в дизайне и заложили добавление тёмной темы на будущее
- В типографике добавили размеры и начертания, которых не хватало в текущих стилях. Разделили шрифты на моды для десктопных и мобильных экранов
- Создали свой стиль иконок, который соответствует бренду
- Настроили систему отступов, радиусов и размеров
Компоненты и гайдлайны
Компоненты разделены на группы для облегчения нагрузки на оперативную память при использовании библиотек и для более гибкой работы. В каждой группе находится несколько компонентов. Есть как простые, так и имеющие свои составные элементы.
Поскольку система должна была работать сразу на несколько продуктов и платформ, важно было выстроить её так, чтобы она сохраняла общую логику, но при этом учитывала различия между web и мобильными приложениями. В мобильной среде часть компонентов строилась с опорой на нативные паттерны iOS и Android, поэтому задача заключалась не в буквальном копировании одного и того же решения, а в создании согласованной системы принципов.
Ещё один большой пласт работы — гайдлайны. Мы описывали не только внешний вид компонентов, но и правила их использования, ограничения, поведение в разных состояниях. При этом документацию старались делать одинаково структурированной и понятной для разных участников процесса, используя общепринятые в команде термины. Отдельно выносили комментарии для дизайнеров и для разработчиков, чтобы каждая сторона быстрее находила релевантную информацию и меньше тратила времени на уточнения.
Мы сформировали систему правил и обозначений. Свойства, состояния, структура компонента в Figma почти полностью давали представление о компоненте в коде. То, что нельзя показать компонентом, описывалось в гайдлайне.
Результат
За 8 месяцев:
~80%
компонентов были подготовлены командой из 3-х дизайнеров
~40%
компонентов были внедрены в продакшен
+30%
к скорости разработки на новых участках флоу
Качественные изменения:
- Улучшилась консистентность интерфейса
- Ускорилось создание новых фич
- Дизайнеры смогли сфокусироваться на UX вместо рутины
- Улучшилась коммуникация между дизайном и разработкой
- Команда лучше поняла ограничения и принципы работы друг друга
Выводы
Основной вызов проекта — синхронизация разных ролей и подходов: нужно было выстроить взаимодействие между дизайном и разработкой и изменить подход команды к работе с интерфейсом. На начальном этапе этот вызов казался незначительным, но в разгар работы это стало испытанием и для меня и для коллег. Мы нашли компромиссы и выработали общий взгляд на дизайн-систему и процессы связанные с ней. Огромная благодарность команде, которая с большой ответственностью и профессионализмом подошла к проекту!
Что можно сделать лучше
Смотря на проект сегодня, я понимаю, что с применением современных инструментов его можно реализовать гораздо быстрее. Так же я поняла, что реализация документации к компонентам в Figma удобна для дизайнеров, но требует значительного ресурса, поэтому сейчас ограничилась бы сторибуком.
Смотреть далее
Скоро будет
Экран товара в е-com. Увеличение конверсии.
App
Research
Дизайн-система для e‑com платформы
Компания:
NDA
Роль:
Владелец дизайн-системы
Sorry, this page is currently available in Russian only. I'll translate it soon. 🙏
Проект включал разработку и внедрение дизайн-системы для группы продуктов: маркетплейса (web, iOS, Android), классифайда и медиа-сервиса, с необходимостью учитывать различия между платформами, но при этом выстроить консистентный пользовательский опыт.
Моя роль — владелец дизайн-системы: я инициировала проект, проводила исследование, выстраивала процессы и координировала работу дизайнеров и разработчиков.
Проблема
Продукт развивался долгое время без системного подхода, что привело к накоплению критических проблем:
- Любые изменения в интерфейсе занимали всё больше времени — рос Time to Market
- Интерфейс терял консистентность — снижалась предсказуемость для пользователя
- В макетах и коде накапливались кастомные артефакты — поддержка усложнялась
- Дизайнеры тратили большую часть времени на UI-рутину вместо работы над UX
При этом зачатки дизайн-системы уже существовали, но:
- Не было документации
- Макеты не соответствовали продакшену
- Коммуникация с разработкой была несистемной
В условиях роста продукта это стало ограничением для дальнейшего развития.
Ограничения
- Проект реализовывался в сложных условиях:
- Высокая нагрузка на команду параллельно продуктовой разработке
- Большое количество легаси-дизайна
- Ограничения существующего кода
- Часть ключевых решений в продукте была принята до запуска дизайн-системы
- В приложениях дизайн-система должна была учитывать особенности SDUI
- Всё это не позволяло сразу внедрять идеальные и масштабные решения, поэтому приходилось искать компромиссы.
Задачи и функции
Иницииация
Координация
Стратегия
Дизайн QA
Исследование
Наставничество
Создание гайдлайнов
UX/UI
Аналитика системы
Исследование
Я инициировала исследование, чтобы оценить масштаб проблемы и определить стратегию.
Что мы сделали:
- Провели опрос сотрудников (дизайнеры, разработчики, менеджеры)
- Провели ревизию компонентов и библиотек
- Собрали аналитику по использованию
- Проанализировали более 10 внешних дизайн-систем
- Оценили текущую скорость разработки и проектирования
- Проанализировали текущие экраны и страницы продуктов. Нам было важно понять, какие паттерны действительно используются в интерфейсах, какие решения повторяются, где накопились расхождения, а где одни и те же сущности визуально и структурно реализованы по‑разному. Такой подход позволил не строить систему в отрыве от реального продукта, а опираться на его текущие сценарии, ограничения и точки роста.
- Провели предварительную оценку проектирования и разработки новых компонентов
- Рассчитали потенциальную экономию от внедрения дизайн-системы
Результаты оформили в презентацию и защитили перед CEO, CPO и CTO.
Стратегия
Рассматривали два подхода: внедрение сторонней дизайн-системы и разработка собственной.
От готовых решений отказались по нескольким причинам:
- Сложный легаси-код и ресурсные ограничения не позволяли внедрять систему массово
- Частичная смена интерфейса совершенно новыми компонентами могла негативно повлиять на пользовательский опыт и восприятие продуктов
- Зависимость от сторонних обновлений не соответствовала внутренним требованиям
Выбрали постепенный переход:
- Сначала внедрить дизайн-систему, соответствующую текущему интерфейсу
- Затем использовать её как основу для дальнейшего плавного редизайна
Это позволило эволюционно обновлять продукт без резких скачков.
Подготовка и процессы
Первым шагом было выстраивание процессов. Я синхронизировалась с PM и разработкой, чтобы определить:
- Как компоненты доходят до продакшена
- Как встроить ДС в текущие бизнес-процессы
- Как поддерживать и обновлять систему
- Где хранить документацию
- Сколько мы можем выделить ресурса в каждой команде
- Как организовать тестирование
В результате:
- Получили процесс создания и изменения компонентов
- Создали эпик в Jira, связанный с Figma и документацией
- Определили приоритеты на основе продуктовых задач
Реализация
При создании компонентов и базовых элементов мы тщательно продумывали их применение в нашем продукте. Старались покрыть возможные сценарии и варианты применения на ближайший горизонт продуктовых задач, и при этом не сделать лишнего.
Во время работы мы скорректировали процесс и выработали общие правила, которые учитывали особенности кода и снижали количество итераций на один компонент.
Перед согласованием компонента и гайдлайна с разработчиками я проводила ревью по определённым заранее критериям и отправляла на доработку, если это было необходимо. Тщательная проверка позволила минимизировать ошибки на этапе delivery и очень сильно прокачала команду дизайнеров.
Семантика
Для нейминга в дизайн-системе мы приняли конструкцию, которая подходила под любой элемент. Это было нужно не только для наведения порядка в макетах, но и для того, чтобы сделать интерфейс более управляемым, подготовить его к дальнейшему развитию и упростить перенос решений в код.
Также, это помогло синхронизировать язык внутри команды, сделать структуру библиотеки более понятной и приблизить устройство компонентов в Figma к тому, как они воспринимаются и собираются в коде. За счёт этого дизайн переставал быть «визуальной версией интерфейса», существующей отдельно от разработки, и становился более прикладным инструментом.
Базовые элементы
Мы обеспечили плавный переход текущих применённых стилей на проде на новую систему токенов.
- Расширили палитру для большей вариативности и гибкости в дизайне и заложили добавление тёмной темы на будущее
- В типографике добавили размеры и начертания, которых не хватало в текущих стилях. Разделили шрифты на моды для десктопных и мобильных экранов
- Создали свой стиль иконок, который соответствует бренду
- Настроили систему отступов, радиусов и размеров
Компоненты и гайдлайны
Компоненты разделены на группы для облегчения нагрузки на оперативную память при использовании библиотек и для более гибкой работы. В каждой группе находится несколько компонентов. Есть как простые, так и имеющие свои составные элементы.
Поскольку система должна была работать сразу на несколько продуктов и платформ, важно было выстроить её так, чтобы она сохраняла общую логику, но при этом учитывала различия между web и мобильными приложениями. В мобильной среде часть компонентов строилась с опорой на нативные паттерны iOS и Android, поэтому задача заключалась не в буквальном копировании одного и того же решения, а в создании согласованной системы принципов.
Ещё один большой пласт работы — гайдлайны. Мы описывали не только внешний вид компонентов, но и правила их использования, ограничения, поведение в разных состояниях. При этом документацию старались делать одинаково структурированной и понятной для разных участников процесса, используя общепринятые в команде термины. Отдельно выносили комментарии для дизайнеров и для разработчиков, чтобы каждая сторона быстрее находила релевантную информацию и меньше тратила времени на уточнения.
Мы сформировали систему правил и обозначений. Свойства, состояния, структура компонента в Figma почти полностью давали представление о компоненте в коде. То, что нельзя показать компонентом, описывалось в гайдлайне.
Результат
За 8 месяцев:
+30%
к скорости разработки на новых участках флоу
~80%
компонентов были подготовлены командой из 3-х дизайнеров
~40%
компонентов были внедрены в продакшен
Качественные изменения:
- Улучшилась консистентность интерфейса
- Ускорилось создание новых фич
- Дизайнеры смогли сфокусироваться на UX вместо рутины
- Улучшилась коммуникация между дизайном и разработкой
- Команда лучше поняла ограничения и принципы работы друг друга
Выводы
Основной вызов проекта — синхронизация разных ролей и подходов: нужно было выстроить взаимодействие между дизайном и разработкой и изменить подход команды к работе с интерфейсом. На начальном этапе этот вызов казался незначительным, но в разгар работы это стало испытанием и для меня и для коллег. Мы нашли компромиссы и выработали общий взгляд на дизайн-систему и процессы связанные с ней. Огромная благодарность команде, которая с большой ответственностью и профессионализмом подошла к проекту!
Что можно сделать лучше
Смотря на проект сегодня, я понимаю, что с применением современных инструментов его можно реализовать гораздо быстрее. Так же я поняла, что реализация документации к компонентам в Figma удобна для дизайнеров, но требует значительного ресурса, поэтому сейчас ограничилась бы сторибуком.
Смотреть далее
Ikon Tyres. Международный портал производителя шин
Design System
B2B
RTL
Скоро будет
Экран товара в е-com. Увеличение конверсии.
App
Research
Компания:
NDA
Роль:
Владелец дизайн-системы
Дизайн-система для e‑com платформы
Ограничения
Sorry, this page is currently available in Russian only. I'll translate it soon. 🙏
Проект включал разработку и внедрение дизайн-системы для группы продуктов: маркетплейса (web, iOS, Android), классифайда и медиа-сервиса, с необходимостью учитывать различия между платформами, но при этом выстроить консистентный пользовательский опыт.
Моя роль — владелец дизайн-системы: я инициировала проект, проводила исследование, выстраивала процессы и координировала работу дизайнеров и разработчиков.
Проблема
Продукт развивался долгое время без системного подхода, что привело к накоплению критических проблем:
- Любые изменения в интерфейсе занимали всё больше времени — рос Time to Market
- Интерфейс терял консистентность — снижалась предсказуемость для пользователя
- В макетах и коде накапливались кастомные артефакты — поддержка усложнялась
- Дизайнеры тратили большую часть времени на UI-рутину вместо работы над UX
При этом зачатки дизайн-системы уже существовали, но:
- Не было документации
- Макеты не соответствовали продакшену
- Коммуникация с разработкой была несистемной
В условиях роста продукта это стало ограничением для дальнейшего развития.
Ограничения
- Проект реализовывался в сложных условиях:
- Высокая нагрузка на команду параллельно продуктовой разработке
- Большое количество легаси-дизайна
- Ограничения существующего кода
- Часть ключевых решений в продукте была принята до запуска дизайн-системы
- В приложениях дизайн-система должна была учитывать особенности SDUI
- Всё это не позволяло сразу внедрять идеальные и масштабные решения, поэтому приходилось искать компромиссы.
Задачи и функции
Иницииация
Координация
Стратегия
Дизайн QA
Исследование
Наставничество
Создание гайдлайнов
UX/UI
Аналитика системы
Исследование
Я инициировала исследование, чтобы оценить масштаб проблемы и определить стратегию.
Что мы сделали:
- Провели опрос сотрудников (дизайнеры, разработчики, менеджеры)
- Провели ревизию компонентов и библиотек
- Собрали аналитику по использованию
- Проанализировали более 10 внешних дизайн-систем
- Оценили текущую скорость разработки и проектирования
- Проанализировали текущие экраны и страницы продуктов. Нам было важно понять, какие паттерны действительно используются в интерфейсах, какие решения повторяются, где накопились расхождения, а где одни и те же сущности визуально и структурно реализованы по‑разному. Такой подход позволил не строить систему в отрыве от реального продукта, а опираться на его текущие сценарии, ограничения и точки роста.
- Провели предварительную оценку проектирования и разработки новых компонентов
- Рассчитали потенциальную экономию от внедрения дизайн-системы
Результаты оформили в презентацию и защитили перед CEO, CPO и CTO.
Стратегия
Рассматривали два подхода: внедрение сторонней дизайн-системы и разработка собственной.
От готовых решений отказались по нескольким причинам:
- Сложный легаси-код и ресурсные ограничения не позволяли внедрять систему массово
- Частичная смена интерфейса совершенно новыми компонентами могла негативно повлиять на пользовательский опыт и восприятие продуктов
- Зависимость от сторонних обновлений не соответствовала внутренним требованиям
Выбрали постепенный переход:
- Сначала внедрить дизайн-систему, соответствующую текущему интерфейсу
- Затем использовать её как основу для дальнейшего плавного редизайна
Это позволило эволюционно обновлять продукт без резких скачков.
Подготовка и процессы
Первым шагом было выстраивание процессов. Я синхронизировалась с PM и разработкой, чтобы определить:
- Как компоненты доходят до продакшена
- Как встроить ДС в текущие бизнес-процессы
- Как поддерживать и обновлять систему
- Где хранить документацию
- Сколько мы можем выделить ресурса в каждой команде
- Как организовать тестирование
В результате:
- Получили процесс создания и изменения компонентов
- Создали эпик в Jira, связанный с Figma и документацией
- Определили приоритеты на основе продуктовых задач
Реализация
При создании компонентов и базовых элементов мы тщательно продумывали их применение в нашем продукте. Старались покрыть возможные сценарии и варианты применения на ближайший горизонт продуктовых задач, и при этом не сделать лишнего.
Во время работы мы скорректировали процесс и выработали общие правила, которые учитывали особенности кода и снижали количество итераций на один компонент.
Перед согласованием компонента и гайдлайна с разработчиками я проводила ревью по определённым заранее критериям и отправляла на доработку, если это было необходимо. Тщательная проверка позволила минимизировать ошибки на этапе delivery и очень сильно прокачала команду дизайнеров.
Семантика
Для нейминга в дизайн-системе мы приняли конструкцию, которая подходила под любой элемент. Это было нужно не только для наведения порядка в макетах, но и для того, чтобы сделать интерфейс более управляемым, подготовить его к дальнейшему развитию и упростить перенос решений в код.
Также, это помогло синхронизировать язык внутри команды, сделать структуру библиотеки более понятной и приблизить устройство компонентов в Figma к тому, как они воспринимаются и собираются в коде. За счёт этого дизайн переставал быть «визуальной версией интерфейса», существующей отдельно от разработки, и становился более прикладным инструментом.
Базовые элементы
Мы обеспечили плавный переход текущих применённых стилей на проде на новую систему токенов.
- Расширили палитру для большей вариативности и гибкости в дизайне и заложили добавление тёмной темы на будущее
- В типографике добавили размеры и начертания, которых не хватало в текущих стилях. Разделили шрифты на моды для десктопных и мобильных экранов
- Создали свой стиль иконок, который соответствует бренду
- Настроили систему отступов, радиусов и размеров
Компоненты и гайдлайны
Компоненты разделены на группы для облегчения нагрузки на оперативную память при использовании библиотек и для более гибкой работы. В каждой группе находится несколько компонентов. Есть как простые, так и имеющие свои составные элементы.
Поскольку система должна была работать сразу на несколько продуктов и платформ, важно было выстроить её так, чтобы она сохраняла общую логику, но при этом учитывала различия между web и мобильными приложениями. В мобильной среде часть компонентов строилась с опорой на нативные паттерны iOS и Android, поэтому задача заключалась не в буквальном копировании одного и того же решения, а в создании согласованной системы принципов.
Ещё один большой пласт работы — гайдлайны. Мы описывали не только внешний вид компонентов, но и правила их использования, ограничения, поведение в разных состояниях. При этом документацию старались делать одинаково структурированной и понятной для разных участников процесса, используя общепринятые в команде термины. Отдельно выносили комментарии для дизайнеров и для разработчиков, чтобы каждая сторона быстрее находила релевантную информацию и меньше тратила времени на уточнения.
Мы сформировали систему правил и обозначений. Свойства, состояния, структура компонента в Figma почти полностью давали представление о компоненте в коде. То, что нельзя показать компонентом, описывалось в гайдлайне.
Результат
За 8 месяцев:
+30%
к скорости разработки на новых участках флоу
~80%
компонентов были подготовлены командой из 3-х дизайнеров
~40%
компонентов были внедрены в продакшен
Качественные изменения:
- Улучшилась консистентность интерфейса
- Ускорилось создание новых фич
- Дизайнеры смогли сфокусироваться на UX вместо рутины
- Улучшилась коммуникация между дизайном и разработкой
- Команда лучше поняла ограничения и принципы работы друг друга
Выводы
Основной вызов проекта — синхронизация разных ролей и подходов: нужно было выстроить взаимодействие между дизайном и разработкой и изменить подход команды к работе с интерфейсом. На начальном этапе этот вызов казался незначительным, но в разгар работы это стало испытанием и для меня и для коллег. Мы нашли компромиссы и выработали общий взгляд на дизайн-систему и процессы связанные с ней. Огромная благодарность команде, которая с большой ответственностью и профессионализмом подошла к проекту!
Что можно сделать лучше
Смотря на проект сегодня, я понимаю, что с применением современных инструментов его можно реализовать гораздо быстрее. Так же я поняла, что реализация документации к компонентам в Figma удобна для дизайнеров, но требует значительного ресурса, поэтому сейчас ограничилась бы сторибуком.
Смотреть далее
Ikon Tyres. Международный портал производителя шин
Design System
B2B
RTL
Скоро будет
Экран товара в е-com. Увеличение конверсии.
App
Research
Компания:
NDA
Роль:
Владелец дизайн-системы
Дизайн-система для e‑com платформы
Ограничения
Sorry, this page is currently available in Russian only. I'll translate it soon. 🙏
Проект включал разработку и внедрение дизайн-системы для группы продуктов: маркетплейса (web, iOS, Android), классифайда и медиа-сервиса, с необходимостью учитывать различия между платформами, но при этом выстроить консистентный пользовательский опыт.
Моя роль — владелец дизайн-системы: я инициировала проект, проводила исследование, выстраивала процессы и координировала работу дизайнеров и разработчиков.
Проблема
Продукт развивался долгое время без системного подхода, что привело к накоплению критических проблем:
- Любые изменения в интерфейсе занимали всё больше времени — рос Time to Market
- Интерфейс терял консистентность — снижалась предсказуемость для пользователя
- В макетах и коде накапливались кастомные артефакты — поддержка усложнялась
- Дизайнеры тратили большую часть времени на UI-рутину вместо работы над UX
При этом зачатки дизайн-системы уже существовали, но:
- Не было документации
- Макеты не соответствовали продакшену
- Коммуникация с разработкой была несистемной
В условиях роста продукта это стало ограничением для дальнейшего развития.
Ограничения
Проект реализовывался в сложных условиях:
- Высокая нагрузка на команду параллельно продуктовой разработке
- Большое количество легаси-дизайна
- Ограничения существующего кода
- Часть ключевых решений в продукте была принята до запуска дизайн-системы
- В приложениях дизайн-система должна была учитывать особенности SDUI
Всё это не позволяло сразу внедрять идеальные и масштабные решения, поэтому приходилось искать компромиссы.
Задачи и функции
Иницииация
Координация
Стратегия
Дизайн QA
Исследование
Наставничество
Создание гайдлайнов
UX/UI
Аналитика системы
Исследование
Я инициировала исследование, чтобы оценить масштаб проблемы и определить стратегию.
Что мы сделали:
- Провели опрос сотрудников (дизайнеры, разработчики, менеджеры)
- Провели ревизию компонентов и библиотек
- Собрали аналитику по использованию
- Проанализировали более 10 внешних дизайн-систем
- Оценили текущую скорость разработки и проектирования
- Проанализировали текущие экраны и страницы продуктов. Нам было важно понять, какие паттерны действительно используются в интерфейсах, какие решения повторяются, где накопились расхождения, а где одни и те же сущности визуально и структурно реализованы по‑разному. Такой подход позволил не строить систему в отрыве от реального продукта, а опираться на его текущие сценарии, ограничения и точки роста.
- Провели предварительную оценку проектирования и разработки новых компонентов
- Рассчитали потенциальную экономию от внедрения дизайн-системы
Результаты оформили в презентацию и защитили перед CEO, CPO и CTO.
Стратегия
Рассматривали два подхода: внедрение сторонней дизайн-системы и разработка собственной.
От готовых решений отказались по нескольким причинам:
- Сложный легаси-код и ресурсные ограничения не позволяли внедрять систему массово
- Частичная смена интерфейса совершенно новыми компонентами могла негативно повлиять на пользовательский опыт и восприятие продуктов
- Зависимость от сторонних обновлений не соответствовала внутренним требованиям
Выбрали постепенный переход:
- Сначала внедрить дизайн-систему, соответствующую текущему интерфейсу
- Затем использовать её как основу для дальнейшего плавного редизайна
Это позволило эволюционно обновлять продукт без резких скачков.
Подготовка и процессы
Первым шагом было выстраивание процессов. Я синхронизировалась с PM и разработкой, чтобы определить:
- Как компоненты доходят до продакшена
- Как встроить ДС в текущие бизнес-процессы
- Как поддерживать и обновлять систему
- Где хранить документацию
- Сколько мы можем выделить ресурса в каждой команде
- Как организовать тестирование
В результате:
- Получили процесс создания и изменения компонентов
- Создали эпик в Jira, связанный с Figma и документацией
- Определили приоритеты на основе продуктовых задач
Реализация
При создании компонентов и базовых элементов мы тщательно продумывали их применение в нашем продукте. Старались покрыть возможные сценарии и варианты применения на ближайший горизонт продуктовых задач, и при этом не сделать лишнего.
Во время работы мы скорректировали процесс и выработали общие правила, которые учитывали особенности кода и снижали количество итераций на один компонент.
Перед согласованием компонента и гайдлайна с разработчиками я проводила ревью по определённым заранее критериям и отправляла на доработку, если это было необходимо. Тщательная проверка позволила минимизировать ошибки на этапе delivery и очень сильно прокачала команду дизайнеров.
Семантика
Для нейминга в дизайн-системе мы приняли конструкцию, которая подходила под любой элемент. Это было нужно не только для наведения порядка в макетах, но и для того, чтобы сделать интерфейс более управляемым, подготовить его к дальнейшему развитию и упростить перенос решений в код.
Также, это помогло синхронизировать язык внутри команды, сделать структуру библиотеки более понятной и приблизить устройство компонентов в Figma к тому, как они воспринимаются и собираются в коде. За счёт этого дизайн переставал быть «визуальной версией интерфейса», существующей отдельно от разработки, и становился более прикладным инструментом.
Базовые элементы
Мы обеспечили плавный переход текущих применённых стилей на проде на новую систему токенов.
- Расширили палитру для большей вариативности и гибкости в дизайне и заложили добавление тёмной темы на будущее
- В типографике добавили размеры и начертания, которых не хватало в текущих стилях. Разделили шрифты на моды для десктопных и мобильных экранов
- Создали свой стиль иконок, который соответствует бренду
- Настроили систему отступов, радиусов и размеров
Компоненты и гайдлайны
Компоненты разделены на группы для облегчения нагрузки на оперативную память при использовании библиотек и для более гибкой работы. В каждой группе находится несколько компонентов. Есть как простые, так и имеющие свои составные элементы.
Поскольку система должна была работать сразу на несколько продуктов и платформ, важно было выстроить её так, чтобы она сохраняла общую логику, но при этом учитывала различия между web и мобильными приложениями. В мобильной среде часть компонентов строилась с опорой на нативные паттерны iOS и Android, поэтому задача заключалась не в буквальном копировании одного и того же решения, а в создании согласованной системы принципов.
Ещё один большой пласт работы — гайдлайны. Мы описывали не только внешний вид компонентов, но и правила их использования, ограничения, поведение в разных состояниях. При этом документацию старались делать одинаково структурированной и понятной для разных участников процесса, используя общепринятые в команде термины. Отдельно выносили комментарии для дизайнеров и для разработчиков, чтобы каждая сторона быстрее находила релевантную информацию и меньше тратила времени на уточнения.
Мы сформировали систему правил и обозначений. Свойства, состояния, структура компонента в Figma почти полностью давали представление о компоненте в коде. То, что нельзя показать компонентом, описывалось в гайдлайне.
Результат
За 8 месяцев:
+30%
к скорости разработки на новых участках флоу
~80%
компонентов были подготовлены командой из 3-х дизайнеров
~40%
компонентов были внедрены в продакшен
Качественные изменения:
- Улучшилась консистентность интерфейса
- Ускорилось создание новых фич
- Дизайнеры смогли сфокусироваться на UX вместо рутины
- Улучшилась коммуникация между дизайном и разработкой
- Команда лучше поняла ограничения и принципы работы друг друга
Выводы
Основной вызов проекта — синхронизация разных ролей и подходов: нужно было выстроить взаимодействие между дизайном и разработкой и изменить подход команды к работе с интерфейсом. На начальном этапе этот вызов казался незначительным, но в разгар работы это стало испытанием и для меня и для коллег. Мы нашли компромиссы и выработали общий взгляд на дизайн-систему и процессы связанные с ней. Огромная благодарность команде, которая с большой ответственностью и профессионализмом подошла к проекту!
Что можно сделать лучше
Смотря на проект сегодня, я понимаю, что с применением современных инструментов его можно реализовать гораздо быстрее. Так же я поняла, что реализация документации к компонентам в Figma удобна для дизайнеров, но требует значительного ресурса, поэтому сейчас ограничилась бы сторибуком.
Смотреть далее
Ikon Tyres. Международный портал производителя шин
Design System
B2B
RTL
Скоро будет
Экран товара в е-com. Увеличение конверсии.
App
Research