Меня зовут Неля Васенина, я продуктовый дизайнер в IT-команде «Северстали» — одной из ведущих металлургических компаний мира, в которой работают 3000+ айтишников. Мы разрабатываем инновационные продукты, от VR-очков для обучения рабочих до сложнейших CRM-систем для аналитиков в тяжёлой промышленности.
В августе 2024 года две наши команды дизайнеров столкнулись с последствиями отсутствия единой дизайн-системы для проектной разработки. Для большинства продуктов она была, но для специфических проектов её не существовало. Мы использовали похожие компоненты, подсматривая друг у друга, что приводило к несоответствиям и задержкам. В итоге мы выделили три месяца на сбор всех компонентов и создание системы, подходящей для всех наших проектов.
В этой статье расскажу, какие именно проблемы были, как мы их идентифицировали,с какими трудностями столкнулись и что решили делать.
В следующей статье поделюсь нашим опытом решения проблем с дизайн-системой, расскажу о разработанных принципах ведения макетов компонентов и подарю ссылку на шаблоны компонентов в Figma (на английском).
Навигация для тех, кто хочет сразу к делу:
Что было ДО пересборки дизайн-системы.
Начало пути: какие проблемы мы идентифицировали.
Середина пути: с какими трудностями мы столкнулись при разработке.
Конец пути: готовый план, как за три месяца собрать дизайн-систему для 10+ продуктов
Если вы разрабатываете несколько продуктов и строите дизайн-систему, наш опыт в решении проблем и преодолении сложностей может помочь выявить похожие точки роста в ваших проектах.
Что было ДО пересборки дизайн-системы
До момента, когда мы осознали необходимость пересборки дизайн-системы, работа с компонентами напоминала катарсис, замаскированный под порядок. Каждый дизайнер, а у нас их 14, создавал решения в моменте, ориентируясь на задачи конкретного проекта. Иногда мы копировали компоненты из других продуктов, иногда придумывали их с нуля. Это правда работало… пока количество задач и продуктов не достигло критической массы…
Иногда очень больно посмотреть правде в глаза и сказать: да, так больше не работает, давайте по-другому.
Начало пути: какие проблемы мы нашли
Хаос — он ведь не сразу заметен. Поначалу кажется, что всё работает, но потом начинаешь осознавать: где-то кнопки разного размера, где-то разработчики изобретают свои решения, а ты тратишь вечность на доработки. Проблемы назревали, и самое полезное, что мы сделали — признали их существование.
1. Непоследовательность компонентов
Один и тот же элемент мог выглядеть по-разному в разных продуктах. Например, кнопки отличались размерами, цветами или даже поведением. Это не только путало самих дизайнеров, но и вызывало головную боль у разработчиков.
2. Отсутствие единого источника правды
Не было централизованного репозитория с компонентами. Каждый проект — это отдельный набор решений. В итоге любое новое требование превращалось в поиск «где бы подсмотреть» или создание чего-то с нуля. (+ к выходу за рамки дедлайнов и + к выгоранию, а нам это не надо).
3. Сложности с масштабируемостью
Рост продукта обнажил слабые места: старые компоненты не вписывались в новые задачи или нуждались в серьёзных доработках. Вместо плавного роста системы мы сталкивались с необходимостью пересобирать её под новые требования.
4. Хаос в макетах
Макеты были хаотичными, с разбросанными компонентами и отсутствием чёткой структуры файлов. Даже внутри одной команды было сложно понять, где искать нужный элемент и как его использовать.
5. Зона отчуждения между дизайнерами и разработчиками
Разработчики, не видя чётких инструкций, пытались доделать компонент, если тот был не со всеми состояниями. После ревью фронта это выливалось в очередные доработки, что, в свою очередь, влекло к затягиваниям сроков (+ к выходу за рамки дедлайнов и + к выгоранию).
Почему это все было критично?
Когда у тебя больше десяти продуктов, в которых задействованы десятки людей, хаос становится очень дорогим.
Середина пути: с какими трудностями мы столкнулись
Токены
При создании новой дизайн-системы мы столкнулись с ключевым ограничением: компоненты нужно было строить на токенах основной дизайн-системы «Северстали». Почему? Всё просто — разработчики и так были перегружены, а мы не могли позволить себе тянуть сроки и добавлять нагрузку.
Создавать свои токены или работать вразрез с основной системой? Это был путь к просроченным дедлайнам, что мы сразу исключили. Поэтому мы решили использовать существующие токены. Это ускорило интеграцию, но потребовало педантичного подхода — каждый шаг нужно было продумывать так, чтобы ничего не сломать.
Анализ компонентов
Сложнее всего было разобраться, кто и какие компоненты использует в проектах. Дизайнеры, бизнес-аналитики, системные аналитики — у каждого своё видение и подходы. Мы провели настоящее исследование: ходили по командам, задавали вопросы: «Что вы используете?», «Где это работает?», «Почему именно так?».
Это были практически UX-интервью, благодаря которым удалось собрать полную картину. У нас был разработан в связи с этим flow для анализа и сбора информации по каждому даже мельчайшему компоненту от кнопки с одной иконкой до таблицы Ганта.
Дедлайн: три месяца
Три месяца на всё — сбор, согласование, тестирование и интеграцию. Ошибок допускать было нельзя: любая задержка могла сорвать процесс. Мы следовали чёткому плану, синхронизировались каждый день и ставили приоритеты без потери качества. Каждый член команды вносил улучшения в процесс тогда, когда считал это нужным, что делало нашу работу более гибкой и спокойной.
Конец пути: Как мы разработали план с дедлайном всего лишь в три месяца
Когда у вас есть всего три месяца на пересборку дизайн-системы для десятков продуктов, ключ к успеху — чёткий и понятный план. Мы знали, что времени мало, поэтому каждый шаг должен был приносить максимум пользы. Вот как мы это сделали:
1. Декомпозиция задачи
Мы разбили большую задачу на небольшие управляемые этапы. Начали с аудита всех компонентов: что используется, что дублируется, а что нужно заменить. Это позволило точно определить объём работы и расставить приоритеты.
2. Чёткие приоритеты
Не все компоненты одинаково важны. Мы выделили ядро системы — элементы, которые используются во всех продуктах (например, кнопки, таблицы, модальные окна). С них мы и начали. Всё остальное оставили в backlog.
3. Синхронизация команды
Каждую неделю мы синхронизировались: что сделано, что осталось, где есть риски. Это позволяло держать всех в курсе и оперативно решать возникающие проблемы.
4. Storybook для тестов
Для проверки и демонстрации компонентов мы использовали Storybook. Он позволил нам тестировать элементы до их интеграции, что сократило количество ошибок и упростило взаимодействие с разработчиками.
Итог:
Три месяца пролетели, как один спринт. Мы держали фокус на главном, шли по плану и справились. Теперь у нас не просто дизайн-система, а рабочий инструмент, который радует всех участников разработки наших интерфейсов.
Что дальше?
В следующей статье я расскажу, как мы пришли к единой структуре компонента в Figma, включая техническую документацию и другие полезные материалы. Вы узнаете о принципах ведения макетов, которые сделали нашу систему удобной и понятной для всех. А ещё я поделюсь готовым шаблоном компонента в Figma, который вы сможете использовать в своих проектах.
Буду рада услышать ваше мнение и обсудить ваш опыт работы с дизайн-системами. Какие сложности вы встречали при создании или масштабировании дизайн-систем? Делитесь в комментариях — давайте обмениваться знаниями и делать наши продукты ещё лучше!
Интересные статьи
Интересные статьи
