Комментарии 10
Как хорошо, когда у команды есть свой дизайнер, погруженный в процессы проекта. Но чаще всего это не так. Обычно на трайб есть пару дизайнеров и они приходящие в проект и совсем не погруженные в него. Именно отсюда у разработчиков большое недоверие к дизайнерам.
Совершенно согласна, когда дизайнер не понимает продукт, не знает его специфики, это плодит и плохую коммуникацию, и слабые решения. Здорово в таких случаях сделать паспорт проекта, где указаны и описаны сегменты аудитории, ключевые флоу, джобы, бизнесовые и технические ограничения и особенности. Так сказать, быстрый онбординг дизайнера, тогда и его решения будут более обоснованные и попадать в цели. Легче наладить коммуникацию, быть в одном понятийном аппарате)
Скажите пожалуйста, как расшифровывается ПБР?
У меня в райфе тоже был неприятный опыт работы с токсичной командой: тратила силы, нервы и время, чтобы взрослым людям показать, как можно комфортно взаимодействовать и давать фидбек, оформляла вики в конфлюенсе, чтобы им было удобнее и стало меньше вопросов, вела специально для них бэклог для прозрачности процессов по текущим задачам и нагрузке.
И спустя год ушла — надеюсь, у автора действительно в долгосрочной перспективе получилось поменять отношение команды! Мне не удалось :(
Команды действительно разные в разных компаниях. В данном случае был позитивный опыт по выстраиванию коммуникации. Но до этого в другом банке проработала также год, с командой и продуктом не повезло. Ты применяла тоже отличные методики по опрозрачниванию процесса дизайнера, но здесь важна и открытость команды к переменам. Только от нас, к сожалению, не всё зависит. И иногда уйти тоже верное решение!
Тут влияет отношение лида. Именно он должен понимать необходимость этих процессов и влиять на отношение всей команды.
(мое субъективное мнение исходя из опыта). Хотелось бы уточнить про какой тип дизайнера статья. Если речь про UX дизайнера, то это отдельная категория, оторванная от действительности. Зачастую они создают очень странные решения, на имплементацию которых тратиться очень большое время, а бизнес value очень маленькое (или даже ниже чем простое решение). Этот тип дизайнеров очень обидчив и считает что их не понимают. Особенно когда их критикуют в самую суть, например система процессинга входящих отчётов. Задача пользователя быстро просмотреть много данных на экране и поправить ошибки. Дизайнер рисует красивый мокап с кучей ui компонентов, пустого места. Когда ему говоришь, что 90% операций надо делать без переключения клавиатура/мышь и максимум данных на экране - получаешь в ответ: Олд скул и ничего не понимаешь в современном дизайне.
Если речь о ui дизайнере, то это must have, особенно если он умеет не только figma, но ещё может предоставить design system. А если он ещё и прототипы умеет делать, то это просто сказка и ни у одной команды не будет с ними проблем.
Во многом проблема в том как ui дизайнер входит в команду. Если он партнёр product owner, то дизайн это часть требований и он подготовлен до того как история уходит в девелопмент. Лёгкие корректировки возможны, если что-то не учли или реализация стоит дорого.
В моей практике идеальная схема ui дизайнер, design system и парт-тайм (не факт, что будет 100% загрузка) верстальщик для того, чтобы чистить вёрстку время от времени.
Сама постановка вопроса, звучит очень странно. Как будто вы хотите сломать существующую design system или доказать свою значимость. Зачастую разработчикам не интересно как и почему создан такой дизайн. Но если он не ложится на бизнес требования, или требует много времени на реализацию компонента или компоненты с одинаковыми требованиями имеют разный дизайн на разных экранах (вопросы консистентности дизайна), то тогда да, к дизайнеру будут вопросы.
В основном это проблемы процессов на проекте и если вы начинаете выстраивать процессы в команде это красный флаг - ваш SM/PM/TM/TL что-то упустил.
Считаю некорректным говорить про "обидчивость UX дизайнеров" только по профессиональному признаку и смахивать всех людей под одну гребёнку.
Я ни разу не работала в командах, где делят дизайнера на UX и UI. И считаю это совершенно верным, что дизайнер занимается и исследованиями, и логикой со структурой, и UI, и бизнесовой частью — включен на всех этапах. Поэтому речь в статье про продуктового дизайнера в постоянной команде разработки.
Вопрос в статье звучит достаточно корректно. Последнее время я чаще встречаю разработчиков, которым интересно, как сформировался дизайн, почему так, а не иначе, они прям хотят вглубь. Поэтому активно дают обратную связь. Шаги из статьи помогли выстроить мне коммуникацию с ними. Да и вовлеченность в команде выросла.
Как дизайнеру приручить «диких» разработчиков?