WebValley Studio

Дизайн система: что это, зачем нужна, из чего состоит, и как создать дизайн систему с нуля — реальный опыт

Дизайн-система — мастхэв для крупных проектов. Она упрощает работу дизайнерам и разработчикам, а заказчику помогает снизить расходы на разработку и ускорить выпуск веб-продуктов без потери качества. Мы не только раскроем теоретические аспекты проектирования дизайн систем, но и поделимся практическим опытом разработки и внедрения дизайн-системы у нас в студии.

Что такое дизайн-система

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

Чтобы решить эти проблемы создаётся система, в которой собраны все элементы дизайна, компоненты, библиотека кода, а также правила и рекомендации, как их использовать. Это называется дизайн-системой.

Дизайн-система и UI-kit: в чём разница

У дизайн-системы есть младший брат, а точнее, потомок — UI-kit.

UI-kit — это набор элементов дизайна: кнопки, иконки, поля ввода, табы и т. д. Он может существовать отдельно от дизайн-системы, если это небольшой проект. Но если разрабатывается крупный продукт, и решено использовать дизайн-систему, UI-kit должен подчиняться её правилам и стандартам.
UI-kit – часть дизайн-системы.
дизайн система и ui kit

UI-kit в дизайн-системе

Виды дизайн-систем

Дизайн-системы бывают 2х видов: с открытым и закрытым кодом.

Дизайн-системы с открытым кодом подходят для публичного использования: ими могут воспользоваться все дизайнеры и разработчики. Их можно использовать и адаптировать под любой проект.

Дизайн-системы с закрытым кодом создаются индивидуально, под конкретный проект и, как правило, доступ к ним ограничен.
Перед тем как разработчик закодит дизайн-систему, дизайнер создает её в Figma. Этому мы учим на курсе Pro Figma.

Дизайн-системы в Figma — без кода

Figma — современный графический редактор, который позволяет создавать и поддерживать согласованный дизайн интерфейсов, без погружения в код. Дизайн система в Figma — это набор гайдлайнов и правил, готовых компонентов, стилей и элементов, который упрощает создание дизайна и его последующее масштабирование.
Дизайн-система WebValley Studio в Figma

Дизайн-системы с открытым кодом

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

Дизайн-системы с закрытым кодом

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

Зачем нужна дизайн-система для компании

Дизайн-системы стоят дорого. Если у вас лендинг с одной кнопкой «Заказать», вам нет смысла прописывать десятки состояний и вариантов использования этой кнопки. Или если вы владелец интернет-магазина, в котором из обновлений только карточки товара, разработка дизайн-системы вам, скорее всего, не окупится. Только если вы бренд, с соцсетями, печатными материалами и так далее, ведь все они подчиняются гайдлайнам дизайн-системы. Такой монолит используется в крупных проектах — это банки, агрегаторы, корпорации, крупные бренды. В остальных случаях будет достаточно UI-kit.

Несколько продуктов в рамках одной экосистемы

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

Вся экосистема digital-продуктов должна работать на узнаваемость бренда. Если открыть приложение Сбера на ноутбуке, смартфоне, смарт-часах и телевизоре, мы увидим одни и те же элементы интерфейса. Дизайн-система помогает пользователю узнать любимый бренд даже по элементам управления. Вы же сразу догадались, из чьей дизайн-системы эти компоненты:
корпоративные дизайн системы

Компоненты дизайн-системы Apple

Они одинаково выглядят на всех устройствах и даже, когда у человечества будут личные космические корабли фирмы Apple, интерфейс у них, скорее всего, будет такой же узнаваемый.

Ускорение работы

Ещё одна причина использовать дизайн-системы для крупного продукта или целой экосистемы — ускорение работы. Можно провести аналогию со строительством. Дизайн-система — это аналог панельных домов, которые возводятся не по кирпичику, а целыми блоками, что в разы ускоряет процесс.

Дизайнер использует эти готовые блоки в макете, разработчик — готовые компоненты в коде. К простым задачам можно вообще не подключать дизайнера, а сразу передавать разработчику. Даже ТЗ на дизайн и разработку составляется быстрее, ведь вместо того, чтобы объяснять всё с нуля, просто ссылаешься на конкретный пункт гайдлайна.

Ускорение запуска для проверки гипотез

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

Преемственность дизайна

