В Purrweb всё начинается с дизайна — это отправная точка любого проекта. Чтобы попасть в ожидания заказчика и создать визуальный концепт без косяков, важно наладить хорошие отношения между дизайнерами и проектным менеджером. Мы поделимся опытом и дадим 4 совета, которые помогут менеджерам эффективнее работать с дизайнерами.
В идеальном мире проектный менеджер разбирается в дизайне на уровне джун-специалиста. Он может вовремя заметить недостающую кнопку на макете, кривую анимацию всплывающего окна и шрифты не по ТЗ.
В реальном же мире у каждого из нас есть сильные и слабые стороны. Поэтому иногда проектный менеджер спотыкается о слово «паддинги», а дизайнеры не понимают, что написано в ТЗ. Они воспринимают менеджера как ходячий таймер с вопросом «Как успехи?», а не как полноценного участника команды. Давайте разберемся, как менеджеру работать с дизайнерами, чтобы сохранить здоровую рабочую атмосферу и нервные клетки всем специалистам.
В некоторых компаниях дизайнеры напрямую работают с заказчиками. Мы же считаем, что дизайнер должен заниматься дизайном, а не менеджерскими задачами. Когда все заняты своим делом, мы экономим время и деньги заказчика.
Совет №1: учитывайте опыт и характер дизайнера, когда назначаете ТЗ
Каждый дизайнер решает одну и ту же задачу по-разному: подход зависит от опыта, навыков и даже склада характера. Мы считаем, что ТЗ тоже нужно ставить по-разному, с учетом этих нюансов. Например, одного дизайнера достаточно попросить «нарисуй эту кнопку», а другому нужно дать пошаговую инструкцию, иначе он свернет куда-то не туда.
Так выглядит ТЗ для джуна-дизайнера: менеджер подробно расписал каждый шаг и дал в скобках пояснения к своим словам
Мы ставим задачи под конкретного дизайнера. Например, для джуна расписываем по пунктам, что нужно сделать и как это должно выглядеть, а опытному сотруднику пишем: «Создай профиль пользователя».
Дополнительно можно дать ссылки с примерами — это поможет избежать недопонимания, особенно когда работаешь с неопытными дизайнерами с небольшой насмотренностью.
В референсах указываем похожие проекты на российском рынке, чтобы было проще схватить суть
Совет №2: проверяйте логику макетов сами — даже после дизайн-ревью
Проектный менеджер по дизайну — не просто попугай, который спрашивает: «Ну, что там с флоу авторизации?». Это полноценный участник процесса, который может предлагать свои решения.
Чтобы менеджер был действительно полезен, он должен базово разбираться в дизайне: понимать, как устроены Figma, Readymag и Miro, знать основы верстки, не путаться в терминах. При этом во время ревью не стоит закапываться в технические детали — это задача дизайнеров, которые проверяют каждый пиксель макета.
Менеджеру важнее понять, все ли функции из ТЗ реализовали, логичен ли путь по приложению, всё ли будет ясно потенциальному пользователю. Если он вовремя заметит ошибки и вмешается в процесс, не придется потом краснеть на демо-презентации для клиента.
Пример из практики. Однажды проектный менеджер заметил грубую ошибку уже после ревью приложения для медитаций. Оказалось, что кнопка выхода из аккаунта в приложении идеально ложится под большой палец пользователя. Это значит, что нежелательное для бизнеса действие становится максимально удобным.
Мы исправили эту ошибку еще до презентации результатов работы заказчику и в итоге не опозорились перед клиентом.
В финальной версии приложения мы подвинули кнопку «Выйти» повыше — теперь пользователь не промахнется, когда нажимает на «Главная» или «Профиль»
Совет №3: передавайте фидбэк от заказчика так, чтобы не ранить чьи-то чувства
Часто дизайнеры уязвимы к критике, потому что вкладываются душой в творчество. Им приходится создавать с нуля, креативить, иногда угадывать желания заказчика. Если проектный менеджер не будет фильтровать обратку, это может уничтожить настрой команды.
Разберем самые частые ошибки и подскажем, как их избежать.
Совет №4: защищайте идеи дизайнеров, когда презентуете результаты работы
Когда задача выполнена, проектный менеджер должен презентовать итог заказчику. Успех разработки оценить просто: если всё работает — команда справилась. С дизайном сложнее: надо объяснить клиенту, почему всё должно работать именно так, и защитить идеи команды.
Здорово, когда проектный менеджер разбирается в дизайне. Он сможет прямо на ходу предлагать альтернативы, осознанно обсуждать макеты, аргументировать решения команды. Например, если заказчик предлагает заменить шрифт на Comic Sans, объяснить, почему так делать не стоит, рассказать про читабельность и контраст, распознаваемость символов.
Чтобы грамотно презентовать работу по дизайну, в Purrweb есть свои мини-шаблоны и структура повествования. Кликайте на картинку и смотрите, как это выглядит:
Пример из практики. Весной мы делали мобильное приложение Hype — социальную сеть для студентов Канады. Клиент хотел добавить на один из экранов максимум функций: возможность добавить в друзья, написать сообщение, сделать репост и заблокировать пользователя.
Проектный менеджер объяснил, почему это невозможно: даже если все эти кнопки поместятся на экран, у них будет очень небольшая область нажатия. Есть риск, что пользователи будут ошибаться и нажимать не на те кнопки: например, блокировать кого-то вместо репоста.
В итоге команде удалось найти компромисс с заказчиком: лишние функции спрятали в кебаб-меню (кнопку с тремя точками) так, чтобы они раскрывались только во всплывающем окне. Получилось выполнить пожелания клиента и в то же время не перегрузить интерфейс.
Так выглядит итоговый вариант страницы, которую менеджер согласовал с заказчиком
Если хотите лучше запомнить структуру демо-презентации, то вот вам постироничная памятка от наших проектных менеджеров.
Коротко: как проектному менеджеру работать с дизайнерами
Проектный менеджер, как и любой хороший специалист, который работает с дизайнерами, прокачивает процессы своей части проекта, вовремя замечает ошибки и поддерживает рабочий настрой команды. Подытожим, что именно он может делать:
- Индивидуально формулировать ТЗ, учитывая опыт и склад характера каждого дизайнера.
- Проверять логику макетов самостоятельно, даже после дизайн-ревью. Полноценно участвовать в создании проекта.
- Передавать фидбэк от заказчика так, чтобы не ранить ничьи чувства, но при этом сохранить суть и не замолчать негатив.
- Убедительно презентовать результаты работы клиенту и защищать идеи дизайнеров.
Хотите еще больше полезных материалов по дизайну, менеджменту, HR и разработке? Тогда подписывайтесь на наш блог, где мы делимся подробными кейсами и экспертными статьями:
Почему мне так смешно, что эта штука называется кебаб-меню?)
я бы даже сказала, шашлык-меню))
Спасибо за статью!
Теперь хочется статью о том, кто позаботится о тонкой душевной организации менеджерской души😆
сначала прочел про душевную организацию менеджерской душнилы ))))
Ну нет же. Менеджер это стрессоустойчивый человек, у которого не должно портиться настроение от фидбека клиентов, который должен находить подходящие слова, всех защищать и вообще быть котиком.
И тапки приносить заодно. Или газету😆
Вы же кнопку подвинули всего на полсантиметра выше. Это ж мелочь, нет?
Теперь кнопка хуже ложится под большой палец. Соответственно, случайно её нажать куда сложнее. Это небольшой нюанс, но он имеет значение — и дизайн-ПМ его подметил.
Она стала дальше от других часто используемых кнопок — следовательно, меньше ложных нажатий по ней. Плюс в новом варианте кнопка не так сильно выделяется относительно других элементов на экране.
В третьем пункте есть неплохие и неочевидные советы, спасибо
Успех проекта зависит от взаимопонимания и компетентности в частности. Это смежные профессии и тут по умолчанию должно предполагаться понимание задач со стороны каждого из них. Понятное дело, что каждый решает свои, но сути это не меняет. А за советы, спасибо.
С первым советом вообще не согласна, ну, или же он сформулирован криво.
Если вы пишете дизайнеру "просто сделай окно настроек", но не пишите ему, что там должно быть, какие должны быть вкладки, какие настройки и тому подобное, просто потому что он уже не джун, мне его очень жаль. Возлагать свою работу по проработке тз на дизайнера (а в таком случае именно дизайнеру, которого просто бросили в это окно настроек без объяснения, придется прорабатывать тз, а потом согласовывать, вами) это прям совет дня.
Вот вам совет: ТЗ всегда должно быть прописанным подробно, насколько это возможно, с требованиями, со связями, сроками и, возможно, даже низкокачественными макетами в пейнте. Чтобы когда придёт время новому сотруднику что-то менять, он не открыл задачу прошлого года, а там "нарисуй плс окно настроек спс".
- а кто задачу ставил? Где тз?
- хз, задачу ведь миддл дизайнер делал, вот еще мидлу тз нормальное п сдать.
Бомбануло знатно у меня, извините.
Остальные советы норм.
Мне кажется, дизайнер должен получать проблему, а не задачу.
Плохо: Нарисуй красную кнопку, она должна триггерить модальное окно. В нем будут такие поля...
Хорошо: эта страница плохо конвертит. Нужно подумать, почему и как решить эту проблему.
В первом случае дизайнер будет жертвой клиентов, дедлайнов, менеджеров и т.д. Второй подход воспитывает инициативного и глубокого специалиста.
Наболело, понимаю вас) тоже сталкиваюсь часто с плохими ТЗ и приходится всё самой уточнять. Так не должно быть.
Но мне кажется, что этот совет подходит для тех дизайнеров, которые постоянно работают с одним и тем же менеджером на потоке и делают оч похожие задачи. Им как будто незачем ТЗ расписывать, они и так эти окна настроек постоянно делают. Только время нерационально тратить и ПМ, и дизайнера — ему писать лишнее, дизайнеру читать лишнее))
Все люди разные и к каждому нужен индивидуальный подход.Да кто то умнее,быстрее,опытнее.Вот поэтому и нужно давать задание понимая опыт специалиста и подробнее рассказать что именно от него требуется.
Дизайну стоит уделять много времени.Так что данная статья и советы будут полезно.Как для новичков так и для тех кто давно в деле.
У любого человека в любой профессии есть свои слабые и сильные стороны в том числе и у менеджерам по проектам. Даже если он многое умеет то все равно будут такие ситуации где возможны ошибки или промахи. Для этого и существует понятие взаимодействия в данном случае менеджера и дизайнера. Что не увидел один, то обязательно заметит другой и подскажут друг другу если что не так.
Уважаемые разработчики сделайте сейф или маленькую коробочку м таймером для нетерпеливых