В день запуска всё обычно выглядит аккуратно.
Главная собрана. Услуги оформлены одинаково. Карточки ровные. Кнопки одного цвета. Заголовки находятся на своих местах. На мобильном ничего не вылезает за экран.
Проходит полгода.
Появляется новая услуга. Потом ещё три. Маркетолог просит добавить кейсы. Редактор публикует статьи. Для отдела продаж нужна новая посадочная. В одной карточке оказывается заголовок в две строки, в другой – в пять. Для новой страницы требуется таблица, которой раньше не было. Потом появляется второй вариант кнопки, новый цвет фона и «немного другой» блок преимуществ.
Через год сайт всё ещё работает. Но выглядит так, будто его собирали несколько разных команд.
Красивый макет ещё не означает масштабируемый сайт
Можно идеально нарисовать пять страниц. Значительно сложнее сделать так, чтобы через год на основе тех же правил можно было создать шестую, двадцатую и сотую страницу – и сайт при этом не начал визуально расползаться.
Макет страницы
Отвечает на вопрос: как должна выглядеть эта конкретная страница?
Система сайта
Отвечает на вопрос: по каким правилам должна выглядеть любая новая страница этого проекта?
Пока страниц мало, проблему почти не видно. Каждый новый экран можно вручную довести до идеального состояния. Но с ростом сайта стоимость такого подхода быстро увеличивается.
Поэтому уже на этапе создания сайта полезно думать не только о текущих макетах, но и о том, как проект будет расширяться после запуска.
Страница должна собираться, а не рисоваться заново
Обычную страницу услуги можно мысленно разобрать на повторяемые элементы.
Если эти элементы существуют как понятные компоненты, новая страница не создаётся с пустого листа. Меняется содержание и композиция, но базовая логика остаётся общей.
Если же каждая новая страница получает собственные кнопки, отступы, стили карточек, оформление заголовков и отдельные правила CSS, сайт постепенно превращается в коллекцию исключений.
Общие правила → компоненты → шаблоны → готовые страницы
Устойчивую систему удобно рассматривать по уровням. Они связаны, но решают разные задачи.
Общие правила
Цвета, типографика, размеры заголовков, ширина контента, отступы, радиусы, тени, ссылки, кнопки и правила адаптивности.
Компоненты
Кнопки, карточки, формы, FAQ, отзывы, таблицы, галереи, призывы к действию и другие повторно используемые элементы.
Шаблоны
Композиции компонентов для услуг, статей, кейсов, контактов и других устойчивых типов страниц.
После этого появляются готовые страницы – уже с конкретным содержанием, но без необходимости каждый раз заново изобретать оформление.
Общие правила уменьшают количество случайных решений
Вместо того чтобы каждый раз выбирать новый размер заголовка, оттенок синего или расстояние между блоками, лучше использовать ограниченный набор заранее определённых значений.
Типографика
Несколько уровней заголовков и понятная шкала основного текста.
Отступы
Системная шкала вместо случайных 17, 29, 41 или 53 пикселей.
Цвета
Основные, фоновые, акцентные и служебные цвета с понятными ролями.
Геометрия
Ширины, радиусы, тени, сетка и поведение на разных экранах.
Компонент – это элемент с назначением и границами
Хороший компонент – это не просто красивый кусок дизайна. Должно быть понятно, где он используется, какие варианты допускает, какое содержимое выдерживает, как ведёт себя на мобильном и когда его применять нельзя.
Назначение
Какую задачу решает элемент и в каких разделах он уместен.
Варианты
Какие состояния предусмотрены заранее, а какие уже требуют нового решения.
Ограничения
Какой объём контента, изображения и действия компонент способен выдержать.
Карточка статьи, карточка услуги и карточка сотрудника могут выглядеть родственными, но это разные сущности, потому что у них разные задачи и набор данных.
Шаблон страницы – не копия другой страницы
Шаблон определяет общую логику определённого типа материала. Например, страница услуги может использовать первый экран, описание, преимущества, этапы, кейсы, FAQ и форму. Статья будет собрана иначе. Кейс – ещё иначе.
Это важное отличие от подхода «скопируйте похожую страницу и поменяйте текст». При копировании вместе с содержанием часто переезжают локальные стили, старые исправления и исключения, которые были нужны только исходной странице.
Если архитектура разделов и страниц ещё не определена, сначала лучше разобраться со структурой сайта и навигацией. Здесь же речь уже о том, как готовая система выдерживает дальнейший рост.
А если все статьи, кейсы и страницы разные по объёму?
Это нормально. Дизайн-система не требует, чтобы все материалы были одинаковой длины или состояли из одного и того же набора блоков.
Один кейс может включать короткое описание задачи, три изображения и результат. Другой – подробную хронологию работы, восемь скриншотов, таблицу, сравнение «до/после», отзыв и FAQ. Обе страницы при этом могут оставаться частью одной системы.
Одинаковыми остаются правила
Типографика, ширина текста, оформление изображений, таблиц, цитат, карточек, кнопок и отступов работают по общей логике.
Разным остаётся содержание
Количество абзацев, изображений, доказательств, этапов, таблиц и дополнительных секций определяется задачей конкретного материала.
Хороший шаблон не должен заставлять текст помещаться в заранее заданное число секций. Он задаёт обязательную основу и набор дополнительных блоков, которые подключаются только там, где действительно нужны.
Обязательная основа
Например, для кейса – задача, выполненная работа и результат. Для статьи – понятная тема, основная часть и вывод.
Дополнительные блоки
Галерея, таблица, отзыв, FAQ, схема, сравнение, видео или дополнительный призыв добавляются по необходимости.
Без пустых мест
Если блока нет, шаблон не должен оставлять пустую область или требовать искусственно дописывать контент ради макета.
То же относится к повторяющимся элементам. Галерея должна нормально работать с двумя и восемью изображениями. Блок преимуществ – с двумя, четырьмя или шестью пунктами в предусмотренных пределах. Текстовый блок – с коротким пояснением и с большим разбором.
Дизайн-система небольшого сайта может быть компактной
Для обычного корпоративного проекта не требуется библиотека на сотни компонентов и отдельная команда дизайнеров.
Главное не количество правил. Главное – чтобы новые страницы создавались по существующим правилам, а новые решения появлялись осознанно.
Откуда появляются «почти одинаковые» элементы
Один из самых заметных признаков проблемы – дублирование компонентов.
Пять вариантов одной кнопки
Один радиус 10 px, другой 12 px, третий немного выше, четвёртый создан только для посадочной, пятый остался от прежнего разработчика.
Пять вариантов одной карточки
Формально элементы разные. По смыслу они решают одну задачу, но каждый новый участник проекта создаёт ещё одну версию.
В какой-то момент уже невозможно понять, какой вариант считается правильным. Новый специалист решает проблему самым быстрым способом – создаёт следующий.
Компонент нужно проектировать не под идеальный текст
Карточка может отлично выглядеть с заголовком «SEO-аудит сайта». Но через год в ней появляется название в четыре строки – и вся композиция ломается.
Если такой контент реалистичен для проекта, компонент должен быть готов к нему заранее.
Минимум
Короткий заголовок, нет описания, одна кнопка, нет изображения.
Максимум
Длинный заголовок, большое описание, дополнительная кнопка, несколько строк характеристик.
Разные изображения
Вертикальные, широкоформатные, без изображения или с важной частью у края.
Состояния
Обычное, наведение, фокус, ошибка, пустое состояние и мобильный экран.
Мобильная версия – часть компонента, а не исправление после разработки
Если карточка имеет три колонки на большом экране, заранее должно быть понятно, как они перестраиваются на планшете, во что превращаются на смартфоне, как ведут себя изображения, кнопки и длинные заголовки.
Слабая схема
Сначала сделали компонент, потом открыли мобильный экран и начали исправлять то, что сломалось.
Системная схема
Поведение на разных ширинах предусмотрено как часть самого компонента ещё до массового использования.
Тогда адаптивность перестаёт быть набором локальных исправлений.
Не каждый новый блок требует нового компонента
Перед созданием очередной карточки или кнопки полезно проверить:
- Какую новую задачу решает элемент?
- Почему существующий компонент не подходит?
- Отличие функциональное или только визуальное?
- Будет ли новый элемент использоваться ещё где-нибудь?
- Можно ли добавить допустимый вариант уже существующего компонента?
- Не превращаем ли мы текущий компонент в универсального монстра с десятками настроек?
Иногда новый компонент действительно нужен. Иногда достаточно варианта существующего. А иногда нужно просто использовать то, что уже есть.
CSS-костыль часто оказывается симптомом, а не причиной
Сам по себе дополнительный CSS не является проблемой. Проблема появляется, когда основная модель развития выглядит так: что-то не подходит – добавляем ещё одно исключение.
padding: 24px;
}
.page-422 .card {
border-radius: 12px;
}
.page-518 .button {
height: 52px !important;
}
Каждое правило решает локальную задачу, но одновременно уменьшает предсказуемость всей системы. Через некоторое время изменение общего компонента начинает ломать отдельные страницы, потому что на них лежат слои старых переопределений.
Один компонент постепенно превращается в десяток «почти одинаковых»
Визуальное расползание редко происходит одним большим решением. Обычно всё начинается с маленьких изменений: немного другой радиус, чуть больше отступ, второй оттенок кнопки, отдельный вариант для одной страницы.
Как WordPress превращается в набор исключений
WordPress сам по себе не заставляет сайт становиться хаотичным. Проблема возникает, когда одновременно используются стили темы, настройки редактора, стили плагинов, встроенные стили блоков, дополнительный CSS, индивидуальные шаблоны, конструктор страниц и ручной HTML – без общей системы.
Тогда один и тот же визуальный элемент начинает задаваться в нескольких местах. Отсюда знакомая ситуация: основной цвет кнопки изменили, но на части страниц она осталась старой.
Подробнее о возможностях и ограничениях самой CMS есть в материале «WordPress: преимущества, недостатки и кому подходит». Здесь важен другой вывод: технический инструмент помогает только тогда, когда сначала определены общие правила проекта.
Свобода редактирования должна иметь безопасные границы
На первый взгляд удобно разрешить менять любой цвет, размер текста, отступ, радиус и ширину. Но чем больше произвольных решений приходится принимать редактору, тем быстрее сайт теряет общий язык.
Лучше варианты
Размер секции: обычная / компактная / увеличенная. Фон: светлый / тёмный / акцентный.
Чем бесконечные настройки
Любой цвет, любой отступ, любой размер и свободная ручная настройка каждой страницы.
Редактор должен управлять содержанием и предусмотренными вариантами, а не заново проектировать интерфейс при каждой публикации.
Документация нужна не только крупным продуктам
Если правила компонента существуют только в голове первого разработчика, система уязвима. Через год другой специалист не знает, где элемент используется, можно ли вставить две кнопки, какого размера должно быть изображение и что произойдёт без описания.
Минимум для компонента
Название, назначение, состав, допустимые варианты и ограничения.
Поведение
Количество колонок, мобильная версия, допустимое содержимое и ситуации, когда нужен другой компонент.
Даже короткое описание значительно уменьшает количество случайных решений при дальнейшей поддержке сайта.
Новый компонент должен становиться частью общей системы
Представим, что сайту понадобился блок сравнения тарифов. Если это повторяемая задача, недостаточно один раз сверстать его на одной странице.
- Привести новый блок к общим стилям проекта.
- Проверить его на разных ширинах экрана.
- Проверить разные объёмы контента.
- Определить допустимые варианты.
- Добавить в общий набор компонентов.
- Зафиксировать правила использования.
Иначе через полгода другой специалист создаст второй блок тарифов – похожий, но уже не такой.
Можем ли мы собрать страницу, которой ещё нет?
Это один из лучших способов проверить систему до запуска. Не нужно ограничиваться утверждёнными макетами. Нужно придумать реалистичную страницу, которая появится через полгода, и попробовать собрать её из существующих компонентов.
Например, новой услуге понадобились:
Если всё собирается из существующей системы – хорошо.
Если внезапно нужны новый размер заголовка, другой контейнер, ещё одна карточка, уникальная мобильная логика и отдельный CSS, нужно понять причину. Возможно, появилась действительно новая задача. Но если так происходит с каждой страницей, проблема уже системная.
Что произойдёт, если завтра сайт вырастет в несколько раз?
Здесь проверяем не сервер и не количество записей в CMS, а устойчивость интерфейса.
- Заголовки одинакового уровня выглядят одинаково.
- Кнопки работают по одним правилам.
- Карточки используют ограниченный набор вариантов.
- Изображения имеют предсказуемые пропорции.
- Формы сохраняют единый внешний вид.
- Секции используют общую систему отступов.
- Мобильная версия остаётся стабильной.
- Новые страницы не требуют индивидуального CSS.
Если большинство ответов положительные, проект действительно готов к росту. Если почти каждая новая страница требует отдельной доработки – проблема уже существует, просто пока её скрывает небольшое количество материалов.
Что проверить перед передачей сайта
Глобальные правила
Определены цвета, типографика, размеры, отступы и сетка.
Компоненты
Понятно, какие элементы повторно используются и какие варианты допустимы.
Контент
Проверены длинные, короткие и пустые значения, а также отсутствие изображения.
Адаптивность
Определено поведение компонентов, а не только конкретных макетов страниц.
Шаблоны
Основные типы страниц создаются без новой разработки с нуля.
Передача
Другой специалист сможет понять основные правила проекта через год.
Полный редизайн нужен не всегда
Сначала полезно провести инвентаризацию повторяющихся элементов: сколько видов кнопок, карточек, размеров одинаковых заголовков, вариантов формы и локальных исправлений существует на сайте.
Из семи кнопок может оказаться достаточно двух. Из пяти похожих карточек – трёх. Одинаковые стили можно перенести в глобальные правила, а уникальные блоки привести к общим компонентам.
Если накопившиеся проблемы уже затрагивают код, шаблоны и множество локальных переопределений, такую нормализацию можно связать с технической оптимизацией сайта, но сама задача этой статьи остаётся шире – вернуть проекту единые правила развития.
Система не должна превращать сайт в конвейер одинаковых страниц
Есть страницы, где индивидуальная композиция оправданна: главная, важная рекламная посадочная, интерактивный сервис, калькулятор или крупная презентационная страница.
Но уникальная композиция не означает, что на ней должны появляться уникальные кнопки, поля формы, шрифты, базовые карточки, отступы и цвета.
Не нужна и чрезмерная бюрократия. Для небольшого корпоративного сайта достаточно компактной системы. Интернет-магазину с тысячами страниц потребуется больше состояний и шаблонов. Масштаб правил должен соответствовать масштабу проекта.
17 признаков масштабируемого сайта
- Есть единая типографика.
- Определены основные цвета.
- Используется ограниченная система отступов.
- Есть один понятный набор кнопок.
- Основные карточки являются повторно используемыми.
- Компоненты проверены с длинным и коротким контентом.
- Предусмотрено отсутствие изображения.
- Определено поведение при разном количестве элементов.
- Мобильная версия является частью компонента.
- Основные типы страниц имеют шаблоны.
- Новая страница не требует копирования старой вместе со всеми её исключениями.
- У редактора есть безопасные варианты оформления.
- Новые компоненты появляются по понятной причине.
- Базовые стили не дублируются по отдельным страницам.
- Ключевой элемент можно изменить глобально.
- Есть хотя бы минимальное описание важных компонентов.
- Сайт можно расширить без постоянного написания индивидуального CSS.
После серьёзного расширения проекта полезно пройти и общий чек-лист проверки сайта, чтобы отдельно проверить технические, SEO- и пользовательские последствия изменений.
Сайт редко разваливается за один день
Сначала появляется одна особенная кнопка. Потом немного другая карточка. Затем отдельный отступ, новый вариант заголовка и CSS специально для одной страницы.
Каждое решение кажется незначительным.
Через два года оказывается, что изменить один базовый элемент страшно, потому что никто не знает, где и что от него зависит.
Именно эта система позволяет проекту расти, не теряя собственного лица.
FAQ о компонентах, шаблонах и дизайн-системе
Что такое компонент сайта?
Повторно используемый элемент интерфейса с определённым назначением и правилами поведения. Например, кнопка, карточка, форма, FAQ, отзыв или блок призыва к действию.
Чем компонент отличается от шаблона?
Компонент является отдельным элементом интерфейса. Шаблон определяет, как несколько компонентов собираются в определённый тип страницы – например, услугу, статью или кейс.
Нужна ли дизайн-система небольшому сайту?
Да, но она не обязана быть сложной. Для небольшого проекта достаточно общих правил типографики, цветов, отступов, кнопок, карточек, форм и основных шаблонов страниц.
Нужно ли запрещать редактору менять дизайн?
Нет. Лучше определить безопасный набор вариантов. Редактор должен иметь возможность управлять содержанием и предусмотренными вариантами компонентов, не создавая каждый раз новую визуальную систему.
Почему плохо копировать существующую страницу?
Копирование часто переносит вместе с содержанием локальные стили, старые исключения и ошибки. Для повторяемых типов страниц надёжнее использовать общий шаблон.
Каждый новый блок должен становиться компонентом?
Нет. Новый компонент оправдан, когда появляется новая повторяемая задача. Одноразовое визуальное отличие ещё не означает необходимость создавать новую сущность.
Как понять, что дизайн-система уже развалилась?
Характерные признаки – много почти одинаковых кнопок и карточек, разные размеры одинаковых заголовков, локальные CSS-исправления, невозможность глобально изменить элемент и необходимость отдельно верстать почти каждую новую страницу.
Можно ли привести уже работающий сайт к системе без полного редизайна?
Да. Обычно начинают с инвентаризации повторяющихся элементов, объединяют дубли, фиксируют глобальные правила и постепенно заменяют частные реализации общими компонентами.
Должны ли все статьи и кейсы иметь одинаковую структуру?
Нет. Одинаковыми должны быть правила оформления и поведения компонентов, а не количество текста, изображений и секций. Шаблон может иметь обязательную основу и дополнительные блоки, которые используются только там, где они действительно нужны.
Сайт должен выдерживать не только запуск, но и собственный рост
Сегодня на нём десять страниц. Завтра – двадцать. Через два года – сто.
Если сотая страница по-прежнему выглядит частью того же проекта, а её создание не потребовало очередной пачки локальных исправлений, значит система была спроектирована правильно.
Если же сайт уже начал расползаться, необязательно переделывать всё с нуля. Можно разобрать существующие шаблоны и компоненты, убрать дубли, определить общие правила и привести дальнейшее расширение к понятной системе.
Поможем вернуть проекту единую систему и подготовить его к дальнейшему росту
Разберём существующие страницы, повторяющиеся блоки и локальные стили, определим, что можно объединить, какие компоненты действительно нужны и как собирать новые страницы без очередного слоя исключений. Если проект только разрабатывается, заложим эти правила до запуска.