Бизнес растёт. Вместе с этим растёт количество сотрудников: кто-то уходит, на их места приходят зелёные, ничего не знающие новички. Дизайн-система позволяет не париться о том, что всё держится на одном человеке, который единственный знает, что и как должно выглядеть или использоваться.

С дизайн-системой у вас есть полноценная документация, с которой можно подключать к проектам новых дизайнеров и разработчиков, не боясь всё запороть. Любому сотруднику достаточно открыть документацию, ознакомиться с элементами и принципами их использования, и в бой.

Менеджеры, дизайнеры, разработчики — все говорят на одном языке. У каждого сотрудника есть чёткое понимание какие компоненты, где и как используются. С единой дизайн-системой возможна синхронизация нескольких разных команд без потери качества и времени.

Консистентность: дизайн продуктов в едином стиле

Продукт должен оформляться в едином стиле. Это помогает пользователям привыкнуть к интерфейсу и повышает узнаваемость бренда. Дизайн-система закрывает обе эти потребности бизнеса. Внимание к деталям — это то, что создает стиль. Крупный продукт должен стремиться стать брендом. Дизайн-система — обязательный шаг на пути к этой цели.
дизайн системы figma
как подключить дизайн систему в figma
дизайн система в фигме
Консистентность дизайн-продуктов. Сайт и дизайн упаковки, выполненные по общим правилам в едином стиле

Ошибки сводятся к минимуму

При разработке интерактивных элементов могут возникать ошибки. Даже у обычной кнопки может быть более 10 состояний: наведение, фокусировка, активная или заблокированная и т. д. Велик риск что-то упустить. Такие ошибки влияют на юзабельность сайта или приложения.

Готовая дизайн-система сводит вероятность подобных ошибок к нулю. Разработчик не выбесит дизайнера тем, что перепутал оттенок серого #CCCCCC с #C1C1C1. Системность, чёткие правила, готовые компоненты с ограниченной вариативностью — все эти принципы защищают ваш проект от ошибок лучше, чем смайлик на фотографии с ребёнком от сглаза.

Снижение затрат на разработку в перспективе

Со временем дизайн-системы разрастаются, появляются стабильные версии. При наличии стабильной дизайн-системы в разы сокращается время на разработку, потребность в большом количестве сотрудников, а значит, и затраты бизнеса. Именно поэтому на крупных проектах дизайн-системы хорошо окупаются.

Дизайн система в UX

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

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

Редизайн дизайн-системы

Ребрендинг и редизайн всегда идут рядом с развивающимся брендом, будь то банк или сеть шаурмы. И это очень сложные, масштабные, дорогостоящие изменения. Наличие дизайн-системы сводит трудности к минимуму, так как она также претерпевает изменения на протяжении жизненного цикла продукта. Однако, при её наличии и изменении какого-либо компонента вам не придётся изменять его во всём приложении — правки в дизайн-системе применятся везде. Что проще: исправить компонент в дизайн-системе, или залезть в код на каждой странице сайта, изменить везде этот компонент руками? Время = деньги. Изменился фирменный цвет? С дизайн-системой надо лишь обновить её версию и — вуаля, все кнопки изменили цвет.

Недостатки дизайн-системы

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

Дорого

Основной недостаток дизайн-системы — стоимость. Для её разработки нужна целая команда, состоящая из дизайнеров, разработчиков, менеджеров и маркетологов.

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

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

Нужно поддерживать в актуальном состоянии

Нельзя сделать одну дизайн-систему раз и навсегда. Бизнес растёт, развивается. На каком-то этапе потребуется трансформация или даже ребрендинг. В зависимости от задач, этот процесс может превратиться в создание абсолютно новой дизайн-системы.

Меньше творчества и креатива

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

Принципы и требования к дизайн системам

Дизайн-система разрабатывается под требования бизнеса, с учётом специфики продукта. Но, несмотря на уникальность, любая дизайн-система должна отвечать ряду принципов.

Модульность

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

Реализация принципа модульности в дизайн-системе

Повторяемость

Все элементы должны быть в едином фирменном стиле. Например, если принято, что компоненты бренда имеют скругления, а главный фирменный цвет элементов синий — значит все компоненты (карточки, кнопки, поля и тд) со скруглениями, а кликабельные элементы — синие.

Масштабируемость

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

Актуальность компонентов

Дизайн-система развивается вместе с продуктом, поэтому она актуализируется по мере актуализации проекта, в котором используется. Если за дизайн‑системой никто не следит, своевременно не актуализирует, значит это мертвая дизайн-система.

