Часть 1. Предыстория и замысел

Всем привет! Меня зовут Иван, я руковожу группой «Дизайн и клиентский сервис» в ИТ-команде «Северстали». Уже почти год мы занимаемся разработкой собственной мультибрендовой дизайн-системы. Наша цель — создать платформу, которая обеспечит «Северстали» необходимую гибкость и независимость от сторонних вендоров при разработке цифровых продуктов, что особенно актуально в условиях тренда на импортозамещение в России.

В последние годы дизайн-системы стали неотъемлемой частью создания цифровых продуктов как на западном рынке, так и в России. Они позволяют унифицировать дизайн и улучшить взаимодействие между разработчиками, дизайнерами и другими участниками процесса.

История масштабная, и я расскажу о ней в трёх частях.

• В первой части (этой) расскажем, как мы пришли к идее собственной дизайн-системы, какие проблемы стояли перед нами и каким видим целевой результат.

• Во второй части заглянем «под капот» системы: поговорим о технических решениях, компонентной базе и токенах, которые мы используем.

• В третьей части покажем результаты и расскажем, как внедрение дизайн-системы повлияло на процессы и продукты.

• В четвёртой части уделим отдельное внимание сложным компонентам: таблицам и диаграмме Ганта.

Предпосылки

Перед нами стояла проблема: большое количество продуктов с разными решениями в части UI-китов. Отличались даже системы, которые соседствовали друг с другом на экране диспетчера на заводе, что создавало ощущение неопрятности и неконсистентности. У каждого проекта были свои подходы к дизайну: существенно различалась цветовая палитра, по-разному реализовывалась тёмная тема, и каждый в той или иной степени отходил от брендинговых стандартов и единства стиля и пользовательского опыта.

Огромное количество децентрализованно развивающихся по собственным правилам проектов негативно влияло на восприятие наших систем, создавая несогласованное общее впечатление, хотя каждая из систем выполняла свои задачи для пользователей.

Помимо различий в дизайне, отличался и стек разработки, что увеличивало рассинхрон: какие-то проекты были на Vue, другие на Angular, третьи на React.

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

Цели создания дизайн-системы

Мы начали с определения целей и формирования круга проблем, которые могли бы решить с помощью дизайн-системы. Наша основная задача заключалась в том, чтобы в короткие сроки и за адекватный бюджет организовать разработку максимально передовой с технической точки зрения дизайн-системы, которая позволила бы:

• сократить сроки разработки;

• принять на вооружение единый фронтенд-стек — React;

• создать визуальный стандарт для всех цифровых продуктов в соответствии с брендбуком компании;

• оптимизировать рабочий процесс дизайнеров для быстрой работы с компонентами и особенно с адаптивами;

• разработать визуальный стандарт для тёмной темы (в брендбуке изначально этого не предусматривалось);

• выстроить оптимальный пайплайн взаимодействия разработчиков и дизайнеров и создать условия, при которых работа дизайнеров могла бы автономно влиять на дизайн-систему с минимальными затратами со стороны разработки;

• создать гибкую и универсальную систему, которая могла бы подстраиваться под другие фирменные стили, например, наших партнёров или дочерних компаний.

Начало разработки

Защитив проект дизайн-системы перед руководством, мы сформировали команду для борьбы с силами хаоса:

• руководитель проекта,

• лид-дизайнер,

• лид фронтенд-разработки,

• 2 дизайнера,

• 2 фронтенд-разработчика.

Анализ рынка и конкурентов

Мы изучили существующие корпоративные дизайн-системы — как зарубежные, так и российские. В фокусе анализа были такие аспекты, как:

• масштаб и глубина компонентной базы,

• гибкость в настройке и вариативность,

• уровень документации,

• использование дизайн-токенов,

• интеграция с современными инструментами (Figma, Storybook и др.),

• поддержка тёмных тем и внимание к доступности.

Почти везде мы видели одну закономерность: чем более универсальна дизайн-система, тем сложнее бывает «вкатиться» и адаптировать её под очень специфические задачи. С другой стороны, узкоориентированные решения могут не покрыть всех потребностей. Поэтому мы стремились найти собственный баланс, учитывающий масштаб компании, специфику металлургической отрасли и требования к цифровым продуктам.

Выводы из анализа конкурентов

• Токены и синхронизация с разработкой. Мы заметили, что многие системы не уделяют должного внимания эффективной связи между дизайном и кодом. Мы хотим внедрить дизайн-токены с возможностью синхронизации с разработкой. С появлением Local Variables в Figma это стало более реальным: теперь мы можем хранить ключевые значения, такие как цвета, шрифты, размеры отступов и принципы их масштабирования в адаптивах, в одном месте и автоматически обновлять их как в дизайне, так и в коде.

• Атомарный дизайн по Брэду Фросту. Идеи атомарного дизайна уже вдохновили множество дизайн-систем, и наша не стала исключением. Компоненты строятся от простого к сложному — от атомов к молекулам и организмам. Такой подход обеспечивает согласованность и предсказуемость, а также облегчает масштабирование и поддержку системы в долгосрочной перспективе.

• Гибкость и вариативность компонентов. Мы понимаем, насколько важно иметь компоненты, которые могут адаптироваться под разные сценарии использования. Наша цель — создать гибкие и настраиваемые компоненты, которые можно легко модифицировать без нарушения общей структуры и стиля.

• Человечный подход к дизайну. Мы хотим, чтобы наша дизайн-система была не просто набором правил и компонентов, а живым инструментом, который облегчает жизнь дизайнерам и разработчикам. Это означает доступную и понятную документацию, примеры из реальной практики и открытый диалог внутри команды для постоянного улучшения системы.

Изучив существующие дизайн-системы, мы поняли, что для создания эффективной собственной системы нам важны:

• интеграция с современными инструментами. Использовать возможности, которые предоставляет Figma и другие современные инструменты, для облегчения процесса разработки и обновления системы;

• баланс стандартизации и гибкости. Стандарты важны для консистентности, но излишняя жёсткость может тормозить инновации. Наша система должна поддерживать единый стиль, но при этом позволять творческий подход;

• фокус на потребностях команды. Учитывать реальные потребности и рабочие процессы нашей команды, чтобы система стала органичной частью повседневной работы, а не дополнительной нагрузкой.

Спасибо, что дочитали до конца! В следующих частях мы подробно расскажем о реализации нашей дизайн-системы, покажем компонентную базу и поделимся результатами внедрения. До встречи!