UI-kit и дизайн-система: зачем нужны и как собрать

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

31 августа 2026 Разработка 19 мин чтения

---

Что такое UI-kit и дизайн-система

UI-kit (библиотека элементов интерфейса) — набор готовых кнопок, полей ввода, карточек, иконок и заголовков, собранных в одном файле макетов. Дизайнер не рисует кнопку заново на каждом экране, а вставляет её из библиотеки. Это инструмент сборки: он экономит время и убирает случайные различия вроде отступа в 14 пикселей на одном экране и 16 на соседнем.

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

Разница видна на простом примере. В UI-kit лежат три кнопки: чёрная, серая и с рамкой. В дизайн-системе рядом с ними написано, что чёрная — главное действие на экране и оно на экране одно, серая — второстепенное, с рамкой — отменяющее. После этого новый дизайнер или разработчик собирает экран так же, как собрал бы автор системы, без совещаний и переписки.

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

Порядок появления в проекте обычно такой: сначала исследование и структура экранов, затем макеты ключевых сценариев, из них вырастает UI-kit, и уже он дорастает до системы с правилами. Обратный порядок — начать с описания правил до первых экранов — почти всегда даёт документ, который не совпадает с реальным продуктом. Подробно про подготовительную часть — в материале о вайрфреймах и в статье о подходе к UX/UI-дизайну приложения.

Что происходит с продуктом без общей системы

Отсутствие системы редко выглядит как авария. Оно выглядит как медленно растущие издержки, которые никто не относит к дизайну.

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

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

Кому нужна дизайн-система, а кому хватит UI-kit

Полная система нужна не всем. Ниже — ситуации, в которых она окупается, и ситуации, где достаточно аккуратной библиотеки элементов.

Система оправдана, когда:

• Продукт живёт в нескольких каналах. Мобильное приложение и сайт интернет-магазина, версии под разные магазины приложений, личный кабинет и витрина. Каждый дополнительный канал умножает цену расхождений.
• Над интерфейсом работает больше одного дизайнера. Двое уже договариваются устно; трое и больше — расходятся, если договорённости не записаны.
• Ассортимент и сценарии сложные. Каталог на десятки тысяч позиций, B2B-сценарии, доставка с ограничениями. Одних макетов ключевых экранов не хватает: нестандартных случаев больше, чем нарисованных.
• Продукт развивается постоянно. Регулярные выпуски новых функций, акции, сезонные разделы — новые экраны собираются каждый месяц.
• Планируется передача проекта. Смена подрядчика, приход своей команды, подключение дизайнера на время — без описанных правил новый исполнитель начинает с изучения чужих файлов.

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

Промежуточный вариант — начать с UI-kit и достраивать систему по мере роста: сначала токены и элементы, потом правила применения, документация — последней. Такой порядок позволяет не оплачивать сразу то, что понадобится через год.

Из чего состоит дизайн-система: четыре уровня

Удобно представлять систему как четыре слоя, где каждый следующий опирается на предыдущий.

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

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

Токены: язык значений вместо «этот серый»

Дизайн-токен — именованное значение, на которое ссылаются элементы: не «#1A1A1A», а «цвет основного текста»; не «16 пикселей», а «внутренний отступ карточки». Смысл в том, что название переживает значение: цвет можно поменять, имя остаётся, и всё, что на него ссылалось, обновляется само.

Базовый набор токенов для интерфейса магазина обычно выглядит так.

Два правила, которые экономят больше всего времени. Первое: токены называются по назначению, а не по внешнему виду. «Цвет предупреждения» переживёт смену палитры, «оранжевый-600» — нет, потому что через год предупреждение может стать красным, и название начнёт врать. Второе: значения выводятся из одного шага — если шаг сетки 4 пикселя, все отступы кратны четырём. Это убирает споры о том, 14 или 16, и делает вёрстку предсказуемой.

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

Компоненты: состояния, варианты, правила

Компонент в макетах — это не картинка кнопки, а кнопка со всеми предусмотренными видами. Именно неописанные состояния становятся источником вопросов на этапе разработки и доработок после приёмки.

Минимальный набор состояний, который стоит закладывать для интерактивных элементов:

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

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

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

Доступность и адаптивность как часть системы

Требования к контрасту и размерам удобно задавать один раз на уровне системы, а не проверять на каждом экране вручную.

Контраст. Международные рекомендации по доступности WCAG задают минимальное соотношение яркости текста и фона: 4,5 : 1 для обычного текста и 3 : 1 для крупного. Если пары «цвет текста — цвет фона» проверены на уровне токенов, дальше нечитаемое сочетание в макете не появится.

Размер области нажатия. Рекомендации платформ отличаются в деталях: Human Interface Guidelines Apple ориентируют на область не меньше 44 × 44 точки, рекомендации Android — на 48 × 48 независимых пикселей. В системе это закладывается в сам компонент: видимая иконка может быть маленькой, область нажатия — нет.

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

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

Как собрать дизайн-систему: шесть шагов

Порядок ниже одинаково работает и для нового продукта, и для интерфейса, который уже несколько лет живёт без правил. Разница в первом шаге: в новом продукте вместо инвентаризации проводится подготовка на основе сценариев.

