Инструменты передачи проекта: от прототипа до файлов клиента
Почему передача проекта — это момент, где всё может пойти не так
Я видел, как проекты страдали на этапе передачи чаще, чем на любом другом этапе работы. Исследование прошло хорошо, дизайн прошёл хорошо, даже внутреннее согласование у клиента прошло гладко — а через три месяца кто-то открывает папку проекта в поисках файла с логотипом и находит сорок слоёв с именами вроде «Frame 47 copy 3» и ссылку на Figma, которая перестала работать, потому что тариф понизили. Работа была хорошей. Передача — нет. И в памяти клиента это одно и то же: работа была плохой.
Неприятная правда в том, что передача проекта — это этап, о котором дизайнеры заботятся меньше всего, а клиенты помнят дольше всего. Вы шесть недель шлифуете библиотеку компонентов и тратите два часа на её экспорт — и именно эти два часа определяют, сможет ли клиент поддерживать продукт без того, чтобы звонить вам по поводу каждого изменения цвета кнопки. Репутация фрилансера или небольшой студии строится не столько на глянце финальных экранов, сколько на том, насколько легко кому-то другому подхватить работу после вас.
Эта статья — об инструментах, которые делают передачу проекта пережить возможным. Причём не только для разработчиков, но и для самих клиентов, которые всё чаще задаются вопросом: «Что именно мы получили в собственность и где это лежит?» Я расскажу, что меняется в зависимости от того, кто принимает файлы, что покрывают встроенные инструменты Figma и где они заканчиваются, какие специализированные платформы для передачи проектов стоит знать, как документация и дизайн-системы работают сами по себе как артефакты передачи, и как упаковать всё «скучное» — шрифты, иконки, код, — чтобы ничего не потерялось после окончания контракта.
Передача проекта — это не один результат, а три разные аудитории
Самая большая ошибка в планировании передачи проекта — считать её единым событием с единым результатом. На практике вы передаёте проект как минимум трём разным аудиториям, и всем им нужны совершенно разные вещи.
Разработчику нужны спецификации, размеры, состояния и токены. Ему всё равно, каким был ваш процесс, ваш мудборд и три отвергнутых направления. Он хочет знать значение отступа, hex-код, начертание шрифта и что происходит при наведении, в неактивном состоянии и при ошибке. Дайте разработчику красивую презентацию в духе кейс-стади — и он пролистает её в поисках панели инспектора.
Внутренняя команда клиента — менеджер по маркетингу, основатель, штатный дизайнер, который присоединится через полгода — хочет рабочий файл, который можно открыть, понять и отредактировать без вас. Им важно знать, почему были приняты те или иные решения, а не только какими они были, потому что им придётся защищать эти решения перед своим руководством. Им нужна дизайн-система с названиями, понятными обычному человеку, а не «Ellipse 14».
Будущее агентство — то, которое заменит вас, будь то через год или через десять лет, — хочет реконструировать вашу логику по имеющимся свидетельствам. Им нужна история версий, им важно видеть, что пробовалось и было отброшено, и, прежде всего, им нужна чистая передача прав собственности без какой-либо зависимости от ваших личных аккаунтов.
Большинство фрилансеров готовят один результат и надеются, что он удовлетворит всех троих. Обычно это не работает. Решение — не утроить объём работы, а так структурировать один пакет материалов для передачи, чтобы каждая аудитория могла быстро найти свой слой информации. Это, по сути, задача информационной архитектуры, а не подбора инструментов. Но инструменты сильно влияют на то, насколько понятной получится эта архитектура.
Встроенная передача в Figma: что она решает, а где заканчивается
Для большинства студий, работающих в Figma, встроенные инструменты инспектора и Dev Mode действительно хороши и, вероятно, закрывают 70% того, что нужно компетентному фронтенд-разработчику, без покупки чего-либо ещё. Стоит точно понимать, что входит в эти 70%, потому что оставшиеся 30% — это как раз то место, где проекты тихо проваливаются.
Что панель инспектора и Dev Mode в Figma делают хорошо: измерения между элементами, экспортированные фрагменты кода CSS/iOS/Android для отдельных слоёв, цветовые значения в нужном вам формате, экспортированные ассеты в нескольких разрешениях и — что критически важно — живая ссылка, которая автоматически обновляется по мере внесения правок, так что никто не работает с устаревшим PDF. Маркеры статуса «готово для разработки» и аннотации в Dev Mode — это реальный шаг вперёд по сравнению со старым процессом скриншотов фреймов в документ Word. Если ваша аудитория передачи — это один достаточно опытный штатный разработчик, обычного доступа к Figma с местом Dev Mode часто достаточно, а покупка чего-то ещё — просто лишние расходы.
Где это заканчивается: инспектор Figma показывает, как выглядит компонент, но не почему он существует и когда его нужно использовать. Он не объясняет логику продукта — почему это состояние появляется только после трёх неудачных попыток входа, почему этот компонент меняет раскладку на экранах уже 375px, почему текст в CTA меняется в зависимости от тарифного плана. Эта логика живёт у вас в голове и в переписке в Slack, и если вы не запишете её где-то в доступном месте, она умрёт вместе с проектом. Dev Mode также предполагает постоянный доступ — как только у клиента заканчивается место в Figma или ваш аккаунт фрилансера убирают из файла, эта «живая документация» исчезает. У меня был случай, когда клиент отменил платный тариф Figma через девять месяцев после запуска ради экономии, не осознавая, что это также отрезало его собственному разработчику доступ к спецификациям для редизайна.
Практическое решение скучное, но эффективное: никогда не позволяйте доступу к файлу быть единственным артефактом передачи. Даже в проектах, полностью выполненных в Figma, экспортируйте статичную справку — PDF со стайлгайдом, README, страницу «о проекте» прямо в файле, — которая существует независимо от чьего-либо статуса логина. В Figma даже есть возможность опубликовать страницу в стиле «Sites» или экспортировать спецификации в PDF именно для этой цели; используйте её, даже если это кажется избыточным, пока у всех ещё есть доступ.
Когда одной Figma недостаточно
Бывают ситуации, когда встроенных инструментов Figma действительно не хватает, и стоит честно понимать, когда это так, а не покупать Zeplin просто потому, что «так все делают».
Самый очевидный случай — передача проекта нескольким сторонним подрядчикам: у клиента есть внутренняя команда разработки, отдельный подрядчик по QA и маркетинговое агентство, и все они работают с одним и тем же дизайном, но никому из них не следует давать права редактирования вашего рабочего файла. Именно здесь такой инструмент, как Zeplin, оправдывает себя — он делает снимок дизайна в конкретный момент времени, убирает поверхность редактирования и даёт каждой стороне доступ только для чтения к версионированному эталону, который не будет меняться под ними, пока вы продолжаете дорабатывать проект в Figma. Экспорт стайлгайда в Zeplin (цвета, текстовые стили, отступы в виде самостоятельного справочника) также действительно удобнее для нетехнических участников, чем «сырой» инспектор Figma, потому что подаётся как документация, а не как живой инструмент редактирования, который пугает людей, никогда не пользовавшихся Figma.
Другой случай: передача командам, работающим с инструментами, близкими к генерации кода, где нужен мост между дизайн-токенами и уже существующей дизайн-системой в коде — например, Supernova или Specify, которые синхронизируют токены (цвет, отступы, шкалы типографики) напрямую с кодовой базой в виде переменных, не давая дизайну и коду расходиться со временем. Это имеет смысл на более крупных, долгоживущих продуктах, где у клиента есть настоящая фронтенд-команда, поддерживающая библиотеку компонентов, а не на сайте-визитке из пяти страниц.
Третий случай, более распространённый во фриланс-работе, чем готовы признать агентства: «разработчик» клиента на самом деле — это no-code/low-code платформа: Webflow, Framer, Wized поверх Webflow или конструктор на WordPress. Здесь передача проекта — это вообще не документ со спецификациями, а рабочая сборка. В такой ситуации честный ответ таков: инструменты передачи Figma здесь почти неактуальны, а фактическим результатом является опубликованный проект в Webflow, перенесённый в собственное рабочее пространство клиента, с аккуратно названными стилями, символами и CMS-коллекциями. У меня были проекты, где я потратил на приведение в порядок названий классов Webflow для передачи больше времени, чем на визуальный дизайн, — потому что клиент, унаследовавший проект с сорока безымянными комбо-классами, окажется в худшем положении, чем клиент, унаследовавший чуть менее отполированную, но понятную структуру.
Общий принцип: добавляйте специализированный инструмент передачи, когда есть вторая сторона, которой нужен стабильный эталон только для чтения, отдельный от вашего рабочего файла, или когда конечная цель — не код, который пишете вы сами, а платформа со своей объектной моделью. Не добавляйте инструмент просто потому, что он считается отраслевым стандартом — для одиночного фрилансера, передающего проект одному разработчику на стороне клиента, лишний платный инструмент часто оказывается просто ещё одним логином, о котором потом забывают.
Документация — это результат работы, а не любезность
Артефакт, который отделяет передачу проекта, на которую клиенты жалуются, от той, за которую вас будут хвалить месяцы спустя, — это редко сам файл Figma. Это письменная документация вокруг него. И именно эту часть большинство дизайнеров пропускают, потому что она ощущается как домашнее задание после того, как «настоящая» работа уже сделана.
Полезный документ передачи проекта отвечает на вопросы, на которые файл ответить не может. В чём разница между основной и вторичной кнопкой и когда использовать каждую — не как они выглядят, а по какому правилу принимается решение. Что происходит с этой раскладкой на экране уже самого узкого спроектированного фрейма. Какой запасной вариант, если имя пользователя состоит из пятидесяти символов и ломает карточку, протестированную на имени «Анна К.». Что было намеренно оставлено за рамками проекта, чтобы никто через два года не принял осознанное решение за недосмотр, отлаживая, почему в процессе оформления заказа нет варианта для гостя. Последний пункт важнее, чем кажется — огромная доля разговоров вида «а почему вы не спроектировали X» возникает потому, что причина исключения X нигде не была записана так, чтобы клиент мог найти её позже.
Notion стал инструментом по умолчанию для такой документации не случайно: человеку без дизайнерского бэкграунда в нём действительно легче ориентироваться, чем в файле дизайна, он позволяет встраивать фреймы Figma и видео Loom прямо в страницу, и им можно поделиться простой ссылкой, вообще без необходимости иметь аккаунт в дизайн-инструменте. Типичная страница Notion для передачи проекта, которую я собираю, начинается с короткого резюме «что это за проект», затем идёт раздел с компонентами со скриншотами и правилами использования, раздел «известные ограничения и планы на будущее» и плоский список всех аккаунтов, файлов и мест хранения ассетов с информацией о том, кто чем владеет.
Confluence решает ту же задачу и является лучшим выбором именно тогда, когда клиент уже ведёт там свою инженерную документацию, потому что документы передачи проекта, которые лежат там, куда команда разработки уже привыкла заглядывать, действительно читают; документы в новом инструменте, о котором клиенту приходится вспоминать, забываются в течение месяца. Об этом стоит спросить прямо во время проекта: «Где ваши разработчики сейчас хранят техническую документацию?» — и разместить свои заметки о передаче там, а не там, где удобнее лично вам.
Короткая запись экрана в Loom, где вы проходитесь по прототипу и вслух объясняете логику взаимодействия, непропорционально эффективна по сравнению с затратами на её создание. Она передаёт тон и ход рассуждений, которые письменная спецификация неизбежно теряет, и в отличие от встречи, не требует согласования расписания — будущий сотрудник клиента посмотрит её тогда, когда понадобится, на скорости 1.5x, через полгода после того, как вы перестали отвечать на письма по проекту.
Дизайн-система как настоящий артефакт передачи проекта
Для любого проекта крупнее одностраничного лендинга самая выгодная инвестиция при передаче — это правильно структурированный файл дизайн-системы, потому что это артефакт, который продолжает окупаться каждый раз, когда клиент дорабатывает продукт уже без вас, а не только в момент самой передачи.
Здесь важно различие между «набором стилей» и настоящей системой. Набор стилей — это страница с цветовыми образцами и шкалой типографики: полезно, но это не остановит следующего человека, который через полгода создаст чуть-чуть неправильный оттенок фирменного синего. Настоящая система означает компоненты, построенные на реальных вариантах и авто-лейауте, с названиями на языке, понятном человеку без дизайнерского бэкграунда («Button/Primary/Default», а не «Group 218»), с задокументированными состояниями для каждого интерактивного элемента, и — это тот пункт, который обычно пропускают, — пометкой, какие компоненты заблокированы (не трогать, критично для бренда), а какие предназначены для расширения.
Переменные и свойства компонентов в Figma, ставшие мейнстримом за последние пару лет, — это то, что делает систему поддерживаемой так, как это было невозможно, когда все вручную управляли цветовыми стилями. Настройте семантические токены — surface, text-primary, border-subtle — вместо буквальных, вроде «gray-600», и будущий дизайнер клиента сможет сменить тему или подкорректировать оформление, не перелопачивая каждый фрейм. Это одно решение — токены вместо буквальных значений — вероятно, лучшие несколько часов дополнительной настройки, которые можно вложить в проект, потому что в демо оно незаметно, но на второй год работы становится решающим.
Storybook стоит упомянуть здесь как эквивалент на стороне кода, и его имеет смысл внедрять на проектах, где у клиента есть настоящая фронтенд-команда, создающая библиотеку компонентов, которая должна пережить память любого отдельного разработчика. Storybook документирует компоненты такими, какие они есть в коде, с живыми интерактивными примерами и элементами управления пропсами, и именно этот артефакт не даёт дизайну и реализации расходиться друг с другом при последующих редизайнах. Для сайта-визитки это избыточно. Для продукта с более чем горсткой экранов и несколькими разработчиками, работающими над фронтендом, это практически обязательно, потому что без него вопрос «что на самом деле поддерживает компонент Button» становится вопросом, ответить на который можно только построчным чтением исходного кода.
zeroheight стоит знать именно как золотую середину — он подтягивает документацию и спецификации прямо из Figma в брендированный отдельный сайт со стайлгайдом, по сути делая то же самое, что вручную собранная страница в Notion, но автоматически и синхронизированно с исходным файлом. Для агентств, которые регулярно передают дизайн-системы, это снимает значительную часть ручной работы по документированию, описанной в предыдущем разделе. Для одиночного фрилансера, делающего это пару раз в год, подписка, скорее всего, того не стоит — вручную собранная версия в Notion закрывает 80% задачи бесплатно.
Права собственности, доступ и то, что никто не считает «дизайном»
Последняя категория инструментов передачи проекта не выглядит эффектно, но именно она с наибольшей вероятностью приводит к реальному спору позже: кто чем владеет и где это на самом деле хранится. Это меньше про творческие инструменты и больше про администрирование аккаунтов, и именно здесь фрилансеры обжигаются чаще всего, потому что легко предположить, что «само как-нибудь разрешится».
Начните с универсального правила: всё, что покупается для клиента — шрифты, лицензии на стоковые фотографии, подписки на плагины, доменные имена, хостинг, — должно быть оформлено на аккаунт и способ оплаты клиента с самого первого дня, а не на ваш с обещанием «перевести потом». Именно на переводах всё и ломается: лицензия на шрифт, купленная под вашим аккаунтом Adobe, технически может оказаться вообще непереносимой в зависимости от условий шрифтовой студии, перенос домена может занять несколько дней и требует активного содействия текущего владельца, а если вы с клиентом расстаётесь на плохих условиях, это «потом» иногда просто никогда не наступает. Теперь я начинаю каждый проект с чек-листа из пяти пунктов, который отправляю клиенту до начала любых покупок: кто за что платит, под чьим аккаунтом, с передачей учётных данных через менеджер паролей, а не по почте.
Права собственности на команду и проект в Figma заслуживают того же подхода. Если вы создаёте проект внутри своей команды в Figma, клиент навсегда остаётся гостем, зависящим от статуса оплаты вашей команды и от того, продолжает ли существовать ваш аккаунт. Более чистая схема — пусть и требующая чуть больше настройки в начале — состоит в том, чтобы клиент сам создал свою команду (бесплатного тарифа обычно достаточно для небольшого бизнеса при текущих лимитах на файлы, хотя стоит проверять актуальные условия, поскольку тарифы Figma периодически меняются), а вы работали как участник внутри его пространства. По окончании проекта вы просто выходите — ничего никуда не нужно переносить. Я перешёл на эту схему после того, как место в команде клиента оказалось заморожено посреди проекта из-за спора по оплате между ним и не связанным с проектом подрядчиком, делившим то же рабочее пространство, и моя возможность передать финальные файлы застряла в этом на две недели.
Для ассетов и кода вне Figma общая облачная папка, принадлежащая клиенту (Google Drive, Dropbox — что угодно, чем они уже пользуются, не стоит вводить новый инструмент именно здесь), организованная по простой и скучной структуре, всегда лучше «умной»: исходные файлы, экспортированные продакшн-ассеты по платформам, шрифты с прикреплённой лицензионной документацией в PDF, единый README наверху, объясняющий, что находится в каждой папке, и — что критично — что НЕ включено и почему (например: «стоковые фотографии не включены — лицензированы только для использования на этом сайте, для другого использования требуется отдельная покупка»). Эта последняя пометка предотвращает конкретную, часто повторяющуюся головную боль: клиент повторно использует лицензированное стоковое фото в печатной рекламе через полтора года, получает юридическую претензию и не понимает, почему «дизайнер не предоставил полные права».
С репозиториями кода та же логика. Если вы или нанятый разработчик писали фронтенд-код, репозиторий должен находиться в организации клиента на GitHub или GitLab с первого же коммита, а не переноситься в конце из личного аккаунта — переносы могут сломать хуки CI/CD, ключи деплоя и историю задач так, что распутывать это потом действительно неприятно. Настройте всё правильно в первый же день, даже если это кажется излишней формальностью для проекта на три недели.
Чек-лист передачи проекта, который переживёт вашу недоступность
Всё описанное выше полезно только в том случае, если это собрано в повторяемый процесс, а не изобретается заново под давлением дедлайна в конце каждого проекта — а именно в этот момент качество передачи и склонно рушиться: все устали, клиент хочет запуститься, и «мы задокументируем это как следует на следующей неделе» тихо никогда не происходит.
У меня работает подход, при котором передача проекта строится как чек-лист, составленный на старте, а не в конце, — потому что половина пунктов в нём (владение аккаунтами, конвенции именования, где будет храниться документация) это решения, которые дёшево принять правильно в начале и дорого исправлять задним числом. Сам чек-лист совершенно не выглядит эффектно:
- Права собственности на файл дизайна подтверждены — под аккаунтом клиента, вы в роли участника, а не наоборот.
- Все платные ассеты (шрифты, стоки, плагины, домены) с первого дня куплены под аккаунтами клиента.
- Единое место документации выбрано заранее, в инструменте, которым уже пользуется команда клиента, а не в том, который удобен вам.
- Конвенция именования компонентов согласована и применяется последовательно, а не только в последнюю неделю перед сдачей.
- Записан видео-обзор прототипа и ключевой логики взаимодействия, сделанный, пока вы ещё помните собственные рассуждения.
- Явно составлен список «не включено / вне рамок проекта», чтобы пробелы читались как решения, а не как недосмотр.
- Назначено контактное лицо и план восстановления доступа на случай, если клиент потеряет доступ к чему-либо из перечисленного после окончания вашего сотрудничества.
Именно последний пункт большинство фрилансеров пропускают полностью, и именно за него клиенты благодарнее всего, когда он есть. Короткий абзац — «если вы потеряете доступ к команде в Figma, вот как восстановить права администратора; если истечёт лицензия на шрифт, вот шрифтовая студия и номер лицензии для повторной покупки» — стоит вам пятнадцати минут, а клиенту экономит по-настоящему нервный вечер через год.
Для всего этого не требуется экзотических инструментов. Большая часть того, что делает передачу проекта качественной, — это решения, принятые заранее о том, где что хранится и кому принадлежит, задокументированные простым языком с использованием инструментов, с которыми клиент уже немного знаком. Специализированные платформы — Zeplin, Storybook, zeroheight, Supernova — это ускорители для конкретных, более масштабных ситуаций, а не замена базовой дисциплине: записывать всё и с первого дня проекта держать права собственности там, где им положено быть. Наладьте эту дисциплину — и вы заметите кое-что конкретное: клиенты начинают рекомендовать вас другим клиентам не потому, что финальные экраны выглядели хорошо (это они и так ожидали), а потому что спустя полгода они всё ещё могли всё найти и понять, почему это было сделано именно так. А это, как оказывается, вещь куда более редкая и ценная, чем просто красивый дизайн.
