Дизайн-система сайта: как собрать, внедрить и принять работу

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

Что такое дизайн-система сайта и какую задачу она решает

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

Первый слой — токены. Это именованные значения: цвет, размеры шрифта, межстрочные интервалы, радиусы, тени, отступы. Вместо конкретного оттенка в макете появляется понятие «текст второстепенный», вместо числа — «отступ средний».

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

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

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

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

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

Задача бизнеса и границы решения

Прежде чем рисовать первый компонент, зафиксируйте, какую именно проблему решает система. От формулировки зависит объём работы.

Типичные задачи, которые ставят перед разработкой дизайн-системы для сайта:

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

Дальше описывают границы. Что входит в работу, а что нет. Например: входит библиотека компонентов для публичной части, не входит переработка личного кабинета; входит описание токенов, не входит полный редизайн. Такая рамка защищает обе стороны: заказчик понимает, что получит, исполнитель — где остановиться.

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

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

Карта компонентов: обязательный артефакт проекта

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

Что фиксируют в карте:

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

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

Токены и система отступов в веб-дизайне

Токены — это именованные значения, которые используются вместо конкретных чисел и оттенков. Вместо «серый #8A8A8A» появляется «текст второстепенный», вместо «16 пикселей» — «отступ средний».

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

Что обычно описывают токенами:

• цвет: основной, фоновый, акцентный, состояния, границы;
• типографика: размеры, насыщенность, межстрочный интервал;
• отступы и внутренние поля;
• радиусы, тени, границы;
• сетка и точки перелома.

Рабочее правило: если значение не описано токеном, оно не используется. Исключения допустимы, но их фиксируют отдельно, чтобы они не превратились в новую норму.

Компоненты состояния и правила использования

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

Для кнопки это обычное состояние, наведение, фокус с клавиатуры, нажатие, отключённое состояние и состояние загрузки. Для поля ввода — пустое, заполненное, фокус, ошибка, отключённое, подсказка. Для карточки — обычная, с наведением, выбранная, недоступная.

Правила использования отвечают на конкретные вопросы:

• когда берём основную кнопку, а когда второстепенную;
• сколько кнопок допустимо в одном блоке;
• что делать, если текст не помещается;
• как компонент ведёт себя на узком экране;
• какие состояния обязательны, а какие зависят от контекста.

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

Согласованность макетов и кода

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

Практический приём: имена токенов и компонентов в макете должны совпадать с именами в коде. Тогда при обсуждении «кнопка основная» все понимают одно и то же, и правка не превращается в переписку.

Отдельно договариваются о версионировании: как вносить изменения в систему, кто их утверждает и как об этом узнают те, кто уже собирает страницы. Без этого система быстро расходится с реальностью.

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

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

Когда дизайн-система нужна, а когда достаточно гайдлайна

Не каждому проекту нужна полноценная система. Ниже — ориентиры для решения.

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

Учебный пример: дизайн-система для каталога

Учебный пример. Данные условные и не описывают реальный проект.

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

Шаг 1. Собираем карту компонентов. В неё попадают карточка товара, плитка каталога, фильтр, пагинация, поле поиска, кнопки, поля формы, уведомления, хлебные крошки, меню. Для каждого указываем состояния и приоритет.

Шаг 2. Описываем токены. Цвета, типографика, отступы, радиусы, тени, точки перелома. Отдельно фиксируем систему отступов: конечный набор шагов, которыми пользуются все макеты.

Шаг 3. Рисуем компоненты в состояниях. Кнопки — шесть состояний, поля — шесть, карточка — четыре. Для каждого компонента указываем, как он выглядит на широком и узком экране.

Шаг 4. Переносим решения в шаблон сайта и шаблоны компонентов. Общая рамка — шапка, подвал, рабочая область — живёт в шаблоне сайта, а повторяющиеся элементы выводятся через шаблоны компонентов.

Шаг 5. Проверяем на трёх типовых страницах: список каталога, карточка товара, корзина. Смотрим, не появились ли новые оттенки и отступы, которых нет в токенах, и все ли состояния форм описаны.

Проверка результата. Берём страницу каталога и сверяем: цвета и отступы совпадают с токенами; у каждой кнопки есть все заявленные состояния; на узком экране ничего не ломается; тексты разной длины не разъезжаются. Если на странице появилось значение, которого нет в системе, — это повод либо добавить его осознанно, либо исправить макет.

Как проверить результат и принять работу

Приёмка идёт по карте компонентов и по токенам, а не по общему впечатлению. Ниже — рабочий чек-лист.

• Карта компонентов согласована и покрывает все типовые блоки публичной части.
• Для каждого компонента описаны состояния: обычное, наведение, фокус, нажатие, отключённое, загрузка или ошибка — там, где они применимы.
• Токены описаны и не дублируются: у каждого значения одно имя и одно назначение.
• Система отступов конечна и используется во всех макетах без исключений «на глаз».
• Компоненты проверены на широком и узком экране.
• Тексты разной длины не ломают вёрстку блоков.
• Имена токенов и компонентов совпадают в макете и в коде.
• Описан порядок внесения изменений в систему и ответственный за них.
• Исключения из правил зафиксированы отдельно и обоснованы.
• Есть короткая инструкция для тех, кто будет собирать новые страницы.

Если какой-то пункт не выполняется, это не обязательно ошибка — но это осознанное решение, и его стоит записать. Так приёмка превращается из спора о вкусах в сверку по списку.

Типичные ошибки и ограничения

Ошибки, которые встречаются чаще всего.

Система ради системы. Команда рисует десятки компонентов, которыми никто не пользуется. Причина — не определили задачу и границы.

Нет владельца. Изменения вносят все, утверждает никто. Через месяц в макетах живут три версии одной кнопки.

Только макет, без связи с кодом. Красивая библиотека в редакторе не помогает, если в шаблоне и шаблонах компонентов те же решения собирают заново.

Слишком много токенов. Когда значений десятки, ими перестают пользоваться и возвращаются к ручному подбору.

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

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

Нет версионирования. Изменения не фиксируются, и никто не знает, какая версия актуальна.

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работы, исполнителю нужен набор входных данных. Чем полнее он будет, тем точнее оценка.

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

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

FAQ