Шаг 1. Инвентаризация

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

Шаг 2. Отбор

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

Шаг 3. Токены

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

Шаг 4. Компоненты

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

Шаг 5. Правила и документация

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

Шаг 6. Перенос в код

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

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

Как устроен файл в Figma

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

• Отдельный файл библиотеки. Токены и компоненты живут в собственном файле и публикуются как библиотека. Рабочие файлы экранов подключают её и не содержат собственных копий элементов.
• Переменные для значений. Цвета, отступы и размеры удобно хранить переменными и группировать по назначению — так поддерживаются темы и режимы (светлая, тёмная, разные плотности).
• Понятные названия. Имя компонента — то, как его называет команда вслух. Разработчик ищет «карточка товара», а не «Card / v2 / final».
• Версии и публикация. Изменения выходят пакетами с описанием, что поменялось. Дизайнеры экранов обновляют библиотеку осознанно, а не обнаруживают правки посреди работы.
• Права доступа. Редактировать библиотеку могут один-два человека, остальные пользуются. Это единственный надёжный способ не получить пять вариантов кнопки обратно.
• Страница «так — не так». Наглядные примеры применения экономят больше времени, чем текст правил.

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

Как система живёт в коде

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

Мы разрабатываем приложения и сайты на Flutter, и здесь связка получается прямой. Токены превращаются в описание темы оформления, из которого элементы берут цвета и стили текста; компоненты становятся переиспользуемыми виджетами. Поскольку из одной кодовой базы собирается и мобильное приложение, и сайт интернет-магазина, набор компонентов остаётся общим — правка кнопки применяется во всех каналах сразу, без параллельной работы двух команд. Это устройство мы разбирали в статье про создание веб-приложений; подробности по стеку — на странице Flutter-разработки для e-commerce.

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

Что стоит зафиксировать до начала переноса:

1. Источник истины. Где хранится эталон значений — в макетах или в коде, и в какую сторону идёт обновление. Двусторонняя правка без правил приводит к расхождению за пару месяцев.
2. Именование. Названия компонентов и токенов совпадают в макетах и в коде. Это единственный способ обсуждать интерфейс без скриншотов.
3. Порядок сверки. Кто и когда сравнивает собранный экран с макетом, куда попадает список расхождений.
4. Что делать с исключениями. Разовые отступления бывают всегда; важно, чтобы они помечались и попадали в разбор, а не оседали в коде молча.

Типичные ошибки

Список собран по проектам, которые приходили к нам на доработку и сопровождение после других подрядчиков. Все ошибки исправимы, но дешевле их не совершать.

1. Система начинается с документа. Правила пишутся до того, как собраны первые экраны, и не совпадают с продуктом. Работает обратный порядок: сначала рабочие решения, затем их описание.
2. Библиотека без состояний. Нарисовано обычное состояние, остальное додумывается в ходе разработки. Каждое додуманное состояние — потенциальная доработка после приёмки.
3. Копия вместо ссылки. Компонент не подключён из библиотеки, а вставлен копией. Внешне одинаково, но обновление до такого экрана не доходит.
4. Токены названы по цвету. «Серый-100» вместо «цвет второстепенного текста». После смены палитры названия начинают противоречить значениям.
5. Система не дошла до кода. Макеты аккуратные, интерфейс собран по-своему. Формально система есть, фактически её нет.
6. Нет владельца. Изменения вносит любой, кто открыл файл. Через несколько месяцев в библиотеке снова три вида кнопки.
7. Правила запрещают всё. Слишком жёсткая система мешает решать новые задачи, и команда обходит её. Работающие системы описывают, как отступать от правил, а не только как их соблюдать.
8. Сборка «на будущее». Компоненты рисуются под сценарии, которых в продукте нет. Половина библиотеки не используется, но поддерживается.

Кто владеет системой и как её поддерживать

Дизайн-система — не поставка, а продукт, у которого есть жизненный цикл. Без ответственного она устаревает за один активный квартал разработки.

Минимальный рабочий порядок выглядит так:

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

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

Как измерить пользу

Дизайн-систему сложно защитить перед бюджетом фразой «станет аккуратнее». Проверяемые показатели выглядят так.

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

Кто собирает: своя команда, подрядчик или дизайнер в аутстафф

Три рабочих варианта, и у каждого есть область, где он объективно сильнее остальных.

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

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

Сколько стоит и от чего зависит смета

Отдельной цены «дизайн-система под ключ» не существует: работа считается по составу. Ниже — факторы, которые двигают оценку сильнее всего.

1. Объём действующего интерфейса. Инвентаризация тридцати экранов и трёхсот — разные задачи. Для нового продукта этот пункт заменяется проработкой сценариев.
2. Количество каналов. Только приложение; приложение и сайт; плюс личный кабинет или административная часть. Каждый канал добавляет шаблоны и правила перестроения.
3. Число компонентов и вариантов. Базовый набор для магазина или расширенный с нестандартными блоками — карта магазинов, конструктор товара, сравнение моделей.
4. Глубина документации. Описания рядом с компонентами или полноценное руководство с примерами применения и правилами текстов.
5. Перенос в код и сверка. Самая недооценённая часть сметы и при этом та, без которой система остаётся файлом макетов.
6. Состояние исходных материалов. Есть ли действующий гайдлайн бренда, доступны ли исходные файлы предыдущего подрядчика, в каком виде живёт текущий интерфейс.
7. Дальнейшее сопровождение. Разовая сборка или ведение системы вместе с развитием продукта.

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

