Дизайн-система компании Атом
Период
Апрель 2024 - н.в.
Команда
Тимлид, продуктовый дизайнер
Роль
Продуктовый дизайнер
Скоуп
UI-библиотеки, паттерны, гайдлайны
О проекте
Компания-стартап, проектирует российский электромобиль и инфроструктуру к нему. В рамках этой работы развивается интерфейс автомобиля, AR-дисплей (Head Up Display), мобильное приложения водителя и пассажира, Saas-сервисы для каршеринга и технического обслуживания.
Задача
Спроектировать и запустить дизайн‑систему для 4х платформ, которая объединит разрозненные интерфейсы, ускорит выпуск фич и упростит поддержку продукта.
Контекст проблемы
К апрелю 2024 года разные команды использовали собственные UI‑паттерны и визуальные решения, что привело к использованию разных стилей и компонентов в похожих сценариях, долгому внедрению новых фич, сложностям с поддержкой.
Исходный аудит
Инвентаризация интерфейсов
Сбор ключевых экранов из разных продуктов. Классификация компонентов. Выявление дубликатов и вариаций.
Исследование
Какие компоненты реально используются? Где логика и визуал расходятся? Интервью с дизайнерами и разработчиками.
Инсайты
Многие компоненты были визуально похожи, но отличались по мелочам (отступы, состояния, шрифты), из‑за чего их нельзя было переиспользовать без доработок. Часть диджитал-компонентов визуально повторяли размер и формы физических компонентов автомобиля. Документация отсутствовала — знания были «в головах» отдельных людей.
Бенчмаркинг
Анализ существующих дизайн-систем, в том числе в сфере Avtomotive.
Формирование подхода и принципов
Молекулярность
Разделение на токены, компоненты, паттерны, шаблоны.
Единообразие
Одна система сеток, типографики, состояний и отступов для всех продуктов внутри одной платформы.
Совместное владение
Дизайн‑система как продукт, за который отвечает кросс‑функциональная команда (дизайн + разработка).
Фундамент
Типографика
Чистка и систематизация текстовых стилей.
Цвет
Сбор и чистка цвета, создание семантических ролей.
Сетка, ритм, радиусы
Создание системы шагов и отступов, формирование сеток на разных платформах. Стандартизация радиусов для различных элементов.
Иконографии
Разработка собственного стиля иконографии для всех платформ, соответствующего фирменному шрифту Atom Interphases. Отрисовка основоного пака иконок для интерфейса автомобиля.
Компоненты и паттерны
Введен единый нейминг и правила проектирования компонентов и состояний во всех библиотеках.
На основе спроектированных флоу собраны паттерны интерфейсов, «перенесены на бумагу».
Созданы принципы использования компонентов: когда использовать какую кнопку, какой паттерн, что использовать в тех или иных ситуациях. Best practices для типичных сценариев: фильтры и поиск, навигация между разделами, сложные формы;Примеры и анти‑паттерны: как делать не нужно;
На основе спроектированных флоу собраны паттерны интерфейсов, «перенесены на бумагу».
Созданы принципы использования компонентов: когда использовать какую кнопку, какой паттерн, что использовать в тех или иных ситуациях. Best practices для типичных сценариев: фильтры и поиск, навигация между разделами, сложные формы;Примеры и анти‑паттерны: как делать не нужно;
Взаимодействие с разработкой
Регулярные сессии с front‑end командой
Согласование API компонентов (props, состояния, ограничения). Тестирование компонентов через приложение-библиотеку;
Синхрон дизайн–код
Совместное ведение changelog’а. Внедрение Storybook Web интерфейсов как витрины компонентов для разработчиков и тестирования.
Внедрение в продукты
Из-за сжатых сроков библиотеки внедрялись массово, по мере сборки компонентов.
Разработаны и внедрены метрики покрытия интерфейсов компонентами, удовлетворённость продуктовых команд (CSI). Обновлены интерфейсы с использованием компонентов ДС и замерены эффекты: скорость разработки, количество багов, реакцию пользователей.
Поддержка
Проводились внутренние демо и воркшопы для продуктовых дизайнеров: Как подключать и переключать библиотеки; Как предлагать новые компоненты; Как не «ломать» систему локальными решениями.
Настроен процесс запросов изменений: дизайнеры могли предложить улучшения или новые компоненты через форму в Jira, а команда ДС приоритизировала их.
Настроен процесс запросов изменений: дизайнеры могли предложить улучшения или новые компоненты через форму в Jira, а команда ДС приоритизировала их.
Результаты
Количество визуальных расхождений между продуктами резко снизилось: новые интерфейсы стали выглядеть и работать единообразно.
Новые дизайнеры и разработчики быстрее проходят онбординг, так как им доступны понятные гайды и библиотеки.
Появился единый канал коммуникации по интерфейсам: вместо отдельных «частных» решений команды опирались на общую систему.
Новые дизайнеры и разработчики быстрее проходят онбординг, так как им доступны понятные гайды и библиотеки.
Появился единый канал коммуникации по интерфейсам: вместо отдельных «частных» решений команды опирались на общую систему.