Доступность для всех членов команды

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

Атомарный дизайн

Дизайн-система строится по принципу от меньшего к большему. Как и всё в мире, она состоит из атомов, молекул, а затем более сложных структур.

Атомы — это самая меньшая, неделимая часть дизайн-системы, например, иконка или текст.

Молекулы — это составной компонент из нескольких атомов. Например, кнопка, которая состоит из текста и иконки.

В свою очередь, молекулы объединяются в ещё более сложные элементы — комплексные компоненты, например, карточки товара или новостей.

Компоненты могут объединяться в шаблоны, например, секции с товарами, информационные блоки.

Потом, из всех этих деталей, как конструктор, строится страница. С таким подходом дизайн-система легко масштабируется и постоянно переиспользуется. А дизайн, созданный из этих компонентов, получается согласованным, в едином стиле.

Принцип наследуемости

Представьте, что вам нужно изменить цветовую схему на уровне корневых стилей. При соблюдении принципа наследуемости, все элементы, наследующие эту схему, автоматически адаптируются к новому стилю. Вам не придётся обновлять каждый элемент вручную отдельно.

Вместе, атомарный дизайн и принцип наследуемости, помогают эффективно управлять дизайн‑системой, изменять и поддерживать её в актуальном состоянии.

Что входит в дизайн систему: компоненты, структура, уровни

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

UI-kit: визуальный язык

Рассмотрим UI-kit на примере нашей дизайн-системы:
дизайн система пример

Структура UI-kit WebValley Studio

Она включает в себя токены: типографика, цвета, тени; компоненты: кнопки, инпуты, табы, комплексные модули: строки таблиц с иконками, карточки блога, блоки аккордеоны (раскрывающиеся списки), карточки кейсов и другие.

Кнопки в дизайн системе и их состояния

Обычные пользователи не задумываются, что у кнопок есть состояния, а неопытные дизайнеры знают только состояние hover. Но для доступности, удобства, интуитивности интерфейса нужно продумать все состояния:
  • hover — наведение,
  • focus — фокусировка, важна для поискового робота и скринридеров,
  • active — событие нажатия,
  • disabled — неактивное состояние.

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

Как правило, кнопки в дизайн-системе, помимо состояний, имеют вариативность. Это может быть разный цвет, размер, с иконкой или без: тут всё ограничивается только фантазией и здравым смыслом. Если вы будете создавать свою дизайн-систему, обязательно помните про нейминг: называйте все элементы и состояния единообразно, так, чтобы они были понятны любому пользователю, чтобы не нарушить доступность дизайн-системы.
дизайн система кнопки

Кнопки дизайн-системы WebValley Studio

Шрифты в дизайн системе

Сайт или приложение не могут существовать без текста, поэтому шрифты — обязательный элемент дизайн-системы. Они, как и другие компоненты, должны подчиняться ряду правил. Если на сайте будет куча разных шрифтов, начертаний или их размеров, то это будет дико неудобно читать.

Важно определить семейство шрифтов. Это может быть один шрифт или несколько, главное не перебарщивать. Надо прописать размеры: заголовки первого, второго, третьего уровня, параграфы, подписи, цифры, кнопки и т. д. Обязательно заложите диапазон размеров с определенном шагом, например, от 12px до 72px. Заранее предусмотрите, нужна ли жирность для какого-либо текста.

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

Типографика дизайн-системы WebValley Studio

Цвета в дизайн системе

Обычно дизайнеры используют определенное количество цветов в проекте и прописывают их в UI-Kit. Но в чём разница цветовой палитры в UI-Kit и в дизайн-системе?

UI-Kit содержит только те цвета, которые используются в дизайне, например: white, black, blue, dark-blue, light-blue, red, green.

Дизайн-система предполагает более глубокую проработку цветов. Это диапазон каждого цвета: как правило, 10 или 12 оттенков, от тёмного к светлому. Для всех элементов описывается, какой оттенок какого цвета используется в том или ином случае. Например, при наведении на кнопку или цвет ошибки заполнения поля ввода.
дизайн система цвета

Отличие цветовой палитры в UI-Kit и дизайн-системе

Благодаря этому, несколько дизайнеров могут работать над проектом параллельно, но готовый продукт получится в едином стиле. Как правило, в палитру всегда закладываются:
  • оттенки серого,
  • фирменные цвета компании,
  • системные: красный (ошибка), зеленый (успех), желтый (предупреждение).

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

Текст и контент в дизайн системе

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

