Пару лет назад к нам пришел клиент после редизайна у другого подрядчика. На руках - PDF на 38 страниц, правки в Telegram, папка final_v7, а мобильная версия «примерно такая же». Через 2 недели разработки выяснилось, что фронтенд собирает главную по старому экрану, а часть решений вообще никто не зафиксировал.
Figma стала стандартом именно в таких историях. По сути, это облачный инструмент для UX/UI-дизайна, прототипирования и передачи макетов в разработку. Ценность не в том, что дизайнеру удобнее рисовать кнопки. Ценность в другом: бизнес, дизайнер и разработка перестают терять деньги на разрыве между обсуждением и реализацией.
Главный выигрыш - дизайн перестал жить в папках и чатах
До Figma дизайн сайта обычно распадался на набор файлов: Sketch, PSD, PNG, PDF, ссылки на облака, отдельные выгрузки для клиента и для разработчиков. Пока проект маленький, с этим еще можно жить. Когда появляются кабинет, адаптивы и несколько участников, версии начинают путаться, а команда ищет не решение, а «тот самый финальный файл».
В Figma у проекта появляется один рабочий документ. Комментарии, история изменений, статусы и сами экраны лежат в одном месте. Бизнесу нужен один источник правды, и Figma эту задачу закрыла лучше большинства старых инструментов.
У нас был редизайн корпоративного сайта для B2B-сервиса. В команде - продакт, UX/UI-дизайнер, 2 разработчика и клиентская сторона. Пока правки летали по почте и мессенджерам, один раунд согласования главной занимал 5-6 дней. Когда обсуждение перенесли в комментарии Figma, цикл сократился до 1-2 дней.
Самая дорогая ошибка в интерфейсном проекте - разрыв между решением, обсуждением и тем, что потом уходит в код.
Для бизнеса это прозрачность, а для команды - сохраненный контекст
Когда замечание висит прямо на кнопке, таблице или форме, не нужно разбирать голосовые и скриншоты с красными кружками. Каждый вопрос стоит в нужном месте. Если дизайнер выпал из проекта, команда не начинает почти с нуля - логика обсуждений остается в файле.
На одном e-commerce проекте менеджер раньше собирал замечания в Google Docs, потом переносил в чат, потом созванивался с дизайнером. После перехода в Figma число уточняющих сообщений по каждому экрану упало примерно на 40% уже в первый спринт.
Ниже разница без теории:
PDF/PNG-подход:
- несколько файлов
- версии путаются
- комментарии живут отдельно
- размеры снимают вручную
Figma-подход:
- рабочий файл в облаке
- актуальное состояние видно сразу
- комментарии в контексте
- спецификации доступны команде
Разработчики ценят Figma за нормальную передачу макетов, а не за красоту
Для фронтенда Figma давно стала рабочей документацией. Размеры, отступы, типографика, состояния кнопок, структура повторяющихся блоков - все видно без лишних созвонов. Если макет собран на Components, Variants, Libraries и Variables, команда кодирует систему, а не набор случайных экранов.
На SaaS-проекте с личным кабинетом мы собрали библиотеку компонентов еще до основной отрисовки экранов. Стек был прикладной и без экзотики - Laravel 11, PostgreSQL 16, Vue 3. После этого новые экраны дизайнер делал примерно на 25-30% быстрее, а визуальных багов на приемке стало меньше на 28%.
Dev Mode полезен по очень простой причине: разработчик быстрее понимает, что именно нужно собирать. Для бизнеса это не «фишка Figma», а минус лишние часы на синхронизацию.
На больших проектах разница уже считается неделями
Лендинг на 3-5 экранов можно собрать почти в любом инструменте. Как только у продукта появляются роли, адаптивы, A/B-тесты, формы с ошибками и новые сценарии, без системы начинается визуальный разнобой. Одинаковые элементы начинают отличаться на несколько пикселей, а изменения расползаются по файлам вручную.
У нас был продукт под NDA для логистики с интерфейсом на 40+ экранов. Клиент обновил бренд-стиль: цвета, типографику и паттерны форм. Через библиотеку Figma основную часть изменений внесли за 3 дня. Если бы это был набор картинок, команда потратила бы минимум неделю - и даже тогда оставался риск что-то забыть.
Как быстро понять, что подрядчик работает системно:
- есть библиотека компонентов, а не просто страницы с макетами;
- продуманы ошибки, пустые состояния и загрузка;
- мобильные версии собраны в том же файле;
- разработчикам отдают макеты через Dev Mode или другой канал передачи;
- ключевые сценарии показаны в прототипе.
Но Figma не лечит плохой процесс сама по себе
Мы тоже когда-то переоценивали аккуратный файл. На деле можно сделать очень чистую Figma и все равно провалить UX. Один кейс я до сих пор хорошо помню: подрядчик сделал редизайн сервиса заявок - современный стиль, хороший прототип, все красиво разложено по страницам. Команда при этом не проработала ошибки формы, повторную авторизацию, пустые таблицы и мобильный сценарий. После старта разработки вылезло 20+ незапланированных решений, сроки поплыли, а часть экранов дорисовывали уже под давлением запуска.
Проблема была не в Figma. Ее использовали как холст для картинок, а не как место, где проектируют систему и фиксируют решения.
Я сам не раз видел, как заказчик выбирает подрядчика по красивому PDF, потому что так проще сравнить варианты. Это понятная ошибка. Если попросить показать не экспорт, а рабочий файл Figma на реальном проекте, зрелость команды видна быстрее, чем по любому коммерческому предложению.
