ну вот как раз те самые узкие кейсы, когда надо гугл аналитику прикрутить и подобные игрушки

для этого есть протопай

Раз тема зашла за курсы, то есть вопрос,  существует ли где-то  хорошие курсы по аналитике, методам тестирование, а/б тесты, построение гипотиз. Чтобы на практике показали, как и что

#вопрос
Ребят, вы расскажите как у вас организованна работа передачи фигмомакета в разработку. Есть проблема, что дизайн может измениться в процессе рпока он в разработке. И разработчику важно понимать, когда изменилось ли что-то. И что он делает ту версию дизайна, которую он получил. Как вариант, экспортить все в пнг и заливать в задачу в жире, тогда будет типо слепок дизайна под версией 1.0. И если дизайнер что-то изменил, то это уже другой слепок 1.1 и это тянет на доработку.
Но оч не хочется что-то выгружать из фигмы, это опять будет два источника правды как было со скетчем, когда выгружали куда-то в клауд.

Как вариант большими буквами клонить релиз кандидат и писать в названии файла что-то типа "ProjectName – RC 1.1.1", где первая цифра это глобальная версия, вторая изменения в рамках спринта, третья изменения в разрабатываемых фичах в рамках спринта. Дополнительные пояснения выносить в комментарии или на отдельный лист с фреймами, содержащими лог изменений, а старый файл просто удалять, чтобы разработчик находясь внутри команды в Фигме не мог залезть в старые версии, а просматривал всегда только актуальную. Практикую подход с такой версионностью уже около двух лет, пока никто не жаловался. Логи изменений выглядят примерно так

Спасибо. Получается в этом варианте у разработчиков не остается выбора сделать изменения в след версии как доработку или перейти уже фигачить сразу новую версию.

И они не могут отчитаться продакту или кому-то, что «вот я делал версию 1 она выглядела так, потом идизайнер изменил, работы стало больше, поэтому сроки большие»

Ну да, оно им и не надо знать, сколько десятков правок ты сделал, прежде чем собрать релиз кандидат. Им важен конечный файл и чёткий лог того, что нужно добавить/убрать.

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

А так, поверь мне, никто из них копаться во вкладке с версиями файла не будет никогда. Просто потому, что у них разбираться в этой чехарде времени нет.

Вот здесь подробнее можешь почитать, я на основе этой статьи свою версионность собирал https://habr.com/ru/post/118756/

Я бы просто всегда держал слой в фигме в том же макете куда пишу версионность, тут же правил и тут же записывал что изменилось на что обратить внмиание. Но разработчикам такой варик не понравился ) Я так понял хочется, чтоб можно было сослаться на две разные версии и уже отдельно решить переделывать что-то или переделки вынести как доработку

Ну типа какой толк смотреть на фреймер и умирающий реакт, если с таким же успехом можно сразу нативные инструменты изучать swiftUI) или Флаттер на крайняк, если на обе платформы.

Тоже подумываю сразу SwiftUI учить

это чё ты реакт хоронишь?) он вполне ещё живой и будет жить, если кто и умрёт так это ангуляр)

как то вы десктоп списали со счетов

Ну по 5ти летнему опыту аутсорс разработки говорю. Реакт юзают на старте, т.к. скорость разработки за счёт мультиплатформы.. а если стартап выживает и уходит в плюс ребята садятся и на нативе переделывают. Потому что архетектурно проигрышный вариант. Иос или андроид в очередной раз обновляют СДК, добавили что-то новое - реакт ещё пол года-год это будет перетягивать. То что юзает фб у себя и в инсте - хер выложат в доступ.

для мобильной разработки, конечно, лучше нативное решение)

тоже с таким сталкивался