Проводил ли анализ в Figma?

Анализ в Figma: мой опыт

Да, я работал с Figma в контексте анализа требований и дизайна. Это важная часть работы BA в современных проектах.

Как я использовал Figma

1. Анализ дизайн-макетов от дизайнеров

Когда дизайнер создавал макеты в Figma, я:

• Смотрел прототипы и flows
• Проверял, что дизайн соответствует требованиям
• Обращал внимание на UX/edge cases
• Задавал вопросы: "А что если пользователь вводит 100 символов? Как это выглядит?"

Пример: В marketplace проекте дизайнер сделал search page. Я заметил:

• Filter panel скрывает результаты поиска на мобильных
• Нет indication что page loadings
• Не ясно что случится если результатов нет

Мы обсудили и улучшили дизайн.

2. Создание flows и user journeys в Figma

Я использовал Figma не для дизайна, а для создания:

• User flows (как пользователь проходит через приложение)
• State diagrams (разные состояния экрана)
• Interaction flows (что происходит при клике)

Примеры:

Figma boards:
- "Payment flow" с 8 screens и transitions
- "Error handling" с разными error messages
- "Mobile onboarding" с 5 screens

Это помогло всей команде видеть целостную картину.

3. Annotation в Figma

Я добавлял комментарии и annotations прямо в Figma:

• Указывал на элементы, которые нужно изменить
• Писал requirements для каждого элемента
• Обсуждал с дизайнером и разработчиком в контексте макета

Это было эффективнее чем писать в отдельном документе.

4. Validation требований через прототипы

Когда я написал требования, я запросил у дизайнера быстрый прототип в Figma. Потом:

• Показал это пользователям на интервью
• Собрал feedback
• Обновил требования

Это сэкономило нам время на разработке неправильного функционала.

Пример: В CRM проекте я предложил новый способ filtering контактов. Дизайнер сделал прототип в Figma за час. Показали пользователям — они сказали "Нет, лучше make it like in Salesforce". Мы обновили дизайн. Потом, когда разработчик начал кодить, требование было ясно.

5. Создание acceptance criteria через дизайны

Дизайны в Figma становились частью requirements:

Task: "Implement search filters"
Acceptance Criteria:
- Filter panel shown on left (как на макете в Figma)
- Filters show: Category, Price, Rating, Availability
- When user selects filter, results update immediately
- Show loading state (спиннер как на макете)
- On mobile: filter panel slide from left

Разработчик открывает Figma и видит точно как это должно выглядеть.

Challenges при работе с Figma

Challenge 1: Figma это для дизайна, не для requirements

Figma не ideal для document complex requirements. Я использовал её в combination с текстовыми документами.

Solution: Figma для visual requirements, документы для logic и edge cases.

Challenge 2: Разработчики игнорируют Figma

Некоторые разработчики смотрели на Figma и говорили "Окей, я буду делать на свой лад".

Solution: Make it binding requirement. Acceptance criteria reference specific screens in Figma. QA checks against Figma.

Challenge 3: Figma не обновляется когда меняются требования

Если я change requirement, нужно update и документ и Figma.

Solution: Always update both at same time. Или use Figma как source of truth для visual parts.

Best practices при работе с Figma

1. Name screens clearly

• "Payment - Initial" vs "Payment"
• "Error - Insufficient funds" vs "Error"

2. Use components для repeated elements

• Button component
• Card component
• Для consistency

3. Add notes в Figma

• Что особенного в этом screen?
• Какие edge cases?
• Что happens на мобильных?

4. Version control

• Figma имеет version history
• Может save versions перед major changes

5. Share with team регулярно

• Link to Figma в requirements
• Discuss в meetings
• Get feedback early

Примеры projects где Figma помогла

Healthcare project:

• Дизайнер создал flows для appointment booking
• Я проверил это с реальными doctors
• Мы improved flows перед разработкой
• Результат: app которая doctors actually want to use

Marketplace project:

• Figma flows помогли visualize journey freelancer-client
• Найдем 5 pain points
• Обновили requirements based on flows
• Разработчик точно знал что делать

FinTech project:

• Figma prototypes помогли discuss edge cases
• Что happens при error payment?
• Что happens при slow connection?
• Все на same page

Интеграция Figma в process требований

Мой процесс:

1. Я пишу требования (text)
2. Дизайнер создает макеты в Figma
3. Я анализирую макеты (проверяю что соответствуют требованиям)
4. Я добавляю comments в Figma
5. Дизайнер обновляет макеты
6. Я создаю acceptance criteria based on Figma
7. Разработчик implements и проверяет против Figma
8. QA тестирует против Figma

Когда Figma не нужна

• Для backend требований (API, database)
• Для infrastructure требований
• Для business logic что не visible на UI

Для этих случаев text requirements достаточно.

Вывод

Figma — это powerful tool для BA если использовать её правильно:

• Как инструмент для validation требований
• Как visual documentation
• Как acceptance criteria для UI
• Как средство communication between designer-BA-developer

Не should be only source of truth для requirements, но important part of process.

Большинство modern projects требуют collaboration between BA и дизайнеров в Figma. Если я не work с Figma, я losing important communication channel.