Условная компания заказала красивый сайт. Через полгода на нём четыре зелёных, три формы кнопки «Обсудить» и два несовместимых способа показывать цену. Каждое изменение отдельно защищали разумно: здесь хотелось выразительнее, там быстрее, тут подрядчик принёс своё. В результате бренд выглядит так, будто отделы познакомились только в подвале страницы.
Дизайн-система сайта — согласованные правила, компоненты и способ их развития. Она связывает смысл, визуальные решения и работающий код: какие состояния предусмотрены, где элемент применяется, кто принимает изменения и как они попадают на страницы. Папка макетов или библиотека кнопок без правил использования ещё не решает эту задачу.
За что бизнес платит в дизайн-системе
Одинаковые отступы сами по себе редко интересуют собственника. Его интересуют скорость изменений, узнаваемость компании, понятный путь пользователя и стоимость сопровождения. Когда одно и то же решение каждый раз придумывают заново, оплачиваются повторные обсуждения, новая реализация, отдельная проверка и последующее исправление расхождений.
Представьте, что условия заявки меняются сразу на нескольких продуктовых страницах. В связанном наборе компонентов меняется общий блок и проверяются известные варианты. На независимых страницах нужно найти все версии, разобраться в локальных стилях и не забыть старый лендинг. Экономия здесь возможна, но её нельзя заранее объявить универсальным процентом: она зависит от реальной повторяемости и дисциплины выпуска.
Дизайн-система полезна и как язык решения споров. Вместо «мне этот зелёный кажется слишком спокойным» команда обсуждает роль цвета: действие, успех, выбранное состояние или декоративный акцент. В Fluent 2 Microsoft токены как раз описываются как именованные значения для цвета, типографики, интервалов и других свойств; семантический слой добавляет назначение значениям.
Это не означает, что вашему агентскому сайту нужен интерфейс Microsoft. Нужен принцип: отделить смысл решения от случайного числа в конкретном файле. Тогда фирменный характер можно сохранить, а изменения сделать управляемыми. Премиальность не возникает от количества редких компонентов. Чаще она держится на точности ограниченного набора решений.
Айдентика задаёт характер, система — поведение
Логотип, цвет и шрифт помогают узнавать компанию. На сайте к ним добавляются задачи: найти услугу, сравнить предложения, понять следующий шаг, отправить обращение. Красивый фирменный знак не объясняет, что происходит после нажатия кнопки. Поэтому дизайн-система должна включать поведение, а не только стилистическую витрину.
Бренд может быть технологичным и немного брутальным, но ошибка формы всё равно должна быть понятной. Металлическая графика и сложная анимация не освобождают интерфейс от подписи поля, читаемого текста и видимого фокуса. Если ради характера посетителю приходится угадывать действие, компания платит удобством за собственную презентацию.
Разделяйте постоянные признаки и область эксперимента. Например, типографическая иерархия, базовый контраст, логика ссылок и формат обращения могут быть общими. Графика продукта, композиция первого экрана и авторская анимация — различаться. Так сайт получает характерные страницы без ощущения, что каждая принадлежит отдельному подрядчику.
Для небольшого агентства полезен короткий документ с несколькими примерами: «Вот что делает страницу нашей», «Вот что можно менять», «Вот что проверяем всегда». Десять точных решений лучше ста страниц, которые никто не использует. При этом нельзя подменять документ коллекцией понравившихся сайтов: референс помогает объяснить приём, но не даёт правила его применения у вас.
Токены: почему зелёный должен иметь работу
Токен — имя для согласованного значения. На базовом уровне это может быть цвет или размер. На смысловом — цвет текста на действии, фон поверхности или интервал между смысловыми блоками. Удобство появляется, когда разработчик выбирает назначение, а не вспоминает, какой из нескольких похожих оттенков сейчас считается правильным.
Плохое имя «green-2» сообщает только положение в палитре. Более предметное «action-background» объясняет использование. Это не универсальная схема именования: проект может выбрать другую. Важно, чтобы система различала сырой цвет и его применение. Иначе после изменения акцентного оттенка одновременно позеленеют ссылки, ошибки и подписи на тёмной графике.
Типографические токены должны описывать реальные роли текста. Крупный заголовок, вводный абзац, основной текст, подпись и служебная метка могут иметь разные правила масштаба. На мобильном недостаточно пропорционально уменьшить всё. Нужно проверить переносы, длину строки, вертикальный ритм и то, не вытеснила ли эффектная фраза действие за несколько экранов.
Согласуйте также движение: длительность короткого отклика, появление раздела, остановку фоновой анимации и поведение при предпочтении уменьшенного движения. Эти параметры не обязаны быть одинаковыми. Им нужна иерархия. Когда всё непрерывно пульсирует, внимание перестаёт понимать, что главное. Технологичность превращается в выставку включённых приборов.
Не начинайте с сотен переменных на будущие случаи. Возьмите реально повторяющиеся решения и назовите их. Новый токен стоит добавлять, когда у него есть понятная роль и несколько применений либо важное отдельное ограничение. Иначе команда будет поддерживать словарь, который сложнее самого сайта.
У компонента есть договор, а не только красивое состояние
Компонент — повторно используемый элемент с предусмотренными вариантами и поведением. Для кнопки важны не только фон и скругление, но и наведение, клавиатурный фокус, ожидание, недоступность и результат действия. Для карточки услуги — допустимая длина названия, роль картинки, связь заголовка со ссылкой и поведение без изображения.
| Часть договора | Что определить | Что сломается без этого |
|---|---|---|
| Назначение | Какую задачу решает элемент | Один блок начнут использовать для разных смыслов |
| Варианты | Какие изменения поддержаны | Локальные стили разойдутся по страницам |
| Состояния | Ожидание, ошибка, пустой результат, успех | Реальное действие окажется вне макета |
| Контент | Длины, обязательные данные, резервный вариант | Редактор будет вручную спасать каждый перенос |
| Проверки | Ширины, ввод, устройства, доступность | Красивый десктоп станет единственным рабочим видом |
В критериях GOV.UK Design System компоненты оцениваются по полезности и уникальности предложения, а перед публикацией — по удобству, согласованности и применимости. Это пример зрелого процесса, не обязательный регламент для коммерческого сайта. Из него полезно взять вопрос: чем новый элемент лучше уже существующего и где проверена его работа?
Особенно внимательно относитесь к маркетинговым исключениям. «Эта карточка особенная» иногда означает самостоятельную продуктовую историю, а иногда — забытый общий стиль. Различить помогает задача. Если у Киры нужно показывать выбор видеопримеров, а у CRM — состояние работы агентов, разные демонстрации обоснованны. Но подписи, управление и доступность всё равно могут опираться на общие правила.
Тексты тоже участвуют в системе
Одинаковая кнопка с надписями «Начать», «Купить», «Обсудить» и «Получить расчёт» обещает разные действия. Если все четыре ведут к одной форме без объяснения, визуальная согласованность не помогает. Пользователь ожидает продолжения того разговора, который начался в блоке. Система должна связывать название действия, содержание формы и ответ после отправки.
Опишите короткие редакционные правила: как называются продукты, как обозначаются ограничения, где появляются условные примеры, какие утверждения требуют доказательства. Это не значит, что все страницы должны говорить одним синтаксисом. Авторский материал может быть живее коммерческого оффера. Общими остаются точность названий и честность обещания.
Контентные ограничения лучше проверять на реалистичных данных. Заголовок из двух слов ничего не говорит о карточке с длинным названием отраслевого решения. Пустой кабинет красив, но не показывает, что происходит с задачами, статусами и несколькими строками имени. Демонстрационные данные допустимы для проверки интерфейса; их нельзя выдавать за результат действующего клиента.
Для блога определите одну ось текста, иллюстраций, таблиц и оглавления. Разные типы материалов могут иметь разную композицию, но внутри статьи случайная смена ширины выглядит как ошибка. Подписи не должны быть светлее читаемого уровня только потому, что они «второстепенные». На мобильном особенно заметно, когда визуальная иерархия была нарисована, а не проверена.
Доступность превращается в повторяемую проверку
Когда цвет и состояние проверяют отдельно на каждой странице, ошибки повторяются вместе с копированием. Общий компонент позволяет исправить правило сразу для всех применений — при условии, что локальные стили его не перекрывают. Поэтому доступность имеет смысл включать в договор компонента, а затем дополнительно проверять на реальной странице.
Пояснение W3C к WCAG 2.2, критерий 1.4.3 указывает минимальный контраст 4,5:1 для обычного текста и 3:1 для крупного, с оговорёнными исключениями. Это конкретная проверяемая граница, но прохождение одного теста не означает доступность всего сайта. Нужны также навигация, фокус, масштабирование, содержание и поведение элементов.
Проверяйте пары цвета в контексте: основной текст на поверхности, подпись на картинке, ссылка в наведении, выбранная вкладка, кнопка поверх видео. Прозрачность и фоновые эффекты могут менять фактический результат. Красивый белый текст на светлом блике остаётся нечитаемым, даже если в дизайн-файле рядом записан правильный зелёный.
Для движения предусмотрите остановку и спокойный режим. Нельзя завязывать понимание услуги только на анимацию, которая может не запуститься. Содержательная подпись и статичный кадр должны сохранять смысл. Проектирование формы и её ошибок подробнее разобрано в материале о доступности заявки; дизайн-система здесь помогает повторно использовать уже проверенное решение.
Кто имеет право изменить общую кнопку
Без владельца развития система быстро превращается в музей. Команда либо боится что-либо менять, либо создаёт обходные версии. Нужен простой маршрут предложения: какая проблема обнаружена, где она повторяется, какие варианты рассмотрены, как проверяется изменение и кто принимает его в общий набор.
Владелец не обязан лично рисовать все элементы. Его задача — сохранять целостность решений и не допускать незаметных несовместимых изменений. Для небольшой команды это может быть совмещённая роль. Важно, чтобы она была назначена и имела время. Формальное «отвечают дизайнеры» часто заканчивается тем, что отвечать приходится разработчику в день релиза.
Разделите исправление дефекта, новый вариант и замену базового поведения. Первое может требовать быстрого выпуска. Второе — примера использования. Третье — проверки всех затронутых страниц и плана перехода. Не каждое изменение заслуживает большого комитета; не каждое изменение безопасно делать только на любимом лендинге.
Фиксируйте версию и список применений. Если старый компонент ещё существует, должно быть понятно, где он используется и когда будет заменён. Иначе «мы обновили дизайн-систему» означает только новую страницу документации, пока сайт продолжает жить на трёх поколениях карточек. Пользователь видит именно сайт, а не ваш аккуратный список намерений.
Когда система окупается, а когда это дорогая полка
Возьмём условную оценку: восемь страниц регулярно получают похожие изменения. Без общих компонентов на каждую требуется по два часа реализации и проверки; с системой — четыре часа на общее изменение и ещё четыре на проверки применений. В этом искусственном примере разница составляет восемь часов на цикл. Реальные затраты могут быть другими, включая разработку самого набора и обслуживание исключений.
Чтобы принять решение, соберите собственные случаи: сколько повторяющихся блоков, как часто они меняются, сколько времени уходит на поиск расхождений, сколько стоит регрессия. Затем оцените минимальный объём общей системы. Не нужно строить инфраструктуру крупного банка ради одного промолендинга с двумя формами, который перестанет существовать через месяц.
Одноразовой странице может хватить стилей, нескольких компонентов и короткой памятки. Растущему сайту с продуктами, блогом и разными исполнителями нужен более устойчивый набор. Корпоративному кабинету со сложными состояниями — ещё более строгие контракты. Масштаб решения определяется повторяемостью и риском изменений, а не желанием произнести «у нас собственная дизайн-система».
Отдельно учитывайте стоимость согласования. Если любой маленький вариант проходит многочасовую защиту, система тормозит работу. Тогда нужно упростить процесс и расширить разрешённые границы. Контроль качества полезен, пока он помогает выпускать проверенные решения, а не охраняет знакомую форму кнопки от реальной задачи пользователя.
Что проверять на макете, а что только в браузере
Макет позволяет оценить композицию, иерархию и согласованность состояний. Но он не показывает реальную загрузку шрифта, задержку видео, клавиатурную навигацию и содержание, которое редактор добавит через месяц. Поэтому приёмка системы должна включать работающий пример на настоящих ширинах, а не только презентацию библиотеки.
Возьмите длинный заголовок, несколько строк подписи, отсутствующее изображение и медленную загрузку. Проверьте, остаётся ли понятным следующее действие. Для сетки карточек важно не требовать от редактора одинакового количества букв в каждом названии. Если дизайн держится только на идеально коротких фразах, это условие нужно либо честно закрепить, либо изменить конструкцию.
Визуальные снимки помогают заметить регрессию, но не принимают решение за дизайнера. Одинаковая картинка до и после не доказывает правильную отправку формы. И наоборот, небольшое изменение переносов после обновления шрифта не обязательно ошибка. Проверки следует связать с договором компонента: что обязано сохраняться, что допускает вариативность и какое изменение требует ручного просмотра.
Как привести существующий сайт к общим правилам
Начните с инвентаризации работающих страниц. Соберите повторяющиеся блоки, состояния, цвета и текстовые роли. Отметьте расхождения и реальные дефекты отдельно: разные композиции не всегда ошибка, а нечитаемая подпись — вполне определённая проблема. Сначала исправляют то, что мешает пользоваться сайтом, затем приводят к общему набору повторы.
- Выберите несколько представительных страниц: главную, продукт, услугу, статью и форму.
- Определите устойчивые смысловые и визуальные признаки бренда.
- Выделите небольшой набор токенов и компонентов с реальными применениями.
- Опишите контент, состояния и ограничения каждого элемента.
- Перенесите один вертикальный сценарий целиком, включая мобильный вид.
- Сравните поведение до и после, исправьте регрессию и только затем расширяйте охват.
Не стоит одновременно менять все тексты, композиции, графику и код, если требуется понять эффект отдельного решения. Иногда большой редизайн необходим, но тогда нужно честно оценивать весь пакет и предусматривать возврат. Техническая проверка сборки не доказывает, что пользователи лучше понимают предложение. Для этого нужны наблюдения за задачами и корректно устроенное измерение.
При разработке и доработке сайта полезно заранее договориться, какие элементы становятся общими и кто поддерживает их после сдачи. Иначе новый подрядчик начнёт с очередного набора собственных компонентов, а бренд снова будет знакомиться с собой на каждой странице. Рабочая дизайн-система делает изменения предсказуемыми. Именно это даёт графике свободу быть выразительной, а интерфейсу — оставаться понятным.