Например, блок заголовка может быть с текстом слева или справа, содержать текст и заголовок или только заголовок. Есть смысл выносить такие элементы в отдельные компоненты дизайн-системы, со всей вариативностью и адаптацией.
текст в дизайн системе

Вариативность текстовых блоков дизайн-системы WebValley Studio

Иконки

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

Они должны быть в векторном формате, заданного размера: нельзя допускать, чтобы одна иконка была 20×20, другая 21×23, а третья 47×47.

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

Иконки могут быть разных цветов, но важно, чтобы они были в одной стилистике. Хороший тон — соблюдение модульности: системные иконки — один модуль, навигация — другой, социальные сети — третий и т. д.
иконки в дизайн системе

Иконки. Дизайн-система WebValley Studio

Изображения

Изображения — это элемент, о котором часто забывают при создании дизайн‑систем, но он может быть востребован. Например, плейсхолдеры для карточек или аватаров. Они также могут иметь различные размеры, скругления углов, которые чётко определены в дизайн‑системе.

Анимация

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

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

UI-элементы

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

Поля ввода. Дизайн-система WebValley Studio

Взаимодействие

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

Валидация полей ввода. Дизайн-система WebValley Studio

Сетка и пространство

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

Сетка и отступы дизайн-системы WebValley Studio

Формы объектов

Геометрия элементов олицетворяется через их форму. Примеры таких форм включают в себя:
  • скругления углов и степень их остроты,
  • присутствие теней и степень их насыщенности,
  • углы поворота элементов (чаще всего это относится к различным плашкам).

Дизайн-система помогает заложить общие геометрические правила для формирования элементов.

Гайдлайн

Гайдлайн — документ, который содержит набор правил о том, как пользоваться дизайн-системой и её элементами. Например, правила расположения элементов на странице, отступы, пропорции и прочие.

Фреймворк

Фреймворк в дизайн-системе — это кодовая база для всех элементов системы, с анимацией и различными сценариями использования компонентов.

Документация дизайн-системы

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

Библиотеки готовых дизайн‑систем

Дизайн систему можно создать с нуля, либо использовать существующие библиотеки.

Ant Design

Проект разработчиков из Alibaba Group. Ant Design нечто более крупное, чем библиотека компонентов. Это полноценный визуальный язык, со своими принципами, стайлгайдами и компонентами. Её отличает приятный дизайн и простота в использовании. Для всех предложенных компонентов есть файлы в Figma.
скачать дизайн систему

Ant Design. Еженедельно эту библиотеку скачивают 1,3 млн раз

Material UI

Ещё одна популярная библиотека компонентов. Содержит более 2100 тысяч иконок и более 100 компонентов. Также как в Ant Design, здесь есть макеты для дизайнеров в Figma, Sketch либо Adobe.
готовые дизайн системы

Material UI. Еженедельных скачиваний — 3,2 млн

Chakra UI

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

Chakra UI. 0,5 млн еженедельных скачиваний

Mantine

Библиотека, содержащая более 100 компонентов. Помимо них также включает в себя React Hooks, работу с формами и Date pickers.
библиотека дизайн систем

Mantine UI. 235 тыс еженедельных скачиваний

Semantic UI React

Легко настраиваемая библиотека с открытым исходным кодом. Использовалась в проектах Netflix.
библиотеки дизайн систем с открытым кодом

Semantic UI React. 215 тыс еженедельных скачиваний

React Bootstrap

Большая библиотека компонентов, построенная на базе популярного фреймворка Bootstrap и оптимизированная для React-приложений.
библиотека дизайн систем с открытым кодом

React Bootstrap. 2.3 млн. еженедельных скачиваний

Evergreen

Библиотека построена на примитиве React UI. Имеет хорошую документацию и гибко настраиваемые компоненты.
библиотека готовых дизайн систем

Evergreen. 9 тыс еженедельных скачиваний

Создание дизайн системы: проектирование и разработка

Создание дизайн-системы состоит из следующих основных этапов:
  1. Аналитика. Начинается с визуального исследования, анализа цветовой палитры, выбора шрифтов, определения сетки для последующего использования в интерфейсе. Затем прорабатывается анимация, выбор изображений и фоновых элементов, соответствующих общей эстетике и целям системы.
  2. Создание атомарных элементов дизайн-системы: иконок, шрифтовой палитры, цветовой палитры.
  3. Проектирование комбинаций элементов. Создание молекул — более сложных элементов дизайн-системы, состоящих из атомов. Например, кнопок, полей, тултипов.
  4. Программирование. Переход от дизайна к реализации кодом, создание функционала и интеграции всех компонентов в единую рабочую систему.
  5. Оформление гайдлайна. Документация элементов, формирование подробного описания каждого элемента системы, его назначения, визуальных примеров использования и рекомендаций по применению в различных контекстах.

