Проектирование и разработка пользовательского интерфейса: как наладить связь

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

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

От макета к общей рабочей среде

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

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

По данным отчёта Figma «State of the Designer 2024–2025», 84% дизайнеров взаимодействуют с разработчиками еженедельно. Сам факт регулярного контакта, конечно, не гарантирует согласованности: можно часто обсуждать макет и всё равно не договориться, что именно означает конкретный цвет или как ведёт себя компонент при длинном тексте. Полезнее смотреть на взаимодействие как на цикл: вопрос возникает, решение фиксируется, реализация проверяется, а найденное расхождение возвращается в общую систему.

На практике этот цикл удобно строить вокруг нескольких точек:

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

2. Во время проектирования участники сверяют ключевые компоненты и поведение, а не только расположение элементов. Вопрос «что увидит человек после ошибки?» для интерфейса важнее, чем спор о названии слоя в файле.

3. Перед сборкой команда фиксирует, какие параметры считаются общими: цвета, типографику, отступы, радиусы, правила состояний. Это снижает число догадок при верстке.

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

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

Дизайн-токены: общий словарь для интерфейса

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

Концепцию токенов впервые представила команда Salesforce в 2016 году при создании Lightning Design System. Сегодня удобнее думать о них как о слоях смысла. В распространённой трёхуровневой архитектуре есть базовые, семантические и компонентные токены. Она позволяет отделить конкретное значение от того, какую роль оно играет и где применяется.

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

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

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

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

JSON и DTCG: как договориться о формате

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

Общий формат хранения делает передачу понятнее и облегчает автоматизацию. 28 октября 2025 года группа W3C Design Tokens Community Group опубликовала спецификацию Design Tokens Format Module v2025.10 для хранения дизайн-токенов в JSON. Это спецификация Community Group; её не следует представлять как полную официальную рекомендацию W3C. Для команды практический смысл в другом: появляется ориентир, по которому проще обсуждать структуру данных и согласовывать обмен между инструментами.

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

Для рабочего процесса я советую закрепить простые правила:

• У токенов есть понятные имена, связанные с назначением, а не только с внешним видом. Название, описывающее роль, обычно легче переживает редизайн, чем название, привязанное к конкретному оттенку.
• В команде понятно, где находится источник актуальных значений. Макет, таблица и код не должны одновременно претендовать на роль единственной версии правды.
• Изменение токена сопровождается проверкой компонентов, которые его используют. Это помогает заметить неожиданные последствия до выпуска.
• Разработчик может сообщить о техническом ограничении до того, как оно превратится в скрытое упрощение. Если поведение компонента требует компромисса, команда выбирает его осознанно.

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

Доступность должна проходить через макет и код

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

WCAG 2.2 рекомендует для обычного текста минимальный коэффициент контрастности 4,5:1 по отношению к фону. Это конкретный ориентир для проверки текстовых сочетаний, но доступность интерфейса шире одной цифры: важны структура, понятность сообщений и возможность пользоваться элементами разными способами. В совместной работе дизайнера и фронтенд-разработчика контрастность стоит обсуждать вместе с цветами и состояниями, а не после их утверждения.

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

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

На ревью полезно разбирать не абстрактное «выглядит ли всё правильно», а конкретный маршрут человека: где он начинает действие, как понимает, что произошло, и что может сделать после ошибки. Такой вопрос одновременно помогает UX-проектированию и выявляет технические недочёты.

Еженедельный ритм вместо финальной передачи

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

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

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

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

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