Дизайн-система сайта нужна далеко не каждому проекту: для сайта на 20 страниц она часто оказывается лишней работой за ваши деньги. Разбираем, где проходит порог окупаемости, из чего состоит минимальный вариант на переменных и почему у нас новая страница собирается за часы, а не за дни.
Разговор обычно начинается так: клиент видел презентацию дизайн-системы у крупного банка и хочет "чтобы у нас тоже всё было системно". Через две недели выясняется, что сайт состоит из главной, восьми страниц услуг и блога, обновляется раз в квартал, а делает всё один подрядчик. В такой ситуации система на 200 компонентов будет стоить дороже самого сайта и умрёт через полгода.
Но обратная крайность встречается чаще. Мы регулярно получаем на поддержку сайты, где на разных страницах живут четыре оттенка синего, три размера одной и той же кнопки и восемь вариантов отступа между блоками. Каждая новая страница там собирается вручную и всё равно выглядит чуть иначе, чем соседняя.
Что вообще называют дизайн-системой
Под этим словом понимают три разные вещи, и путаница в терминах стоит клиентам денег.
Гайдлайн - документ с правилами: какие цвета, какие шрифты, как пишем заголовки. Живёт в PDF или в текстовом файле. Полезен, но с сайтом никак не связан, поэтому расходится с реальностью через несколько правок.
UI-кит - набор готовых элементов в макете: кнопки, поля, карточки, шапка, подвал. Ускоряет работу дизайнера, но не верстальщика: в коде всё равно можно сверстать по-своему.
Дизайн-система - это когда правила и элементы связаны с кодом через переменные. Один и тот же цвет живёт в одном месте, а макет и вёрстка на него ссылаются. Меняете значение переменной - меняется весь сайт. Вот это уже экономит время, всё остальное экономит только на словах.
Из чего она состоит на практике
Минимально работающий набор выглядит так.
Палитра в переменных. Не "фирменный фиолетовый", а конкретный набор оттенков с именами. У нас на сайте это шкалы от 50 до 950: светлые оттенки для фонов, средние для акцентов, тёмные для текста. В коде цвет пишется именем переменной, а не кодом вроде #6E59A4. Правило простое: если в вёрстке встречается hex-код напрямую, система уже дала трещину.
Шкала отступов. Один шаг, обычно 4 или 8 пикселей, и набор кратных значений на его основе. Без шкалы верстальщик подбирает отступы на глаз, и в итоге между блоками оказывается то 38, то 42 пикселя. Разница не читается сознательно, но общее ощущение неаккуратности даёт.
Типографика. Пары "размер шрифта плюс межстрочный интервал" для заголовков разных уровней, основного текста, подписей. Плюс решение по самим шрифтам и их лицензиям, про это писали отдельно в статье про шрифты для сайта.
Сетка и брейкпойнты. Ширина контейнера и список точек, на которых меняется раскладка. У нас их пять: 720, 768, 1024, 1100 и 1200 пикселей. Когда точки заданы один раз, адаптив не приходится проверять заново на каждой новой странице.
Компоненты с состояниями. Кнопка описана не одной картинкой, а всеми вариантами: обычное состояние, наведение, нажатие, неактивная, с иконкой, на тёмном фоне. Именно состояния чаще всего забывают, и потом верстальщик придумывает их сам.
Правила иконок. Одна толщина линии, один размер сетки, один стиль. Иначе набор собирается из разных источников и выглядит как коллаж, что подробно разбирали в материале про заказ иконок и иллюстраций.
Тон текстов. Как обращаемся к посетителю, что пишем на кнопках, как формулируем ошибки в формах. Это часть системы, хотя про неё вспоминают в последнюю очередь.
Минимальная версия для небольшого сайта
Для сайта малого бизнеса всё перечисленное сводится к двум вещам: один файл переменных и примерно десяток компонентов.
Файл переменных - это 40-60 строк: цвета, отступы, радиусы скругления, тени, размеры шрифтов. Компоненты: кнопка в двух-трёх вариантах, карточка, форма, шапка, подвал, блок с заголовком и текстом, таблица, аккордеон для вопросов и ответов.
Всё. Больше для сайта на 20-30 страниц не нужно. Такой набор дизайнер и верстальщик собирают внутри обычного проекта, отдельной строкой в смете это добавляет порядка 20-40 тысяч рублей, а иногда не добавляет ничего, потому что аккуратный подрядчик так работает по умолчанию.
Как это устроено у нас
Наш собственный сайт собран ровно по этой схеме. Цвета и отступы лежат в отдельном файле переменных, поверх него один файл базовых стилей и один файл компонентов. Карточки, кнопки, секции с заголовками, блоки призыва к действию - всё описано один раз.
Практический эффект измеряется временем. Новая страница услуги или посадочная страница под рекламу собирается из готовых блоков за 3-5 часов вместо двух дней. Правка вроде "сделайте акцентный цвет теплее" занимает минуту: меняется одно значение, и оно расходится по всем страницам сразу.
Второй эффект менее очевидный. Когда набор блоков ограничен, дизайнер и заказчик перестают спорить о том, как оформить конкретный экран: берётся подходящий блок из существующих. Обсуждение смещается к смыслу текста и структуре страницы, а это как раз то, что влияет на заявки.
Когда система оправдана, а когда нет
| Ситуация | Нужна ли система |
|---|---|
| Один лендинг, дальше ничего не планируется | Нет, достаточно аккуратной вёрстки |
| Сайт на 15-25 страниц, обновления редкие | Только минимальный набор переменных |
| Сайт плюс несколько посадочных под рекламу | Да, окупается на второй-третьей странице |
| Новые страницы выходят каждый месяц | Да, экономия времени заметна сразу |
| Над проектом работает больше одного человека | Да, иначе стили разъезжаются |
| Редизайн планируется по частям, разделами | Да, система держит единый вид старого и нового |
| Интернет-магазин с каталогом и фильтрами | Да, там компонентов много по определению |
Простой ориентир: система начинает экономить деньги, когда страниц становится больше, чем может удержать в голове один человек, либо когда людей больше одного. Если и то и другое не про вас, хватит файла переменных.
Отдельный случай - планы на тёмное оформление. Если тёмная тема хотя бы обсуждается, переменные обязательны: без них её приходится верстать заново, о чём подробнее в разборе тёмной темы на сайте.
Главная ошибка: библиотека, которой никто не пользуется
Самый дорогой сценарий выглядит так. Дизайнер за полтора месяца рисует библиотеку на 200 компонентов, включая те, которых на сайте нет и не будет. Документация на 40 страниц. Через три месяца выходит новая страница, нужного компонента в библиотеке не оказывается, верстальщик делает по-своему. Ещё через полгода система и сайт не совпадают почти нигде.
Причина всегда одна: систему делали от идеала, а не от того, что реально есть на сайте. Рабочий подход обратный - сначала инвентаризация существующего, потом сокращение до разумного набора, и только потом добавление нового по мере необходимости.
Второй по частоте промах - система живёт только в макете. Красивая библиотека в Figma без связки с переменными в коде расходится с сайтом на первой же срочной правке. Про то, как связать макет и вёрстку, есть отдельный материал о передаче макета в вёрстку.
Кто её поддерживает
Система без ответственного умирает предсказуемо. Нужен один человек с правом сказать "нет, новый компонент мы не заводим, берём существующий". В студии это ведущий дизайнер или технический руководитель, на стороне клиента - маркетолог, который принимает работы.
Три правила, которые держат систему живой:
- Новый компонент заводится, только если существующие не подходят по смыслу, а не по вкусу.
- Любое новое значение цвета или отступа сначала попадает в файл переменных, потом в вёрстку.
- Раз в полгода набор пересматривается: то, что не использовалось ни разу, удаляется.
Третий пункт пропускают чаще всего, а он важнее первых двух: разросшаяся система перестаёт помогать примерно на сотом компоненте.
Порядок внедрения на существующем сайте
Если сайт уже работает, переделывать его целиком не надо. Порядок такой.
- Инвентаризация. Собрать скриншоты всех типов страниц и выписать, сколько на сайте фактически цветов, размеров шрифта, вариантов кнопок и отступов. Обычно цифры удивляют владельца сильнее любых аргументов.
- Сокращение. Свести найденное к разумному набору: 8-12 цветов вместо 30, 6-8 размеров текста вместо 15, 3 варианта кнопки вместо семи.
- Переменные. Вынести получившееся в отдельный файл и заменить в коде прямые значения на имена переменных. Внешне сайт при этом не меняется, и это правильный признак.
- Компоненты. Описать 10-15 блоков, из которых собираются страницы, вместе со всеми состояниями.
- Проверка на новой странице. Собрать одну реальную страницу целиком из системы и замерить время. Если получилось не быстрее прежнего, где-то ошибка в наборе.
- Постепенный перевод старых страниц. По мере плановых правок, а не отдельным проектом. Перед началом полезно свериться с прототипом сайта, если он сохранился: часто расхождения тянутся ещё оттуда.
Первые три шага для сайта на 30 страниц занимают у нас 15-25 часов работы. Это тот минимум, после которого дальнейшие правки становятся дешевле.
Кому это подходит
Дизайн-система - не признак солидности, а способ сократить время на каждую следующую страницу. Для одного лендинга она не нужна, для сайта с регулярными обновлениями или несколькими подрядчиками окупается быстро. Начинать стоит с малого: файл переменных и десяток компонентов дают большую часть выгоды при небольших затратах. Библиотека на 200 элементов, собранная от идеала, а не от реального сайта, не окупается почти никогда.
Если проект уже есть и хочется понять, что в нём стоит приводить к общему знаменателю, опишите задачу по пунктам в брифе: по ответам про объём, сроки и число подрядчиков обычно и видно, нужна система или хватит порядка в стилях.