Этот подход помогает не только создать систему согласованных элементов, но и обеспечить их эффективное использование.

Разработка дизайн-системы WebValley Studio: разбор реального кейса

Всё, что касалось дизайна, проектирования мы описали выше с примерами из нашей дизайн‑системы. Теперь поделимся опытом разработки дизайн системы, который поможет в работе с вашими проектами.

Целесообразность дизайн системы

Сайт студии — огромный проект на 200+ страниц, все они должны быть выполнены в едином визуальном стиле. Этот визуальный стиль основан на принципах, описанных в брендбуке. При этом полиграфия также должна быть согласована с брендбуком, а значит и с сайтом. Короче, всё связано в кольцо =))).

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

Сторонние библиотеки vs собственная дизайн система

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

Технический процесс создания дизайн системы

Разработка дизайн-системы состоит из следующих этапов:
  • подготовка сборщика библиотеки,
  • написание кода компонентов,
  • составление документации,
  • тестирование компонентов,
  • публикация библиотеки.

Сборщик

Сборщик — это фундамент разработки дизайн-системы. Настройка сборщика с нуля отнимает много времени и сил, поэтому, уверены, что многим наш опыт упростит жизнь.

Изначально мы создали простой сборщик на Webpack. Ниже — скелет сборщика. Он подойдет для основы простых дизайн-систем, которые будут использоваться в React приложениях:

const path = require("path");

module.exports = {
  mode: "production",
  entry: "./src/index.ts",
  output: {
    filename: "index.js",
    path: path.resolve(__dirname, "dist"),
    libraryTarget: "umd",
    clean: true,
  },
  resolve: {
    extensions: [".ts", ".tsx"],
  },
  externals: {
    react: "react",
  },
  module: {
    rules: [
      {
        test: /\.css/,
        use: ["style-loader", "css-loader"],
      },
      {
        test: /\.(ts|tsx)?$/,
        use: ["ts-loader"],
        exclude: /node_modules/,
      },
    ],
  },
};
Мы протестировали этот сборщик на приложении React, наши компоненты отображались в браузере, мы приступили к следующим задачам. Но как же без проблем в разработке? =))

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

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

Технология React, в отличие от привычных всем HTML, CSS, JS (с помощью которых создаются обычные сайты или темы для Wordpress, Битрикс и т. п.) работает принципиально иначе. Особо не будем грузить деталями, но суть в том, что в обычном мире пользователь видит ту страницу, которую прислал сервер. В React сервер не присылает никаких страниц, а отправляет, грубо говоря, пустую коробку с названием «Главная» и скрипт. Только после того, как этот пакет пришёл пользователю, у него появляется страница: её создаёт скрипт от той самой «коробки». И это проблема, так как поисковые роботы такие штуки не понимают, а значит и SEO работать не будет — поисковый робот также будет получать не страницы сайта, а пустые коробки.

Чтобы решить проблему SEO нужно что-то, что будет поисковому роботу отправлять готовые страницы, а не пустые коробки. На языке разработки — это пререндеринг. Ну или Server Side Rendering (SSR — генерация страниц на сервере). Мы решили для нашего сайта использовать специальную обёртку, с помощью которой можно было бы настраивать пререндеринг. Этой обёрткой стал Next 13 — фреймворк, созданный для приложений на React. Благодаря ему приложение остаётся таким же шустрым, но добавляется вишенка — возможности SEO, генерация однотипных по составу страниц (например, статьи, товары) ну и другие фишки.
Заметка для разработчиков

SSR не позволял нам отображать компоненты из дизайн системы, собранной webpack’ом. Решили попробовать использовать компилятор typescript, но столкнулись с проблемами подключения плагинов для SCSS и прочих хотелок. В итоге проблему удалось решить с использованием rollup. Он позволяет подключать все необходимые плагины точно также, как и webpack, но не конфликтует с Next и его SSR.

Наш сборщик на Rollup:

