
Что такое дизайн-система?
Дизайн–система — это как отдельный продукт внутри одного большого IT–проекта. Она состоит из набора шаблонов, руководства по стилю, определенных стандартов.

Когда компании нужна дизайн-система?
Когда у нее несколько схожих продуктов для клиентов. В этом случае крайне важно, чтобы все продукты были выполнены в одном дизайне и с одной логикой.

Как создать свою дизайн-систему?
Сам процесс требует серьезных вложений. Так что если вы небольшая компания и денег пока нет, то с дизайн–системой лучше подождать или начать с атомарного дизайна.

Что такое дизайн–система
Дизайн–система — это как отдельный продукт внутри одного большого IT–проекта. Она состоит из набора шаблонов, руководства по стилю, определенных стандартов. Из них, как из конструктора дизайнер компании собирает сайты и приложения.
Если смотреть узко, то дизайн–система будет состоять из цветов, шрифтов, блоков и других инструментов проектирования. Но если взглянуть на нее шире, то это определенная философия, принципы и структура, которой руководствуется команда продукта, чтобы работать быстрее. Она дает им направление для работы.
Отличный пример дизайн системы — конструктор–сайтов Tilda. Есть набор компонентов с определенным функционалом. И из них собирается готовый продукт.


Из чего состоит дизайн–система

Зачем нужна дизайн–система?

Когда компании нужна дизайн–система

Как создать свою дизайн–систему
Сделать это не так просто. И сам процесс требует серьезных вложений. Так что если вы небольшая компания и денег пока нет, то с дизайн–системой лучше подождать. Либо начать с атомарного дизайна.

Что такое атомарный дизайн
Атомарный дизайн — это основа дизайн–системы или один из методов ее проектирования. Тут проводится прямая аналогия между дизайном и любым живым организмом. Компоненты дизайна воспринимаются как атомы и молекулы.
Объяснить в двух словах все принципы атомарного дизайна не получится. Но если хочется погрузиться в эту тему глубже, то здесь вы найдете перевод книги Брэда Фроста, разработчика интерфейсов и создателя методики «Атомарный дизайн». Ссылка на книги — атомарный–дизайн

Командная работа для построения дизайн–системы
Выделим основные моменты, которые нужны для построения дизайн–системы.
Команда совместно начинает работу над системой. Обычно задействованы UX- и UI–дизайнеры, разработчики, менеджер проекта или владелец продукта. Но так или иначе вся компания в теме и всячески содействует процессу.
Главная роль, конечно, отводится дизайнерам: они создают компоненты системы. Компоненты описывают и документируют. Проще говоря, все, что как–то связано с дизайном продукта (значки, шрифты, изображения и прочее) собирают в одном месте и организуют. Это нужно для того, чтобы любой сотрудник мог правильно понять, как и где это правильно применять. У всех должен быть открыт доступ к этой библиотеке.
Основа дизайн–системы — это принципы или желаемые качества, требования к продукту. О них команда договаривается заранее.
Затем все согласовывают визуальный язык, на котором продукт будет говорить с пользователями. Важно определиться, какой настрой и какой посыл в это вложен.
Учитываются и технические моменты по применению этих самых компонентов. Для этого дизайнеры вместе с программистами проходят путь внедрения элементов, чтобы потом можно было все эти нюансы разработки учесть. Все проблемы, которые всплывают в процессе внедрения, тоже учитывают.

Комплексный подход к созданию дизайн–системы
Дизайн–систему нельзя начать внедрять в середине проектирования или «впихивать» в уже готовые продукты. Это комплексный подход. И он начинается от начала проектирования и до применения в уже готовых продуктах. То есть охватывает весь их жизненный цикл.
Хорошо начать продумывать и описывать компоненты на старте продукта, чтобы затем их систематизировать.

Минусы дизайн–системы

Создание дизайн–системы: кейс Высшей школы экономики
У Высшей школы экономики много разных айти–продуктов: сайты, сервисы, соцсети, образовательная платформа. Для них нужна была единая дизайн–система:
Создавать дизайн–систему начали с анализа уже имеющихся продуктов, их компонентов.
Затем все эти компоненты начали распределять по частоте использования. Хотели понять, какие детали приоритетны, а какие совсем не нужны, потому что используются очень редко.
Подошли к следующему шагу — разработке различных блоков библиотеки компонентов в соответствии с приоритетность. Каждый элемент по сути выпускали отдельно, как продуктовую фичу.
Что в итоге получили: