Figma для PM нужна не для того, чтобы самому проектировать интерфейсы. Она нужна, чтобы читать продуктовое решение напрямую: видеть сценарий, структуру экрана, предполагаемое поведение, пользовательский путь, объём изменений и точки, где delivery-реальность может начать расходиться с дизайном и ожиданиями стейкхолдеров.
Зачем PM использует Figma
- понимать, что именно команда собирается реализовывать;
- лучше согласовывать объём и последствия изменений;
- замечать разрывы между дизайном, требованиями и delivery;
- упрощать диалог между дизайнером, продуктом, аналитиком и разработкой.
Что нужно уметь на базовом уровне
- читать макеты и основные пользовательские сценарии;
- видеть различие между концептом, рабочим дизайном и финальным согласованным решением;
- задавать вопросы по объёму, сложным состояниям и спорным местам;
- не путать просмотр дизайна с его утверждением без контекста.
Что нужно уметь на сильном уровне
- использовать Figma как инструмент снижения неопределённости перед delivery;
- замечать места, где красивое решение может иметь дорогую цену реализации;
- связывать увиденное с требованиями, приоритетами и планом;
- вести согласование так, чтобы дизайн не жил отдельно от проектного контура.
В каких сценариях инструмент полезен
- обсуждение и согласование новых пользовательских сценариев;
- подготовка команды к реализации изменений;
- выравнивание понимания между продуктом, дизайном и delivery;
- анализ того, что именно меняется и как это влияет на scope.
В каких сценариях он перегружает процесс
- если PM уходит в микродетали дизайна без управленческой пользы;
- если дизайн на проекте играет второстепенную роль и не влияет на delivery-контур;
- если Figma становится местом бесконечных комментариев без принятия решения.
Типовые ошибки использования
- смотреть на экран, но не уточнять поведение и нестандартные состояния;
- согласовывать визуал без связи с требованиями и сроками;
- подменять разговор о продуктовой ценности спором об интерфейсных мелочах;
- считать, что наличие макета автоматически означает ясность для delivery.
Как PM работать с Figma прикладно
1. Сначала определить, что именно нужно понять: scope изменения, пользовательский сценарий, спорные места требований или цену реализации. 2. Пройти по основному сценарию и отдельно проверить пограничные состояния, пустые состояния, ошибки, разрешения и роли. 3. Сверить увиденное с фиксацией требований и тем, что реально попало в delivery-контур. 4. Отдельно вынести вопросы по зависимостям, компромиссам и зонам, где дизайн может конфликтовать со сроком, ресурсом или техническими ограничениями. 5. Зафиксировать вывод не в комментариях ради комментариев, а в понятном follow-up: что согласовано, что нужно уточнить, что влияет на приоритет или план.
Как понять, что здесь есть пробел
- после просмотра макета PM всё ещё не может объяснить, что именно меняется для пользователя и для delivery;
- в работу уходят дизайны без ясности по состояниям, ограничениям и объёму;
- спорные места обнаруживаются уже на реализации, а не на чтении решения;
- Figma используется как витрина, а не как источник управленческого контекста.
Чем можно заменить
- структурным документом и сценариями, если дизайн-контур слабый или ещё не оформлен;
- совместной сессией с дизайнером и продуктом, если статичного просмотра недостаточно;
- простыми аналитическими панелями, если вопрос больше в фактическом поведении пользователей, чем в дизайне решения.