const typescript = require("@rollup/plugin-typescript");
const postcss = require("rollup-plugin-postcss");
const url = require("@rollup/plugin-url");
const svgr = require("@svgr/rollup");
const terser = require("@rollup/plugin-terser");
const dts = require("rollup-plugin-dts");
const packageJson = require("./package.json");
const peerDepsExternal = require("rollup-plugin-peer-deps-external");
const autoprefixer = require("autoprefixer");
const resolve = require("@rollup/plugin-node-resolve");
const commonjs = require("@rollup/plugin-commonjs");

module.exports = [
	{
		input: "src/index.ts",
		output: [
			{
				file: packageJson.module,
				format: "cjs",
				sourcemap: true,
			},
			{
				file: packageJson.main,
				format: "esm",
				sourcemap: true,
			},
		],
		external: ["react-dom"],
		plugins: [
			pierDes External(),
			resolve(),
			commonjs(),
			typescript({
				tsconfig: "./tsconfig.json",
				exclude: ["**/*.stories.tsx"],
			}),
			postcss({
				extract: "index.css",
				modules: true,
				use: ["sass"],
				minimize: true,
				plugins: [autoprefixer()],
			}),
			url(),
			svgr({ icon: true }),
			terser(),
		],
	},
	{
		input: "dist/esm/types/index.d.ts",
		output: [{ file: packageJson.types, format: "esm" }],
		external: [/\.(css|scss)$/],
		plugins: [dts.default()],
	},
];

Storybook

Любая дизайн система должна быть задокументирована. Для этого мы использовали storybook. Это инструмент, который позволяет не только документировать, но и просматривать библиотеку компонентов, видеть различные состояния интерактивных элементов и тестировать компоненты.

Пример нашей story для компонента input.

import React, { useState } from "react";
import { type StoryFn, type Meta } from "@storybook/react";
import { type IInputProps, Input } from "./Input";

const meta: Meta<typeof Input> = {
  component: Input,
  tags: ["autodocs"],
  argTypes: {
    value: {
      control: {
        disable: true,
      },
    },
  },
};

export default meta;

const Template: StoryFun<Input Props> = (args) => {
  const [localValue, setValue] = useState<string>(args.value ?? "");
  return (
    <Input
      {...args}
      onChange={(e) => {
        args.onChange(e);
        setValue(e.target.value);
      }}
      value={localValue}
    />
  );
};
export const Default: StoryFn<IInputProps> = Template.bind({});

Default.args = {
  name: "story_input",
  value: "",
  icon: null,
  placeholder: "Placeholder*",
  required: false,
  success: false,
  successMsg: "successMsg",
  error: false,
  errorMsg: "errorMsg",
  disabled: false,
  label: "inscription",
  caption: "caption",
};

Компоненты

Итак, со сборщиком разобрались, трансформируемся из инженера-сантехника Сан Саныча в мастера по ноготочкам, переходим к вёрстке красивых анимированных кнопок =))

В первую очередь необходимо собрать атомарные части нашей дизайн системы: типографику и цвета.
структура дизайн системы

Типографика дизайн-системы WebValley Studio

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

Пример текста в Storybook. Дизайн система WebValley Studio

Студия следует принципу: разводить общие стили или правила на соответствующие файлы, поэтому цвета вынесены в отдельный файл consts.scss. Мы используем препроцессор SCSS, чтобы спокойно юзать переменные или функции в стилях, а также упростить написание кода.

// Colors
//gray
$gray50: #f4f4f0;
$gray100: #bebe 6;
$gray200: #dbdbd7;
…
//yellow
$yellow50: #fff7d9;
$yellow100: #fff0ba;
$yellow200: #ffeba1;
…
//blue
$blue50: #ebf1fa;
$blue100: #c3d9fa;
$blue200: #a5c8fa;
…
Структура нашего проекта по папочкам выглядит так:

src/
  components/
    [Название_компонента]/
      [Название_компонента].ts
      [Название_компонента].module.scss
      [Название_компонента].stories.tsx
  core/
    assets/
      fonts/
      icons/
    styles/
      consts.scss
      fonts.scss
      …
В качестве примера разберем код компонента LinkButton. tsx — кнопки, выполняющей роль ссылки:

import clsx from "clsx";
import block from "module-clsx";
import React, { type SyntheticEvent } from "react";
import style from "./LinkButton.module.scss";
import * as Icons from "../Icons";

