Комментарии 28
Отрицание, гнев, торг...
Забыли еще двух всадников дизайнопокалипсиса:
Обе работы - от одной очень известной (в частности, своей буквой "М") студии. Трещина (в будущих отношениях) в последнем случае не была задумана, как элемент дизайна. Или была?
висящие в воздухе строительные леса
Там видно диагональные подпорки (укосины). Леса же не обязательно стоят на земле. Ту же Останкинскую башню не только построили, но и ремонтировали после пожара, фото со "строительными лесами, висящими в воздухе" несложно нагуглить.
Там видно диагональные элементы только под самым нижним ярусом, остальные ярусы не крепятся к фасаду здания ничем. Отсутствуют защитные ограждения, отсутствует молниеотвод, отсутствует защитная сетка. Помост находится в неудовлетворительном состоянии, отсутствуют отдельные элементы. По периметру здания отсутствуют ограждения и знаки, предупреждающие о высотных работах.
При строительстве телебашни леса почти не использовались, подмости крепились к бетонной поверхности.
Примерно так
фото со "строительными лесами, висящими в воздухе" несложно нагуглить
Если не сложно, сделайте пожалуйста. У меня не получилось.
У вас на фото не "подмости", а строительная арматура для заливки бетона
upd. Увидел на вашем фото внизу под арматурой и подмости. Тогда вообще не понимаю, чего ещё тут нам обсуждать)
2. Картинки со строительными лесами на Останкинской башне
остальные ярусы не крепятся к фасаду здания ничем.
Крепятся к нижним ярусам
Отсутствуют защитные ограждения, отсутствует молниеотвод, отсутствует защитная сетка
Иллюстрация ≠ строительный чертеж, тут допустимы любые упрощения.
Статья огонь, за ссылку на Неделя руководителя разработки отдельное спасибо!
А можно получить ваш чек-лист?
вы все вместе усердно поработали, а на проде получается что-то такое
Взаимопонимание и поддержка в команде не мешает делать "такое" или "не такое" - просто с каждым разом они делают это дружнее. Если впадать в крайности, то в какой-то момент люди отключают критическое мышление, заменяя свой профессионализм более удобными социально одобряемыми паттернами поведения.
Не всегда дизайнер понимает, что зашивается на фронте, что тянется с бэка, а если с бэка, то что будет, если данные не придут?
да, это боль ....
Хорошие советы, статья - топ!
Ваши картинки к статье очень плохо читаются при чтении статьи на телефоне
С ума сойти, это не статья, это титанический труд, который тянет на целую книгу
Теперь понятны боли и как их решали, но "вишенкой" будет посмотреть какой получился чек-лист, чтобы стянуть его себе
Мемесы классно дополнили повествование) Прочитал на двух дыханиях
Оч интересно больше узнать про процесс дизайна с SDUI, надеюсь следующая статья будет про енто)
попробуйте в браузере зайти на любую страницу товара на Озоне и отобразить отзывы по товару, начиная с самых низких оценок... Этот UX когда-нибудь будет исправлен?
Прочитал с удовольствием, картинки порассматривал с отдельным удовольствием, от бэкенда дизайнерам пламенный привет, в статье прекрасно проартикулировано всё то, что вертится на языке, когда задумываешься над проблемой взаимодействия.
Как аналитик в настоящем, я уже далёк и от дизайна, и от разработки; а как маркетолог в прошлом (руководил разработкой лендингов и знаком с "половиной" болей обоих сторон) — то прочитал с большим удовольствием.
Спасибо за шикарную статью и мемы, все в тему)
Спасибо за статью! Интересно было бы узнать, как версия дизайна прибивается к тикетам разработки? Что происходит, если разработчик взял в работу то, что увидел, через час что-то в макете изменилось, а через неделю все вместе очень удивляются новой реальности в фигме?) И еще как бороться с желанием дизайнеров раскрыть подробнее мысль о куске флоу в отдельной фигме, и не принести обновления в общую?
Отвечу исходя из опыта в своих командах, в других может быть принято иначе:
Когда дизайнер с продактом пришли к некоторому дизайн-решению и при необходимости согласовали его со всеми заинтересованными, начинается этап передачи в разработку: продакт ставит таски на девелоперов, договаривается о приоритетах на техкомах и совершает все нужные организационные телодвижения. Дизайнер в это время может самостоятельно поискать кейсы, которые нужно отразить в макетах, дописать спецификацию, пройти дизайн-чек у дизайн-лидов. Продакт забирает ссылку на Figma и прикрепляет её в таску на разработку.
На груминге и последующих этапах может что-то всплыть и придётся доработать макеты: у меня это чаще всего какие-то непокрытые кейсы, которые мы устно на груминге обсуждаем и я тут же проговариваю, что отражу в макетах. Макет правлю наживую в том же файле: либо добавляю недостающее, либо правлю некорректное (или что договорились переделать с целью упрощения разработки). Если для себя хочу сохранить состояние «до» — переношу в sandbox рядом.
Так как наверняка к этому моменту уже заведётся тред по фиче, то после доработки макета продублирую в треде об изменениях в макете с тегом всех причастных. Дополнительно могу в макете подсветить бейджиками New новые места.
Получается, что я держу все изменения всё в том же файле Figma, который продакт в самом начале прикрепил в тикет разработки: так у всех остаётся последняя актуальная версия. В своих командах не могу вспомнить о проблемах, чтобы апдейты макетов проводились втихую и всплывали уже только на QA неприятным сюрпризом, но у нас в целом очень плотная коммуникация (треды на 600 сообщений не дадут соврать:-))
>Как бороться с желанием дизайнеров раскрыть подробнее мысль о куске флоу в отдельной фигме, и не принести обновления в общую
Звучит как смертный грех, возможно стоит настойчиво дизайнера так больше не делать или спросить о причинах такой организации файлов. Могу только предположить, что файлик может начать умирать по оперативке, и дизайнер начинает новый файл — в любом случае, в предыдущем файле должна быть яркая сноска и комментарий на недостающий кусочек флоу.
Спасибо за ответ! То есть если дизайнер, условно, меняет каждый день макет на протяжении 2 месяцев по нескольку раз в день, то пишет это в общий чат, где вся разработка его каждый день вычитывает в поисках апдейтов дизайна? А как выглядят плашки об изменениях? Типа "new 04.08 12:53", "new 04.08 13:11", "old/removed 04.08 13:13" ?
Сложно представить дизайнера-мазохиста, который 2 месяца будет довносить правки в один и тот же макет, тем более что скорее всего он должен уже работать над следующей задачей в следующих макетах... Либо я не поняла вопроса или контекст? У нас макет (страница в Figma) заводится под каждую задачу, будь это новый экран или просто замена иконки.
Например, есть задача: обогатить данные новых пользователей-юрлиц (что условно может решаться добавлением поля ввода в форме регистрации), заводится страница в Figma-файле задач для юрлиц, в ней показывается As Is и To Be. Допустим, на груминге вспомнили про ещё один стейт ошибки для этого инпута: после груминга бегу добавлять это в макет. Конкретно эта задача закрыта, если у дизайнера есть другие задачи на эту форму регистрации/экран/etc — будет проводиться работа уже в новых страницах Figma.
Соответственно изменения наживую — это какие-то разовые случаи для отработки набросов от аналитиков/разработчиков/QA.
У нас так складывается, потому что у каждого домена своё пространство в Figma, внутри домена есть несколько файлов, которые команды классифицируют как им удобнее (по сценариям и/или по виджетам), внутри файла уже страницы под каждую задачу. В каждой задаче есть карточка: кто делал, когда, кто проверял, тикет в Jira, цель задачи и прочее. Если в ходе дизайн-решения становится понятно, что для разработки скоуп надо «нарезать», то под каждую итерацию делается своя страница и экраны размазываются по нужным страницам. Итого возвращаемся к понятному сценарию: 1 тикет у разработки = 1 макет (страница в Figma) в дизайне.
Ощущение, что текст чат-бота единый и для приложения, и для сайта. Однако на сайте кнопочек нет:
Картинка
Как дизайнеру, пункты из статьи жизненно знакомы) особенно про игнорирование спецификации. Пишу комментами в макете, обговариваю с разработчиком и с тестировщиком. Все равно забывают. Потом на дизайн ревью все это обнаруживается) Думал только у меня так, а видимо нет.
Как у вас распределяется работа у дизайнеров? Из текста создалось впечатление что один дизайнер работает на множестве проектов.
>Как у вас распределяется работа у дизайнеров? Из текста создалось впечатление что один дизайнер работает на множестве проектов.
Возможно такое впечатление сложилось из-за приложенных примеров, но это моя история: я год поработала в продукте «Ozon для юрлиц», а затем перешла в Навигацию.
Обычно у дизайнера множество задач в рамках своего домена, например в PDP (карточке товара), Отзывах, Поиске, Корзине, Чекауте и так далее — везде свой закреплённый дизайнер (или их несколько).
Отрицание, гнев, торг: как дизайну и разработке найти общий язык