Передача дизайна инженерам – за пределами комментариев в Figma
Почему одних комментариев в Figma недостаточно для передачи дизайна инженерам и что на самом деле работает в небольших командах.
By Ellis Keane · 2026-04-06
Лучший инструмент передачи дизайна инженерам – тот, который инженеры никогда не открывают
Чем больше дизайнеры вкладывают в совершенствование передачи через Figma – авто-лейаут, дизайн-токены, аннотации режима разработчика, документация компонентов – тем хуже зачастую становится фактическая передача дизайна инженерам. Не потому, что дизайн-работа плоха – она обычно блестящая – а потому, что все эти усилия живут в инструменте, который инженеры посещают неохотно, бегло просматривают и затем закрывают, чтобы строить то, что, как им показалось, они увидели.
Я был по обе стороны. Начинал как дизайнер (ну, «дизайнер» – я делал сайты для ломбардов в Нью-Гэмпшире, так что будем щедры с этим званием), а сейчас пишу большую часть инженерного кода Sugarbug. Проблема передачи дизайна инженерам – не проблема инструментов, это проблема рабочего процесса. Информация существует, она просто в неправильном месте в неправильное время.
Типичная передача дизайна инженерам выглядит примерно так: дизайнер три дня полирует фрейм в Figma, добавляет двенадцать комментариев, объясняющих решения по отступам и крайние случаи, тегает инженера и ждёт. Инженер открывает Figma, смотрит на фрейм около девяноста секунд, думает «ладно, понял», закрывает вкладку и строит нечто на 80% правильное и на 20% неправильное – причём на исправление этих 20% уйдёт ещё неделя переписки. Двенадцать комментариев? Прочитал от силы четыре.
Передача дизайна инженерам – это не файл, который бросают через стену. Это контекст, который должен жить там, где работает инженер – в задаче, в PR, в коде – а не в дизайн-инструменте, который он посещает один раз.
Почему комментарии в Figma не подходят для передачи
Я пользуюсь Figma каждый день и искренне получаю удовольствие (что на этом этапе, вероятно, уже дефект характера). Но комментарии в Figma оптимизированы для совместной работы дизайнеров между собой, а не для передачи дизайна инженерам, и эта разница важнее, чем осознаёт большинство команд.
Фундаментальное несоответствие вот в чём: комментарии Figma пространственно привязаны к фреймам и компонентам. Они существуют внутри дизайн-файла. Но инженеры не работают внутри дизайн-файлов – они работают в задачах Linear, PR GitHub и своём IDE. Когда дизайнер оставляет комментарий на фрейме: «этот дропдаун должен сворачиваться на мобильных вьюпортах ниже 640px», эта информация теперь заперта в Figma. Она не становится задачей. Она не появляется в рабочем процессе инженера. Она существует в параллельной вселенной, которую инженер должен помнить посещать, а (вот что действительно важно) посещение Figma не является частью естественного рабочего цикла инженера, в отличие от проверки Linear или ревью PR.
Результат предсказуем: критические дизайн-решения теряются – не потому, что кто-то небрежен, а потому, что информация в неправильном инструменте. Это как оставить стикер на столе человека, который работает из дома.
Где дизайнеры оставляют контекст
- Комментарии Figma – пространственные, привязаны к фреймам
- Аннотации режима разработчика Figma – детальные, но требуют открытия Figma
- Треды в Slack – разговорные, через неделю не найти
- Документация дизайн-системы – обширная, но редко используется в ходе спринта
Куда инженеры реально смотрят
- Описание задачи Linear – первое, что читают перед началом
- Описание PR GitHub – ориентир во время реализации
- Комментарии в коде – обнаруживаются при ревью
- IDE – где проводят 90% времени
Что действительно работает (от того, кто делает и то, и другое)
За последний год создания Sugarbug я был дизайнером и (в основном) инженером, что означает – у меня был необычный опыт передачи самому себе и при этом потери контекста. Если я не могу вспомнить собственные дизайн-решения со вторника, то отдельный инженер точно не уловит всё из ветки комментариев в Figma.
Вот что реально сработало в нашем процессе передачи дизайна инженерам – и ничего из этого не связано с написанием лучших комментариев в Figma.
1. Записывайте дизайн-решение в задачу, а не в дизайн-файл
Прежде чем инженер начнёт строить, дизайн-контекст должен жить в задаче Linear (или в том, что использует ваша команда). Не ссылка на файл Figma с «смотри дизайн» – это отписка, и все это знают. Задача должна включать:
- Что: Скриншот или экспортированный фрейм (не ссылка на Figma – PNG, который инженер может увидеть, не открывая другой инструмент)
- Почему: Обоснование ключевых решений. «Мы выбрали выдвижную панель вместо модального окна, потому что пользователю нужно видеть список во время редактирования» – одно предложение, экономящее три раунда «почему не модальное окно?»
- Крайние случаи: Что происходит на мобильном? Что с длинным текстом? Что, если данных нет? Если вы об этом подумали, запишите. Если не подумали, так и скажите (честное «я ещё не придумал пустое состояние» полезнее молчания)
2. Ревью дизайна проходит в задаче, а не в Figma
Когда я получаю обратную связь по дизайну во время реализации, я хочу получить её в ветке задачи Linear, а не как комментарий в Figma, который я могу не увидеть два дня. Задача – мой единственный источник правды для работы: если обратная связь живёт там, я увижу её при следующей проверке задачи – а это несколько раз в день. Если она в Figma, я увижу её, когда случайно открою тот файл, а это может быть никогда.
Это не значит «никогда не используйте комментарии Figma». Они отлично подходят для совместной работы дизайнеров, для аннотирования конкретных визуальных деталей и для обсуждений самого дизайна. Но в момент, когда обратная связь превращается в «инженеру нужно что-то изменить», она должна перейти в инженерный рабочий процесс.
stat: "Большинство" headline: "комментариев в Figma оставались непрочитанными более 48 часов, когда мы полагались на них при передаче" source: "Опыт нашей команды за 3 месяца неформального отслеживания"
3. Замыкайте цикл скриншотами, а не предположениями
Самый дешёвый способ валидации передачи дизайна инженерам – скриншот. Когда инженер заканчивает реализацию компонента, он вставляет скриншот в PR или задачу и тегает дизайнера. «Это совпадает?» занимает десять секунд и ловит 20% расхождения до выпуска. Никаких совещаний, никакого ритуала сравнения в Figma – просто PNG и вопрос.
Мы начали делать это для каждого UI PR, и количество разговоров «это не соответствует дизайну» упало практически до нуля. Оставшиеся разговоры – это настоящие крайние случаи, которые дизайн не покрыл, и это нормально – это именно то, что стоит обсуждать, а не базовое «ты использовал отступ 16px вместо 12px».
4. Пусть контекст перетекает между инструментами автоматически
Здесь я упомяну Sugarbug, потому что мы буквально создали его для решения именно этой проблемы. Наш дизайнер оставляет комментарий в Figma об изменении отступов. Sugarbug подхватывает этот комментарий, связывает его с соответствующей задачей Linear и PR GitHub, и инженер видит его в своём рабочем процессе, не открывая Figma. Передача дизайна инженерам перестаёт быть ручным ритуалом копирования и становится чем-то, что просто происходит.
Но если вы не используете Sugarbug (а большинство из вас не используют – мы ещё до запуска), ручной вариант такой: назначьте кого-то «мостом передачи», кто ежедневно проверяет комментарии в Figma и копирует релевантную обратную связь в задачи Linear. Это утомительно, но работает, и бесконечно лучше, чем надеяться, что инженеры вспомнят заглянуть в Figma.
Если я не могу вспомнить собственные дизайн-решения со вторника, то отдельный инженер точно не уловит всё из ветки комментариев в Figma. attribution: Chris Calo
Ваш чек-лист передачи дизайна инженерам
Если вы вынесете из этой статьи одну вещь, пусть это будет вот что: решение – не лучшие инструменты (ну, не в первую очередь – хотя я один и создаю, так что имейте это в виду). Решение – установить нормы о том, где живут дизайн-решения, и убедиться, что это «где» – внутри естественного рабочего процесса инженера.
- [ ] Экспортируйте ключевые фреймы как PNG в задачу Linear (не просто ссылку на Figma)
- [ ] Запишите «почему» для каждого важного дизайн-решения в описании задачи
- [ ] Перечислите известные крайние случаи (мобильные, пустые состояния, длинный текст) – или явно отметьте, что ещё не решили
- [ ] Перенесите обратную связь по реализации из комментариев Figma в ветку задачи
- [ ] Требуйте скриншот в каждом UI PR до подтверждения дизайнером
- [ ] Назначьте «мост передачи», если у вас нет инструмента для автоматического связывания Figma и Linear
Часто задаваемые вопросы
Q: Почему комментарии в Figma не работают как инструмент передачи дизайна инженерам? A: Комментарии в Figma живут внутри дизайн-файла, отключённые от рабочего процесса инженеров. Инженеры работают в Linear, GitHub и своём IDE – не в Figma. Комментарий на фрейме не становится задачей, пока кто-то вручную его не скопирует, и этот ручной шаг – место, где передача дизайна инженерам рушится. Это не проблема людей, это проблема границ инструментов.
Q: Sugarbug автоматически связывает комментарии Figma с задачами в Linear? A: Да – это одна из конкретных проблем, для решения которых мы его создали. Sugarbug собирает комментарии из Figma и связывает их с соответствующими задачами в Linear и PR в GitHub, так что обратная связь по дизайну появляется в рабочем процессе инженера без копирования между инструментами. Мы сами пользуемся им каждый день, и разница (честно говоря) немного смущает, учитывая простоту идеи.
Q: Какой лучший процесс передачи дизайна инженерам для небольших команд? A: Запишите дизайн-решение в задачу Linear до того, как инженер начнёт строить. Укажите причину, а не только внешний вид. Если во время реализации обнаруживаются крайние случаи, обсуждайте их в ветке задачи – а не в комментарии Figma, который инженеру придётся искать. Самый простой процесс зачастую самый долговечный.
Q: Как справляться с изменениями дизайна после начала инженерной работы? A: Относитесь к ним как к изменениям объёма: задокументируйте изменение в задаче с чётким сравнением до/после, объясните причину и дайте инженеру оценить стоимость реализации перед принятием обязательств. Худшие провалы передачи случаются, когда изменения дизайна приходят как случайные комментарии в Figma к работе, которая уже построена – именно так вы получаете обиженных инженеров и разочарованных дизайнеров.
Получайте аналитику сигналов прямо в почту.