Больше обо мне
В этом кейсе
У компонентов не было единого источника
Что обнаружил
Компоненты находились минимум в трёх файлах Figma, их копировали без единого источника актуальных версий. Например, в одинаковых полях ввода отличался размер текста.
К чему это приводило
Разработчикам приходилось уточнять решения, интерфейсы расходились с макетами, а команда возвращалась к выполненной работе.
Как подтвердили проблему
- Второй дизайнер
- Обратная связь разработчиков
- Задачи в трекере
Первый шаг — лендинг
Я предложил обновить визуальный язык продукта одновременно с созданием дизайн-системы. Масштабное обновление требовало ресурсов команды, поэтому начал с лендинга: самостоятельно переработал его и представил решение бизнесу.
После запуска лендинга бизнес согласовал обновление продукта вместе с созданием дизайн-системы.
Начали с самых частых компонентов
Систему мы делали вдвоём, каждый отвечал за свою группу компонентов.
Первая версия
кнопки и поля ввода
Дальнейшее развитие — по мере продуктовых задач
уведомления, чекбоксы, переключатели
От цветовых значений к семантическим ролям
Я адаптировал существующий подход к семантическим токенам: роли — текст, фоны, границы, иконки, состояния — опираются на базовые палитры.
Light и Dark используют общую структуру токенов с разными значениями. Значения я подбирал и проверял на реальных экранах с учётом контраста, иерархии и состояний компонентов.
Повторяющийся паттерн — в компонент
Компонент в библиотеке
Применение в продукте
Паттерн объединённых кнопок повторялся в интерфейсах. Я собрал Button Group из существующих кнопок как вложенных экземпляров. Это позволило переиспользовать группу и централизованно изменять её оформление.
Что изменилось после внедрения
На основе дизайн-системы обновили веб и мобильное приложение. При проектировании Telegram Mini App повторно использовали компоненты библиотеки Figma.
Компоненты публиковали до передачи в разработку
- Новый компонент
- Проверка
- Публикация в библиотеке
- Передача в разработку
Я проверял подготовленные компоненты, согласовывал изменения и публиковал их до передачи утверждённых интерфейсов разработчикам.
Обратная связь команды
Разработчики отмечали меньше уточнений и расхождений с макетами, продакт-менеджер — более быстрое закрытие задач. Это качественные наблюдения.