Эффективность взаимодействия с отделом UX/UI дизайна

компоненты - красиво!
Заинтересованы в качественном продукте
Вовлеченность и не безразличие к результату

В опросе участвовали:
BA
QA
Product manager
FE

после окончания разработки
2) Изменение расположения (возможно удаление)
- старых макетов, но актуальных по проду
- новых макетов, актуальных по задачам
3) Нет наглядности и прозрачности:
- по критериям сдачи и приема результатов работы UX/UI.
- чья ответственность за окончательное согласование и дальнейшую передачу этих результатов в разработку (кто исполнитель, кто заказчик, кто приемщик)
- чье видение важнее продакта или дизайнера
4) Коммуникации:
- стало сложнее и тяжелее общаться
- уходит много сил и времени
- нужно доносить и отстаивать точку зрения
- не всегда слышат и прислушиваются к аргументам
- в последнее время это ощущается как противостояние друг другу
- Периодически диалог начинает походить на выяснение отношений.
- Прилетают какие-то обвинения или факты, которых не было.
Кейс: Пришёл к ним в отдел, "уселся" и стал долбить по столу пальцем и требовать радио-кнопки. А по факту пришёл и указал основное требование - чтобы функционал компонента предполагал выбор только одного варианта. И, кстати, завершилось все именно отрисовкой радио-кнопок, но потребовался целый день, чтобы это решение принять.

Кейс: "Переворачиваются слова", и в целом переходы на "ты говорил-ла”.
Перевели общение в Skype, для записи разговора. “т.к. потом может получится ситуация, что ты якобы этого не говорил-ла, и никаких сроков не было оговорено”.
Кейс: Резкие и иногда грубоватые высказывания и комментарии в личных сообщениях, комментариях к задачам.
Кейс: Получаем порции едких комментариев о том, что ничего не понимаем и лезем в чужую работу.
5) Предложенный вариант макета усложняет разработку
- делает ее более дорогой. Иногда и дальнейшее сопровождение функционала. Не понятно, как быть в таких ситуациях.
6) Нет анализа логики дизайнером по ТЗ от BA по UC.
- некая последовательность операций в UC принципиальна и н-р не может быть объединена в 1 блок, даже если это очень красиво.
7) Долгое согласование макетов
- не принимают факта, что в конкретную задачу мы не можем уместить весь функционал, который отрисован. (т.е. сверх задачи)
Кейс: по BR-26869 согласовывали макеты по Админке неделю. Ждали неделю макеты по UI ЛК. Потом еще спорили и пытались им обосновать почему мы не будем переделывать Карточку обращения.
8) Принятие решений за продакта/разработчика/РМ
Кейс: когда дизайнеры серьезно начинают говорить, сколько времени или строчек кода займет та или иная доработка у разработчика. Т.е. “делайте, это недолго”.
9) Флоу работы над задачей -не прозрачен.
Кейс: а) когда задача в ревью (иногда это ревью для Ланы и заказчику нельзя смотреть, а иногда это ревью уже для тебя). б) закрывается задача дизайнером без ок от заказчика.

задаче или нет. Из-за чего в какой-то момент уже перестаешь прописывать сценарии и проблемы.
11) Обмена информацией от руководителя -> сотрудникам
- Приходится либо созваниваться снова совместно, либо заново всё объяснять.
12) Не знают как работает на проде
- Текущий флоу клиента, какие есть технические, юридические, организационные ограничения. Каждый раз приходится заново их объяснять, оправдываться за то, что эти ограничения существуют и доказывать, что обойти их сейчас не можем / не будем / не в рамках задачи.
13) Несоблюдение договоренностей
- Устно могли договориться и обсудить один вариант, с ним могли согласиться (иногда с возражениями, но итог - согласие) . Через время может оказаться, что с вариантом не согласны и сделали иное.
14) Забывают про мобилку
- Отрисовывается всё чаще всего на десктоп, мобилка уже отрисовывается постольку поскольку и в паре вариантов. При этом у нас 90% пользователей на мобилке, поэтому лучше акцентироваться и видеть дизайн именно в мобилке.
15) Очень много времени во время обсуждений
- Тратим на то, чтобы послушать, как хорошо отдел дизайна знает дизайн и разбирается в UI/UX. При этом это база, которая не подвергается сомнению.

16) Неприятие и отрицание в ситуации доработок макетов
- Если есть какие-либо доработки дизайна, из-за чего приходится долго и мягко (и всё равно получается не очень хорошо) пытаться подводить к тому, чтобы были внесены какие-то корректировки, что затягивает сроки реализации задач.
17) Множество доработок, которые инициируются самим дизайнером
- При этом это всё уходит в стол, потому что у продактов нет задач на это, или же они не взяты в работу. После чего возникают возражения или путаница с тем, что "а мы же этот кейс уже перерабатывали".
18) Иногда нам нужны дарк паттерны
- Мы (и бизнес) не всегда готов на оптимальные для пользователя решения,и это - нормально, в ином случае мы будем терять / недозарабатывать деньги. Если такое происходит, то приходится долго обсуждать с дизайном и оправдываться, почему нужно именно так.
19) Требований отдела\ регулятора\ результата исследования
- Приходится словно “оправдаться” или убеждать почему так надо
20) Замыкание всех “проблем” на Арт-директора
- Часто Лана сама рисует макеты.
- Ксения Ярославлева не идет на контакт, на любое предложение сразу в отказ, и эскалация на Лану.
21) Макеты теряются
- Невозможно найти макеты по задаче 2-х месячной давности (действующие). QA непонятно с чем сверять