Дизайн-система для сайта и приложения: как согласовать интерфейсы и ускорить изменения

11.11.2026 Эксперт 18 мин чтения

---

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

Что такое дизайн-система для сайта и приложения

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

Три слоя системы

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

Дизайн-система, UI-кит и брендбук: что из чего следует

Чем различаются брендбук, UI-кит и дизайн-система

Критерии, при которых дизайн-система оправдана

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

При одном-двух совпадениях достаточно UI-кита с описанными состояниями. Начиная с трёх поддержка разрозненных макетов обходится дороже системы: каждая правка превращается в сверку экранов между командами.

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

Токен — именованное значение, на которое ссылаются и макет, и код. Вместо кода цвета в двадцати слоях макета и в двух файлах стилей появляется имя вида color.action.primary с одним значением за ним.

Группы токенов, без которых система не работает

• Цвет — текст, фон, границы, статусы: успех, предупреждение, ошибка.
• Типографика — размер шрифта, межстрочный интервал, насыщенность.
• Отступы и сетка — шаг отступов и внутренние поля компонентов.
• Радиусы и тени — скругления и уровни подъёма элементов.
• Длительности анимации — переходы между экранами и состояниями.

Уровни токенов

Два слоя имён и зачем нужен второй

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

Перенос значений в код

Автоматической цепочки между редактором макетов и кодом по умолчанию нет: значения переносит разработчик вручную, хотя и без пересоздания компонентов. Сократить эту работу помогает единый формат описания токенов — Design Tokens Community Group ведёт открытую спецификацию (tr.designtokens.org, черновик, проверено 28 октября 2026 года). Практический минимум: файл токенов лежит в репозитории рядом с кодом, имена согласованы один раз, а дизайнер при правке меняет значение, а не придумывает новое имя.

Компоненты и их состояния

Компонент — элемент интерфейса, который повторяется в разных сценариях и имеет собственные состояния: кнопка, поле ввода, карточка товара, строка фильтра, всплывающее сообщение. Конкретный экран оплаты компонентом не считается — он состоит из компонентов и описывается правилами раскладки.

Состояния, которые описывают обязательно

• Обычное.
• Наведение курсора и нажатие.
• Фокус с клавиатуры.
• Отключённое.
• Загрузка.
• Ошибка.
• Пустое значение — для компонентов, которые показывают данные.

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

Состояния ошибок и пустых экранов

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

Два требования здесь совпадают с проверяемыми критериями доступности: ошибку нужно описать текстом (критерий 3.3.1 WCAG 2.2) и, где возможно, подсказать способ исправления (критерий 3.3.3). Сценарии, на которых проверяют эти состояния в e-commerce, разбираются в материале про сценарии UX-аудита корзины.

Адаптивность: сетка, точки перелома, плотность

Адаптивность в системе описывают правилами, а не набором макетов под модели устройств: какая сетка работает на каждой ширине, в какой момент раскладка перестраивается и как меняется плотность элементов.

Сетка и точки перелома

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

Плотность и масштаб шрифта

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

Различия сайта и приложения: что не переносится экран в экран

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

Различия, которые описывают для каждой среды отдельно

Последняя строка влияет на устройство системы сильнее остальных. На сайте правка компонента доходит до пользователя в день выпуска, в приложении — после проверки в сторах и обновления у пользователя. Поэтому в системе описывают поведение компонента в прежней версии приложения: интерфейс остаётся работоспособным, пока обновление дойдёт до всех. Та же логика действует при переносе данных между версиями — её разбирает материал про перенос приложения на новый backend, а согласованность каналов продаж — материал про омниканальную архитектуру для ритейла.

На общей кросс-платформенной базе (например, на Flutter) библиотека компонентов в коде может быть одна, но правила раскладки и навигации всё равно описываются для каждой среды. Критерии выбора между кросс-платформенной и нативной разработкой на Kotlin и Swift собраны в матрице выбора для интернет-магазина.

Доступность: требования, которые можно проверить

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

Проверяемые требования доступности и способ проверки (WCAG 2.2, проверено 28 октября 2026 года)