Если продукт запускается на нашей модульной платформе, дизайн-часть входит в этап интеграции: платформа даёт готовые модули — каталог, корзину, оплату, лояльность, — а оформление собирается под бренд. Модель оплаты состоит из трёх частей: единоразовая интеграция под бренд (до 30 рабочих дней), ежемесячные лицензионные платежи, в которые уже включены затраты на техническую поддержку команды FITTIN, и отдельно — новый функционал и доработки по фактически затраченным часам с оценкой перед стартом задачи. В направлении «только мобильное приложение» тариф ПРО — это интеграция от 525 000 ₽ и лицензия от 150 000 ₽ в месяц; в направлении «приложение и сайт на одной кодовой базе» — от 735 000 ₽ и от 250 000 ₽ в месяц (цены с НДС). Действующие тарифы и состав пакетов — на странице тарифов; ориентиры по бюджету именно дизайн-части разобраны в статье о стоимости дизайна приложения, а по обновлению действующего интерфейса — в материале о стоимости редизайна.

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

Как это выглядело на проектах

Несколько примеров из наших проектов, где единый набор компонентов решал разные задачи.

• Пан Чемодан — сеть магазинов сумок и чемоданов с бутиками в 40 городах. Бренду был нужен собственный визуальный язык, а не типовое оформление: приложение собрано с кастомным дизайном под фирменный стиль. Запуск занял 21 день, закрыто 193 задачи, показатели после запуска выросли на 5%.
• IDOL — премиальный fashion-проект с журнальной подачей каталога и отдельным сегментом VIP-покупателей. Здесь система понадобилась, чтобы выдержать нестандартную вёрстку витрин без потери единообразия: 2% покупателей в VIP-сегменте дают около 40% выручки, и их сценарии оформлены иначе, чем массовые.
• Сыроварня — первое мобильное приложение крупной ресторанной сети: конструктор блюда, оформление заказа в одном окне, бронирование столика. Нестандартные сценарии собраны из общего набора компонентов. Запуск занял 2 месяца, проект получил номинацию Workspace Digital Awards 2026.
• Street Beat — мультибрендовый магазин обуви и одежды с персонализированными витринами и анимациями интерфейса. За 5 месяцев после запуска пришло 130 000 новых пользователей органически, закрыто более 700 задач и выпущено 7 обновлений — при таком темпе выпусков библиотека компонентов и определяет скорость.
• Сатурн — сеть строительных магазинов в 20+ городах с каталогом свыше 30 000 товаров и сложными услугами вроде колеровки краски и распила материалов. Приложение вышло одновременно в четырёх магазинах приложений, за первый месяц — 7 594 установки при конверсии 12,4%.
• Finn Flare — перезапуск действующего приложения на Flutter с переносом оформления. Бюджет проекта оказался в 2,5 раза меньше, а скорость разработки — в 1,5 раза выше прежней, выпуск состоялся примерно за 30 рабочих дней.

Остальные проекты — в разделе кейсов.

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

UI-kit — библиотека элементов, дизайн-система — библиотека плюс значения, правила, документация и порядок изменений. Короткий порядок действий:

1. Проведите инвентаризацию. Пока не видно, сколько в интерфейсе вариантов одного и того же, обсуждать систему рано.
2. Вынесите значения в токены и назовите их по назначению. Это то, что позволит менять оформление правкой нескольких строк, а не обходом всех экранов.
3. Опишите состояния. Нажатие, недоступность, ожидание, ошибка, пустой список — здесь возникает большая часть доработок после приёмки.
4. Доведите систему до кода. Библиотека, которая не дошла до продукта, пользы не приносит.
5. Назначьте владельца и порядок изменений. Без этого система устаревает за один активный квартал разработки.

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

• Оценить текущий интерфейс и получить список расхождений — аудит UX/UI.
• Собрать систему и макеты продукта — разработка UX/UI-дизайна приложения и сайта; если интерфейс морально устарел — редизайн приложения и сайта.
• Усилить свою команду на время сборки — аутстаффинг UX/UI-дизайнеров; посмотреть кейсы или описать задачу через контакты.

Вопросы и ответы

Чем UI-kit отличается от дизайн-системы?

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

Нужна ли дизайн-система, если у нас только сайт и нет приложения?

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

Сколько стоит собрать дизайн-систему?

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

Можно ли взять готовую библиотеку вместо своей — Material или рекомендации Apple?

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

Что делать, если интерфейс уже большой и разъехался — переделывать всё сразу?

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

Кто владеет дизайн-системой после сдачи проекта?

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

Как понять, что система работает, а не лежит мёртвым файлом?

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

Можно ли взять дизайнера в команду только на время сборки системы?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.