Как часто используешь Figma?

Как я использую Figma в работе Business Analyst

Figma — это не инструмент для дизайна, а инструмент для сотрудничества. За 10+ лет работы я понял, что аналитик, который умеет работать в Figma, экономит месяцы на согласовании требований и передаче видения команде.

Частота использования

Я использую Figma почти каждый день — примерно 2-3 часа в неделю. Это стало таким же инструментом для моей работы, как Excel и SQL.

Но важно уточнить: я не дизайнер, я не рисую красивые картинки. Я использую Figma для коммуникации и уточнения требований.

Основные сценарии использования

1. Уточнение требований с дизайнерами (40% времени в Figma)

Сценарий: Дизайнер создал макет нового экрана. Нужно убедиться, что это соответствует требованиям.

Мы открываем дизайн в Figma и я:

• Комментирую на макете: "Что происходит, если пользователь вводит 100+ символов в это поле?"
• Задаю вопросы: "Где error message? Есть ли validation на клиенте?"
• Рисую arrows и notes: "Этот flow потребует API вызова. Сколько это займёт?"

Пример: Тестировали redesign checkout flow. Я заметил в Figma, что отсутствует экран "payment failed". Спросил дизайнера: "Что видит пользователь, если платёж не прошёл?" Он забыл об этом случае. Благодаря этому обсуждению в Figma, мы не построили incomplete feature.

2. Прототипирование user flows (30% времени)

Когда нужно обсудить сложный процесс (например, multi-step form), я:

• Беру template экранов
• Добавляю comment с описанием transitions
• Создаю простые wireframes (не красивые дизайны, просто boxes с labels)
• Показываю коллегам

Пример: Разрабатывали новый onboarding для Enterprise клиентов (10 шагов). Я:

• Нарисовал 10 экранов в Figma (каждый — просто 5 минут на создание)
• Добавил комментарии: "Шаг 1: Email verification. Что делать, если Email не валиден?"
• Поделился с Product Manager и CTO
• Они предложили улучшения в виде комментариев
• За 2 часа согласовали сложный flow вместо 5 встреч

3. Документирование requirements (20% времени)

Для сложных фич я создаю в Figma то, что называю "Requirement Design":

• Оригинальный макет дизайнера
• На нём я рисую и комментирую все edge cases
• Например, чекбоксы для разных стейтов: normal, hover, checked, disabled, error
• Все возможные состояния экрана в одном месте

Это экономит разработчику часы на вопросы "Как должна выглядеть кнопка в disabled состояния?".

4. Сотрудничество с разработчиками (10% времени)

Девелоперы постоянно спрашивают:

• "Что означает этот иконка?"
• "Это поле обязательное?"
• "Сколько это должно быть?"

Вместо ответа в Slack, я открываю Figma и комментирую прямо на макете. Разработчик видит контекст и не нужно пересылать скриншоты туда-сюда.

Техники, которые я использую

Техника 1: Component States Для каждого компонента показываю все его состояния:

• Button: default, hover, pressed, disabled, loading
• Input: empty, filled, focused, error, success, disabled

Это особенно полезно для дизайн-системы и консистентности.

Техника 2: Annotation Layers Создаю отдельный слой "Annotations" с notes:

[!] Required field
[i] Shows validation error if length > 100
[!] API call on blur — must be debounced
[!] Accessible via keyboard tab

Разработчик видит все constraints сразу.

Техника 3: Linking Flows Если у меня 10 экранов, я создаю invisible buttons и делаю prototype links между экранами. Дизайнер может кликать через flow без Figma плаин (prototype mode). Это помогает "почувствовать" юзер experience.

Техника 4: Version Control Оставляю комментарии с версиями:

[v1] Первый вариант (отклонен — слишком много steps)
[v2] Второй вариант (одобрен Product Manager)
[v3 CURRENT] Третий вариант с feedback от CTO

Это помогает при revisit через месяцы.

Какие навыки Figma мне нужны

Я не дизайнер, поэтому не нужно:

• Красивые цвета и шрифты (это дизайнер)
• Продвинутая типография
• Иллюстрации
• Анимация и prototype interactions (это может быть useful, но не критично)

Мне нужно:

• Базовые фигуры (rectangle, circle, line) ✓
• Текст и комментарии ✓
• Группировка элементов ✓
• Components (для consistency) ✓
• Sharing и permissions ✓

Это я выучил за неделю. Не нужно быть экспертом в Figma, чтобы быть полезным.

Реальные примеры

Пример 1: API Response Handling Дизайнер нарисовал happy path (когда всё работает). Я спросил в Figma:

• "Что если API возвращает error 500?"
• "Что если response slow (3 секунды)?"
• "Что если нет интернета?"

Дизайнер создал дополнительные экраны. Разработчик видел все случаи и не гадал.

Пример 2: Mobile Responsiveness Дизайнер создал desktop версию. Я в Figma спросил:

• "Как это выглядит на iPhone 12? на iPad?"
• Дизайнер добавил варианты
• Мы обсудили, какие элементы переходят в подменю, какие скрываются

Удалось избежать ситуации "разработчик сделал responsive, но выглядит странно".

Пример 3: Error Messages На макете было: "Error: invalid email". Я прокомментировал:

• "Что такое "invalid email"? Не хватает @? Домен не существует?"
• "Нужна ссылка на help документацию?"
• "Какой язык? Русский? Английский?"

Это привело к лучшему UX и меньше support tickets после релиза.

Интеграция с другими инструментами

Figma + Jira Копирую ссылку на Figma screen в description требования в Jira. Разработчик знает, что как должно выглядеть.

Figma + Design System Если я использую design system component, я ссылаюсь на него. Это обеспечивает consistency.

Figma + Handoff Tools Использую плагины типа Zeplin для автоматического экспорта спецификаций (размеры, цвета, fonts).

Когда я НЕ использую Figma

• Простые требования: Если это просто "добавь новую кнопку в меню", Figma излишен
• Текстовые требования: Для API contracts, database schema я использую Excel/Confluence
• Data flows: Для ETL логики использую diagrams.net, не Figma

Figma лучше всего подходит для UI/UX требований.

Почему это важно для моей роли Business Analyst

1. Быстрая коммуникация — вместо 30 минут встречи, я пятью комментариями в Figma уточняю требования
2. Документирование — макет + мои комментарии = живая спецификация
3. Снижение rework — дизайнер видит требования раньше, чем начать detailed design
4. Уважение к дизайнерам — я говорю на их языке, не требую change через Slack
5. Единая версия истины — все видят один макет, не множество файлов Word

Правила использования Figma

1. Комментируй, не редактируй — если это не мой дизайн, я не меняю цвета/размеры
2. Будь конкретен — вместо "это выглядит странно", пишу "кнопка должна быть красная, как в design system"
3. Спрашивай, не приказывай — вместо "измени это", спрашиваю "почему ты выбрал этот подход?"
4. Реагируй на feedback — если дизайнер спросил, отвечу в течение дня
5. Архивируй старые версии — не удаляю старые макеты, они могут пригодиться для reference

Результаты

Благодаря регулярному использованию Figma:

• Misunderstandings снизились на 60% — всё видно на макете
• Rework сократился — дизайнер и разработчик понимают требования раньше
• Скорость разработки выросла — разработчик не гадает, как сделать
• Качество UX улучшилось — обсуждаем all edge cases до разработки
• Отношения с дизайнером улучшились — я не критикую готовый код, я помогаю на этапе дизайна

Figma стала мой third most important tool после SQL и Excel. Это инвестиция в навыке, которая окупается в первый месяц.