Figma для продакта: что нужно знать

Зачем продакту Figma

Продакт не должен уметь рисовать в Figma. Продакт должен уметь её читать, оставлять полезные комменты и понимать, что в макете — пять минут работы, а что — переделка дизайн-системы. Если этого нет, общение с дизайнером превращается в пинг-понг «а здесь не так, переделай».

Боль без Figma-навыков выглядит так: дизайнер скидывает ссылку, продакт открывает, говорит «классно» и идёт писать ТЗ для разработчиков. Через неделю выясняется, что в макете нет пустого состояния, ошибки сети, лоадера и формы регистрации без интернета. Релиз сдвигается на спринт. Если бы продакт прошёлся по макету системно — вопросы всплыли бы заранее.

В этой статье — что именно нужно уметь продакту в Figma, без претензии на то, чтобы заменить дизайнера.

Как читать макеты

Figma-файл обычно устроен так: страницы (вкладки слева), на странице — фреймы (экраны), внутри фреймов — компоненты. Минимум, которому стоит научиться:

• Переключаться между страницами (фичи / архив / дизайн-система).
• Открывать панель свойств справа: размер, цвет, шрифт.
• Включать линейку и сетку, чтобы понимать, где отступы.
• Смотреть слои (layers) — что в каком порядке нарисовано.

Что обязательно проверять в каждом макете перед передачей в разработку:

• Все состояния: дефолт, hover, pressed, disabled, error.
• Пустое состояние, лоадер, ошибка сети.
• Длинные тексты — переносится ли, обрезается ли троеточием.
• Тёмная тема, если она у продукта есть.
• Адаптив: маленький экран, планшет.
• Локали: длинный немецкий перевод, RTL, если применимо.

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

Комменты и ревью макетов

В Figma есть встроенные комменты — кликаете на месте макета, пишете замечание, дизайнер видит. Это в десять раз эффективнее, чем «на втором экране в правом нижнем углу есть кнопка, переименуй её».

Хороший коммент:

• Указывает на конкретный элемент.
• Объясняет, что не так и почему.
• Предлагает решение или задаёт вопрос, а не приказывает.
• Помечен статусом (открыт / решён) — не оставляйте старые комменты висеть.

Плохой коммент: «не нравится». Дизайнер не телепат.

Если ревью макета большое — лучше сделать встречу с шарингом экрана, а в Figma оставить только итоговые правки. Так быстрее и без эмоций.

Дизайн-система и компоненты

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

Почему это важно продакту:

• Если ваша новая фича укладывается в существующие компоненты — это спринт работы. Если требует нового компонента — это уже месяц с учётом ревью, разработки и обновления библиотеки.
• Когда вы видите в макете что-то, чего нет в дизайн-системе — спросите, почему. Иногда обоснованно (новый паттерн), иногда дизайнер просто забыл взять из библиотеки.
• Системные компоненты гораздо проще тестировать и собирать аналитику — у них одинаковые имена событий и поведение.

Совет: попросите дизайнера показать вам страницу с компонентами один раз. Это сэкономит часы споров в будущем.

Прототипы и пользовательские тесты

В Figma можно собрать кликабельный прототип: связать экраны переходами, настроить анимации. Это полезно для:

• Демо стейкхолдерам — лучше показать прототип, чем пересказывать словами.
• Юзер-тестов — посадить пять человек и посмотреть, дойдут ли они до целевого действия.
• Внутреннего тестирования логики до разработки.

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

Частые ошибки

• Игнорировать состояния. Дефолтный экран — это 30% сценария. Без error/empty/loading продукт ломается на проде.
• Переписывать тексты сразу в Figma. Дизайнер обновит макет — все ваши правки потеряются. Тексты ведите в отдельной таблице или Notion.
• Не закрывать комменты. Через месяц никто не помнит, актуально это или нет.
• Открывать макет в режиме «view» и пытаться что-то менять. Просите права на комментирование заранее.
• Просить «уменьшить кнопку на 2 пикселя». Это работа дизайнера, не ваша. Сформулируйте проблему, а не решение.
• Передавать в разработку ссылку «вот тут вся фича». Разработчику нужны конкретные фреймы и спецификация, а не вся доска.
• Игнорировать responsive. Если приложение работает на разных экранах — макеты должны быть на основные брейкпоинты.

Связанные темы

• Как продакту работать с дизайнером
• Notion для продакт-менеджера
• Miro для продакт-менеджера
• Hotjar и аналоги: запись сессий

FAQ

Нужно ли продакту уметь рисовать в Figma?

Нет. Достаточно уметь читать, комментировать и понимать структуру файла. Рисование — работа дизайнера.

Figma бесплатная?

Есть бесплатный тариф с ограничением на количество файлов и редакторов. Командам продукта обычно нужен платный.

Чем отличается режим «view» от «edit»?

View — только смотрите. Comment — можете оставлять замечания. Edit — можете менять файл (но вам это не нужно).

Как передать макет в разработку?

В Figma есть режим Dev Mode: разработчик видит размеры, отступы, цвета, шрифты, может скопировать токены. Просто шарите ссылку на нужный фрейм.

Что делать, если дизайн-системы нет?

Это красный флаг для продакта. Без дизайн-системы каждый экран — переизобретение велосипеда, разработка дороже в разы. Подсветите проблему руководству.

Как организовать файлы Figma по продукту?

Обычно: один файл — одна крупная фича или раздел. Внутри — страницы по этапам (research, exploration, final, archive). Архивные версии не удаляйте — пригодятся для контекста.

---

Готовьтесь к собесу на продакта — откройте тренажёр с 1500+ вопросами по аналитике и продукту.