Как согласовать UI-кит с клиентом, прежде чем переходить к макетам экранов

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

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

Почему макет без утверждённого UI-кита — это гонка за своим хвостом

Когда стили согласовывают по ходу проработки экранов, каждое решение принимается локально, применительно к одному конкретному макету. Клиент видит кнопку на экране №3 и просит сделать её темнее. Дизайнер меняет цвет, но на экранах №1 и №2 кнопка уже утверждена в прежнем виде. Формально правка выполнена, фактически в проекте появилось расхождение, которое кто-то должен заметить и устранить. Чем больше экранов готово к моменту такой правки, тем дороже откат назад.

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

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

Что именно входит в согласование UI-кита

Согласование UI-кита — это утверждение набора базовых решений, на которые опираются все макеты:

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

Каждое из этих решений фиксируется один раз и больше не пересматривается в рамках проекта, если только не меняется сам UI-кит целиком, осознанно и явно.

Когда проводить этот шаг

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

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

Как организовать само согласование, чтобы оно не превратилось в созвон на созвоне

Удобнее всего вынести все элементы UI-кита на один артборд (цвета, шкалу шрифтов, кнопки и поля рядом) и собирать комментарии прямо на нём. Клиент кликает по конкретному цвету или компоненту и оставляет замечание там же, а не в общем чате, где реплика быстро теряется среди других сообщений. Комментарий при этом привязан к токену или компоненту, а не к абстрактному «мне не нравится общий вид».

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

Что фиксировать как результат шага

Итогом согласования становится короткий документ или отдельный экран с принятыми решениями: утверждённая палитра, шкала шрифтов, состояния компонентов. На него можно сослаться в любой момент, если дизайн следующего экрана вызовет вопрос «а мы точно так решили?». Без такой фиксации утверждённый UI-кит живёт только в памяти участников обсуждения, а память, в отличие от зафиксированного решения, теряется при смене исполнителя или просто за несколько недель работы над проектом.

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