>Как у вас распределяется работа у дизайнеров? Из текста создалось впечатление что один дизайнер работает на множестве проектов.
Возможно такое впечатление сложилось из-за приложенных примеров, но это моя история: я год поработала в продукте «Ozon для юрлиц», а затем перешла в Навигацию.
Обычно у дизайнера множество задач в рамках своего домена, например в PDP (карточке товара), Отзывах, Поиске, Корзине, Чекауте и так далее — везде свой закреплённый дизайнер (или их несколько).
Сложно представить дизайнера-мазохиста, который 2 месяца будет довносить правки в один и тот же макет, тем более что скорее всего он должен уже работать над следующей задачей в следующих макетах... Либо я не поняла вопроса или контекст? У нас макет (страница в Figma) заводится под каждую задачу, будь это новый экран или просто замена иконки. Например, есть задача: обогатить данные новых пользователей-юрлиц (что условно может решаться добавлением поля ввода в форме регистрации), заводится страница в Figma-файле задач для юрлиц, в ней показывается As Is и To Be. Допустим, на груминге вспомнили про ещё один стейт ошибки для этого инпута: после груминга бегу добавлять это в макет. Конкретно эта задача закрыта, если у дизайнера есть другие задачи на эту форму регистрации/экран/etc — будет проводиться работа уже в новых страницах Figma. Соответственно изменения наживую — это какие-то разовые случаи для отработки набросов от аналитиков/разработчиков/QA. У нас так складывается, потому что у каждого домена своё пространство в Figma, внутри домена есть несколько файлов, которые команды классифицируют как им удобнее (по сценариям и/или по виджетам), внутри файла уже страницы под каждую задачу. В каждой задаче есть карточка: кто делал, когда, кто проверял, тикет в Jira, цель задачи и прочее. Если в ходе дизайн-решения становится понятно, что для разработки скоуп надо «нарезать», то под каждую итерацию делается своя страница и экраны размазываются по нужным страницам. Итого возвращаемся к понятному сценарию: 1 тикет у разработки = 1 макет (страница в Figma) в дизайне.
Отвечу исходя из опыта в своих командах, в других может быть принято иначе: Когда дизайнер с продактом пришли к некоторому дизайн-решению и при необходимости согласовали его со всеми заинтересованными, начинается этап передачи в разработку: продакт ставит таски на девелоперов, договаривается о приоритетах на техкомах и совершает все нужные организационные телодвижения. Дизайнер в это время может самостоятельно поискать кейсы, которые нужно отразить в макетах, дописать спецификацию, пройти дизайн-чек у дизайн-лидов. Продакт забирает ссылку на Figma и прикрепляет её в таску на разработку. На груминге и последующих этапах может что-то всплыть и придётся доработать макеты: у меня это чаще всего какие-то непокрытые кейсы, которые мы устно на груминге обсуждаем и я тут же проговариваю, что отражу в макетах. Макет правлю наживую в том же файле: либо добавляю недостающее, либо правлю некорректное (или что договорились переделать с целью упрощения разработки). Если для себя хочу сохранить состояние «до» — переношу в sandbox рядом. Так как наверняка к этому моменту уже заведётся тред по фиче, то после доработки макета продублирую в треде об изменениях в макете с тегом всех причастных. Дополнительно могу в макете подсветить бейджиками New новые места.
Получается, что я держу все изменения всё в том же файле Figma, который продакт в самом начале прикрепил в тикет разработки: так у всех остаётся последняя актуальная версия. В своих командах не могу вспомнить о проблемах, чтобы апдейты макетов проводились втихую и всплывали уже только на QA неприятным сюрпризом, но у нас в целом очень плотная коммуникация (треды на 600 сообщений не дадут соврать:-))
>Как бороться с желанием дизайнеров раскрыть подробнее мысль о куске флоу в отдельной фигме, и не принести обновления в общую Звучит как смертный грех, возможно стоит настойчиво дизайнера так больше не делать или спросить о причинах такой организации файлов. Могу только предположить, что файлик может начать умирать по оперативке, и дизайнер начинает новый файл — в любом случае, в предыдущем файле должна быть яркая сноска и комментарий на недостающий кусочек флоу.
Вспомнила, что у нас ещё дизайнеры ДС рассказывали со своей колокольни про СДУЙ, возможно в видеоформате будет удобнее https://www.youtube.com/live/FiqtBduNcEc?si=FFEs9FVuL7gax49w&t=5094
Как хорошо, что про это уже есть статья, которую мы писали с нашим мобильным разработчиком, пока я была деврелом) https://habr.com/ru/companies/ozontech/articles/661941/
К сожалению, ограниченность инструментов оформления изображения на Хабре не позволяет выбрать оптимальное решение, которое хорошо бы смотрелось и в десктопе, и на мобилке. Пришлось выбрать меньшее из зол :(
Спасибо! Думала о том, надо ли чек-лист приложить дополнительно, но у нас в нём много внутрянки и локальных ссылок. Скриншот в хорошем качестве, если вдруг захочется какие-то пункты к себе забрать (кажется, уже во всех компаниях свои чек-листы на эту тему)
Вы приводите в пример ироничный ответ от комментатора, который скорее всего не связан с компанией) Рядом был ответ на тот же вопрос:
«Большое заблуждение, что продуктовые команды не сталкиваются с технологическими вызовами. Платформа это все же набор общих решений, благодаря которым можно не тратить много времени на проработку инфраструктурных слоев своего сервиса, однако для каждого конкретного сервиса всегда будут специфические кейсы, которых в платформе нет и быть не может.
Платформа не придумывает алгоритмы для логистики, складов, для сервисов типа стоков и информации о товарах и т.п. Платформа не пишет оптимальные sql запросы в шардированном окружении. Платформа не занимается анализом hotpath и не ищет утечки памяти. Платформа не оптимизирует выделения памяти, не уменьшает потребление CPU и т.п. Этим всем занимаются именно продуктовые команды. Но да! Платформы дает больше средств для диагностики своих сервисов и, конечно, помогает командам, если у них возникают проблемы, для решения которых у них вдруг не хватает экспертизы»
>Как у вас распределяется работа у дизайнеров? Из текста создалось впечатление что один дизайнер работает на множестве проектов.
Возможно такое впечатление сложилось из-за приложенных примеров, но это моя история: я год поработала в продукте «Ozon для юрлиц», а затем перешла в Навигацию.
Обычно у дизайнера множество задач в рамках своего домена, например в PDP (карточке товара), Отзывах, Поиске, Корзине, Чекауте и так далее — везде свой закреплённый дизайнер (или их несколько).
По идее должна быть кнопочка и на декстопе тоже, но по какой-то причине не догрузилась. Попробую найти внутри, кому передать из коллег
Сложно представить дизайнера-мазохиста, который 2 месяца будет довносить правки в один и тот же макет, тем более что скорее всего он должен уже работать над следующей задачей в следующих макетах... Либо я не поняла вопроса или контекст? У нас макет (страница в Figma) заводится под каждую задачу, будь это новый экран или просто замена иконки.
Например, есть задача: обогатить данные новых пользователей-юрлиц (что условно может решаться добавлением поля ввода в форме регистрации), заводится страница в Figma-файле задач для юрлиц, в ней показывается As Is и To Be. Допустим, на груминге вспомнили про ещё один стейт ошибки для этого инпута: после груминга бегу добавлять это в макет. Конкретно эта задача закрыта, если у дизайнера есть другие задачи на эту форму регистрации/экран/etc — будет проводиться работа уже в новых страницах Figma.
Соответственно изменения наживую — это какие-то разовые случаи для отработки набросов от аналитиков/разработчиков/QA.
У нас так складывается, потому что у каждого домена своё пространство в Figma, внутри домена есть несколько файлов, которые команды классифицируют как им удобнее (по сценариям и/или по виджетам), внутри файла уже страницы под каждую задачу. В каждой задаче есть карточка: кто делал, когда, кто проверял, тикет в Jira, цель задачи и прочее. Если в ходе дизайн-решения становится понятно, что для разработки скоуп надо «нарезать», то под каждую итерацию делается своя страница и экраны размазываются по нужным страницам. Итого возвращаемся к понятному сценарию: 1 тикет у разработки = 1 макет (страница в Figma) в дизайне.
Отвечу исходя из опыта в своих командах, в других может быть принято иначе:
Когда дизайнер с продактом пришли к некоторому дизайн-решению и при необходимости согласовали его со всеми заинтересованными, начинается этап передачи в разработку: продакт ставит таски на девелоперов, договаривается о приоритетах на техкомах и совершает все нужные организационные телодвижения. Дизайнер в это время может самостоятельно поискать кейсы, которые нужно отразить в макетах, дописать спецификацию, пройти дизайн-чек у дизайн-лидов. Продакт забирает ссылку на Figma и прикрепляет её в таску на разработку.
На груминге и последующих этапах может что-то всплыть и придётся доработать макеты: у меня это чаще всего какие-то непокрытые кейсы, которые мы устно на груминге обсуждаем и я тут же проговариваю, что отражу в макетах. Макет правлю наживую в том же файле: либо добавляю недостающее, либо правлю некорректное (или что договорились переделать с целью упрощения разработки). Если для себя хочу сохранить состояние «до» — переношу в sandbox рядом.
Так как наверняка к этому моменту уже заведётся тред по фиче, то после доработки макета продублирую в треде об изменениях в макете с тегом всех причастных. Дополнительно могу в макете подсветить бейджиками New новые места.
Получается, что я держу все изменения всё в том же файле Figma, который продакт в самом начале прикрепил в тикет разработки: так у всех остаётся последняя актуальная версия. В своих командах не могу вспомнить о проблемах, чтобы апдейты макетов проводились втихую и всплывали уже только на QA неприятным сюрпризом, но у нас в целом очень плотная коммуникация (треды на 600 сообщений не дадут соврать:-))
>Как бороться с желанием дизайнеров раскрыть подробнее мысль о куске флоу в отдельной фигме, и не принести обновления в общую
Звучит как смертный грех, возможно стоит настойчиво дизайнера так больше не делать или спросить о причинах такой организации файлов. Могу только предположить, что файлик может начать умирать по оперативке, и дизайнер начинает новый файл — в любом случае, в предыдущем файле должна быть яркая сноска и комментарий на недостающий кусочек флоу.
знаем об этом, отвечая на вопрос: когда-нибудь — да, есть в бэклоге
Вспомнила, что у нас ещё дизайнеры ДС рассказывали со своей колокольни про СДУЙ, возможно в видеоформате будет удобнее https://www.youtube.com/live/FiqtBduNcEc?si=FFEs9FVuL7gax49w&t=5094
Как хорошо, что про это уже есть статья, которую мы писали с нашим мобильным разработчиком, пока я была деврелом) https://habr.com/ru/companies/ozontech/articles/661941/
К сожалению, ограниченность инструментов оформления изображения на Хабре не позволяет выбрать оптимальное решение, которое хорошо бы смотрелось и в десктопе, и на мобилке. Пришлось выбрать меньшее из зол :(
Спасибо!
Думала о том, надо ли чек-лист приложить дополнительно, но у нас в нём много внутрянки и локальных ссылок. Скриншот в хорошем качестве, если вдруг захочется какие-то пункты к себе забрать (кажется, уже во всех компаниях свои чек-листы на эту тему)
Вы приводите в пример ироничный ответ от комментатора, который скорее всего не связан с компанией) Рядом был ответ на тот же вопрос:
«Большое заблуждение, что продуктовые команды не сталкиваются с технологическими вызовами. Платформа это все же набор общих решений, благодаря которым можно не тратить много времени на проработку инфраструктурных слоев своего сервиса, однако для каждого конкретного сервиса всегда будут специфические кейсы, которых в платформе нет и быть не может.
Платформа не придумывает алгоритмы для логистики, складов, для сервисов типа стоков и информации о товарах и т.п. Платформа не пишет оптимальные sql запросы в шардированном окружении. Платформа не занимается анализом hotpath и не ищет утечки памяти. Платформа не оптимизирует выделения памяти, не уменьшает потребление CPU и т.п. Этим всем занимаются именно продуктовые команды. Но да! Платформы дает больше средств для диагностики своих сервисов и, конечно, помогает командам, если у них возникают проблемы, для решения которых у них вдруг не хватает экспертизы»
А можно развернуть мысль, что вы прочитали про их "Платформу"?
Факт
Выглядит любопытно. Главное, чтобы это не превратилось в стресс-интервью)
Ты даже не представляешь, насколько это близко к правде :) У нас очень много внутренних мемов с гусями.
Есть, у нас как минимум Поиск на Java и в Озон Экспресс есть
Просто у нас полугодовое ревью в марте будет)
Регистрация напомнит о событии и даёт возможность задать вопросы, на которые мы ответим в ходе прямого эфира
Трансляция будет в нашем канале на YouTube, запись оставим там же
На Озоне :) Голуби — наша любовь. Кстати, это фото выиграло в конкурсе лучших рабочих мест.
А патч «Дичь» — это уже другая история.