export interface ILinkButtonProps
  extends React.PropsWithChildren<
    Omit<React.HTMLProps<HTMLAnchorElement>, "type" | "size">
  > {
  link: string;
  icon?: keyof Icons.IIcons;
  size?: "small" | "large";
  underline?: boolean;
  color?: "dark" | "light" | "yellow";
  onClick?: (() => void) | ((e: SyntheticEvent) => void);
  extraClass?: string;
}

export const LinkButton: React.FC<ILinkButtonProps> = ({
  children,
  icon,
  link,
  size = "large",
  underline = false,
  color = "dark",
  onClick,
  extraClass = "",
  ...rest
}) => {
  const Icon = Icons[icon];
  const type = icon && children ? "text-icon" : icon ? "only-icon" : "text";
  const addHash = block(style);
  const className = clsx(
    addHash("button"),
    `${size === "large" ? "button-m" : "button-s"}`,
    {
      [addHash(`button_color_${color}`)]: color,
    },
    {
      [addHash(`button_underline_${underline}`)]: underline,
    },
    "manrope",
    "fw-600",
    "caps",
  );
  return (
    <a href={link} className={className} {...rest}>
      {type !== "only-icon" && <span>{children}</span>}
      {type !== "text" ? (
        size === "large" ? (
          <Icon size="20" />
        ) : (
          <Icon size="16" />
        )
      ) : null}
    </a>
  );
};
Компонент принимает на вход ряд параметров — пропсов:

children - текст кнопки;
icon - иконка, как ранее созданный компонент;
link - ссылка на какой-то адрес страницы для перехода;
size - размер;
underline - подчеркивание;
color - цвет;
onClick - обработчик клика;
extraClass - экстра класс, данный пропс есть в каждом нашем компоненте, 
на случай назначения дополнительных стилей.
Использование большинства возможных параметров влияет на стили компонента. Грубо говоря, параметр «color» добавляет кнопке цвет — button__color_black, а параметр size влияет на её размер — button__size_xl. Чтобы было проще и быстрее всё это комбинировать между собой и не писать 850 строк грязного кода, мы использовали библиотеку clsx. Она сама комбинирует стили по условиям.

Файлы стилей у нас модульные. Это нужно, чтобы какой-нибудь .button из одного файлика не затёр. button из другого. При обработке проекта сборщиком все стили в модульных файлах получают хэш. Условный пример: было. button__color_red, а стало. button_color_red_XjK5455. Благодаря хэшированию, каждый одинаково названный стиль станет неодинаковым, так как хеш всегда разный, а значит не произойдёт никаких затираний одного другим, и элемент будет выглядеть как задумано. Ну и разработчику удобно, не нужно придумывать какие-то космические названия в духе button_variant1_with-line_color_black1_121 212.

Но, при использовании clsx в проекте на Next 13 мы столкнулись с проблемой потери этих хэшей. По этой причине в наших компонентах мы используем аналогичную библиотеку — module-clsx. Что clsx, что module-clsx это маленькие библиотеки, которые не влияют на оптимизацию и итоговый размер проекта.

Так выглядит файл со стилями LinkButton.module.scss:

@import "../../core/styles";

//// ОБЩИЕ СТИЛИ НАЧАЛО 

.button {
  cursor: pointer;
  text-decoration: none;
  display: flex;
  align-items: center;
  width: fit-content;
  @include allMediaRez("column-gap", 12);
  transition: opacity 0.5s;
  position: relative;
  & span {
    pointer-events: none;
  }
  & svg {
    pointer-events: none;
  }
  &::before {
    pointer-events: none;
    content: "";
    position: absolute;
    left: 0;
    @include allMediaRez("bottom", -8);
    width: 100%;
    @include allMediaRez("height", 3);
    opacity: 0;
    transition: opacity 0.5s;
  }
  &:hover {
    span {
      animation-name: btntext-in;
      animation-duration: 0.5s;
    }
  }
  &:not(:hover:not(:disabled)) {
    span {
      animation-name: btntext-out;
      animation-duration: 0.5s;
    }
  }
}
//// ОБЩИЕ СТИЛИ КОНЕЦ

//// ЦВЕТА НАЧАЛО

//Темная
.button_color_dark {
  color: $gray800;
  & svg g path {
    fill: $gray800;
  }

  &:focus {
    &::before {
      opacity: 1;
      background-color: $yellow200;
    }
  }

  &:active {
    color: $gray600;
    svg g path {
      fill: $gray600;
    }
  }
}