Что проверяют в готовом интерфейсе

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

Этап 1. Инвентаризация интерфейсов

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

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

Что получится: таблица расхождений и согласованный перечень компонентов, с которого начинается библиотека.

Этап 2. Токены и правила

Что происходит: дизайнер и разработчик договариваются об именах и структуре значений. Имена важнее значений: значение меняется за минуту, переименование расходится по макетам и коду.

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

Что получится: файл токенов и документ с правилами именования, одинаковый для макетов и кода.

Этап 3. Библиотека компонентов

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

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

Что получится: библиотека компонентов в макетах, по которой разработчик реализует экран без вопросов к дизайнеру по каждому отступу.

Этап 4. Перенос библиотеки в код

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

• Файл токенов в репозитории и подключение его к стилям.
• Компоненты в коде сайта и в коде приложения.
• Страница-витрина с компонентами и их состояниями для проверки.
• Сверка готового интерфейса с макетом по отступам, контрасту и размеру целей нажатия.
• Требования к интерфейсу в техническом задании на новые экраны — как это описывают, разобрано в материале про техническое задание на e-commerce-приложение.

Что получится: две кодовые библиотеки с общим файлом токенов и витрина компонентов, на которой видно расхождения.

Этап 5. Версии, поддержка и обучение команды

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

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

Что получится: работающий регламент: правка в библиотеке доходит до интерфейса предсказуемым путём, а исключения видны и посчитаны. Близкая по смыслу задача — зафиксировать обязательства по поддержке; её разбирает материал про обязательства SLA на поддержку приложения.

Маршрут согласования изменений

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

1. Заявка на изменение. Автор описывает сценарий: что пользователь не может сделать сейчас.
2. Проверка существующих компонентов. Владелец библиотеки смотрит, закрывается ли сценарий тем, что уже описано: шаг отсекает дубли, из которых вырастают расхождения.
3. Решение о типе правки. Варианта четыре: значение токена, новое состояние существующего компонента, новый компонент, разовое исключение вне системы.
4. Правка в библиотеке макетов. Дизайнер вносит изменение и описывает затронутые состояния.
5. Версия библиотеки. Изменение попадает в выпуск с перечнем правок — команды видят, что поменялось.
6. Перенос в код. Разработчики сайта и приложения обновляют библиотеки у себя.
7. Проверка перед выпуском. Тестировщики проходят затронутые экраны в двух средах, включая ошибки и работу с клавиатурой.

Кто принимает решение

• Дизайнер — владелец библиотеки макетов. Состав компонентов, имена токенов, описание состояний.
• Разработчик — владелец библиотеки в коде. Значения в коде, реализация компонентов, версии пакета.
• Руководитель направления или владелец продукта. Продуктовое решение: нужен ли новый тип экрана и когда изменение выходит.

Что измерять

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

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

Итог: дизайн-система на одной странице

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

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

Что делать дальше

Начните с инвентаризации: соберите фактические значения и расхождения по двум средам — этот документ сразу показывает объём работы. Если интерфейс уже работает и вопрос в потерях на пути к оплате, посмотрите сценарии UX-аудита корзины. Если впереди новый продукт, начните с требований — их состав разобран в материале про техническое задание на e-commerce-приложение, а оценку эффекта — в материале про окупаемость мобильного приложения.

Источники

• Web Content Accessibility Guidelines (WCAG) 2.2, W3C — критерии 1.4.3, 1.4.11, 2.4.7, 2.4.11, 2.5.8, 3.3.1, 3.3.3. Проверено 28 октября 2026 года.
• Understanding SC 2.5.8: Target Size (Minimum), W3C WAI — пояснение к требованию 24×24 CSS-пиксела. Проверено 28 октября 2026 года.
• Design Tokens Format Module, Design Tokens Community Group — черновик спецификации формата токенов. Проверено 28 октября 2026 года.
• Apple Human Interface Guidelines — раздел о целях нажатия и безопасных зонах. Проверено 28 октября 2026 года.
• Material Design 3, Google — разделы о доступности и размерах целей нажатия. Проверено 28 октября 2026 года.

Обсудить задачу

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