// Светлая
.button_color_light {
  color: $gray50;
  & svg g path {
    fill: $gray50;
  }

  &:focus {
    &::before {
      opacity: 1;
      background-color: $yellow500;
    }
  }

  &:active {
    color: $yellow50;
    svg g path {
      fill: $yellow50;
    }
  }
}

// Желтая
.button_color_yellow {
  color: $yellow500;
  & svg g path {
    fill: $yellow500;
  }

  &:focus {
    &::before {
      opacity: 1;
      background-color: $yellow700;
    }
  }

  &:active {
    color: $yellow400;
    svg g path {
      fill: $yellow400;
    }
  }
}
//// ЦВЕТА КОНЕЦ

//// ПОДЧЕРКИВАНИЕ СТАРТ

.button_underline_true {
  span {
    position: relative;
    &::after {
      pointer-events: none;
      content: "";
      position: absolute;
      left: 0;
      bottom: 0;
      width: 100%;
      height: 100%;
      border-bottom-style: solid;
      @include allMediaRez("border-bottom-width", 1);
      transition: width 0.6s ease-in-out;
    }
  }
  &:hover:not(:disabled) {
    span {
      &::after {
        width: 0;
      }
    }
  }
  .button_color_dark {
    span {
      border-color: $gray800;
    }
  }
  .button_color_light {
    span {
      border-color: $gray50;
    }
  }
  .button_color_yellow {
    span {
      border-color: $yellow500;
    }
  }
}

//// Подчеркивание конец
Ниже представлена кнопка со storybook
документация дизайн системы

Пример кнопки в Storybook. Дизайн система WebValley Studio.

Остальные компоненты создавались по такому же принципу.

Публикация библиотеки дизайн системы на Github Packages

Мы создали дизайн-систему с закрытым кодом, так как это наш внутренний продукт для создания других продуктов =). Для этих целей использовали Github Packages. Он даёт закрытый доступ ко всей дизайн-системе для команды.

Чтобы опубликовать закрытую дизайн-систему на Github, нужно выполнить несколько простых шагов:

1. Настроить package. json в своей библиотеке, указать name и publishConfig следующим образом:

"name": "@YOUR_GITHUB_USERNAME/YOUR_REPOSITORY_NAME",
  "publishConfig": {
    "registry": "https://npm.pkg.github.com/YOUR_GITHUB_USERNAME"
  },
2. Указать точку входа в main на ваш главный js файл, который генерируется после билда проекта

"main": "dist/esm/index.js",
3. Также для публикации библиотеки на github packages необходимо добавить файл .npmrc:

registry=https://registry.npmjs.org/
@YOUR_GITHUB_USERNAME:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=YOUR_AUTH_TOKEN
Чтобы сгенерировать токен, необходимо в github перейти в settings → developer settings. Вы можете настроить все необходимые параметры для токена: параметры доступа, дату истечения токена и другие. Обязательно после генерации токена скопируйте его, так как после обновления страницы данный токен пропадёт.

Также вы можете использовать NPM. Публичная публикация библиотеки бесплатная, а вот для создания приватного пакета необходимо оплачивать подписку в размере 7 $ в месяц за каждого сотрудника.

Чтобы тестировать компоненты, не публикуя их ни в Github, ни в NPM, можно подключать библиотеку локально, для этого:
  1. Находясь в папке с библиотекой введите в терминал npm link.
  2. Затем, в проекте, где будет использоваться библиотека — npm link [имя_библиотеки].
  3. После успешного подключения библиотеки, в папке node_modules проекта появится папка библиотеки.

Создание дизайн системы — важный этап в веб-разработке, сочетающий непростую техническую реализацию и дизайнерскую концепцию. Надеемся, что наш опыт поможет вам и вдохновит на создание дизайн системы, которая лучше всего подходит для ваших потребностей и проектов.
Автор статьи
Данил Стасенко
Developer
22.11.2023
Соавторы
Алексей Гамов
СЕО WebValley Studio
Мария Дрокина
UI-дизайнер
Вероника Юдина
Руководитель SEO
Доверьте разработку сайта профессионалам!
Оставьте заявку с кратким рассказом о проекте или заполните бриф.
Понравилась статья?
Поделись материалом с другими в социальных сетях — сохрани статью себе для быстрого доступа, поддержи нашу студию!

Подпишись, чтобы быть в курсе!

Подпишись на наш новостной дайджест, чтобы первым получать анонсы новых статей, материалов или мероприятий. Без спама, только по факту =). Наши соцсети в конце сайта.
Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности.