— Привет! Мы решили нанять тебе помощника на текущий проект, нашли подходящего кандидата. Кстати, он выходит в понедельник. — Эммм, окей. Реакция — Почему моего мнения не спросили!? Почему именно я буду им заниматься? Может я не хочу тратить свое время!? — Я не готов! Не уверен, что у меня не получится. — О боже, еще одна обязанность, за которую мне не платят! Да, такое бывает, иногда бизнесу виднее как вести дела, масштабировать продукт и как растить команду, поэтому я предлагаю опустить рассуждения на эту тему и двинуться дальше — впереди самое интересное! Представьте что перед вами вы, только в самом начале карьеры — постарайтесь сделать процесс взаимодействия и обучения максимально комфортным, ведь вы уже знаете, что важно в профессии, а что не очень, что можно пропустить и где можно срезать углы, а где наоборот — потребуется приложить больше усилий. Сейчас лучший момент чтобы воспользоваться этими знаниями. При этом стоит учитывать, что у всех людей разный опыт — у кого-то в начале всё прошло гладко и он после учебы попал в хорошую компанию, а кто-то скитался по мелким студиям или галерам, где процесса онбординга не было в принципе, а к новичкам относились без должного уважения. Ваш подопечный такой же дизайнер, как и вы — ваша задача помочь ему набраться опыта и периодически тюнить его направление развития, если он забредает не туда. Круто когда есть документ в Ноушен (необязательно Ноушен, подойдет что угодно) с наиболее базовыми вопросами, например, как получить доступы, где лежат файлы, как создать аккаунт в Слаке, а так же, что делать, если заболел и как правильно уйти в отпуск и прочее.  Если нет, то возможно, стоит подумать над этим, пригодится в будущем. Совсем классно, когда у вас есть чек-лист для новичка, с пунктами которые нужно выполнить за первую неделю, месяц, или весь испытательный срок — просто и удобно контролировать. После того как вы закрыли некоторые базовые вещи, важно проговорить свои ожидания от сотрудничества, озвучить критерии по которым вы будете оценивать работу специалиста, какую часть продукта должен закрывать новичок и за что быть ответственным, а так же ожидаемые сроки.Посвятите человека в ваши личные принципы работы и принципы работы компании. Если у вас приняты специальные рабочие ритуалы, поделитесь и этим. Двигаемся дальше и знакомимся с командой — один созвон со всеми или серию один на один, не принципиально.Обсудить что новый дизайнер предпочитает вы можете и на общем созвоне — окрошку на квасе или кефире, Marvel или DC.Если вы ходите в офис, закажите пиццу и позвольте команде поболтать всем вместе, или возьмите человека на обед — тут уж что вам больше нравится. Запульнуть в человека доступами в Фигму и сказать — давай разбирайся, недостаточно! Расскажите как у вас всё устроено в работе с макетами, расскажите про специфические процессы, может вы как-то по-особенному именуете файлы, или есть особенности в статусах задачи, или вы особым способом передаете файлы в разработку. Полезно будет показать предыдущие итерации вашего продукта, это важно для понимания вектора развития и работы над последующими задачами. Расскажите про культуру добавления новых компонентов в библиотеку, про работу со шрифтами и иконками. После этого можно время взять человека на парочку рабочих встреч чтобы он мог своими глазами увидеть как устроены процессы, а так же начать погружаться в продукт. Для начала можно дать несколько простых заданий и посмотреть как человек справится — по результатам вы увидите где стоит подтянуть. Я бы обратил внимание на следующие критерии: Сроки. Команда разработки ожидает получить готовые макеты к определенному времени. Важно донести до джуна ценность сроков, чтобы не подводить команду. Необходимый и достаточный уровень проработки логики. Вы увидите понял ли человек задачу, нашел ли оптимальное решение или подумал над несколькими вариантами, может ли в деталях объяснить почему выбрал именно то, что выбрал. Как аккуратно собраны макеты. Интересно посмотреть как человек собрал экраны, использовал ли компоненты, обратил ли внимание на стили шрифтов и цветов, и как поладил с дизайн-системой в целом, обсудил новые компоненты с разработчиками, проработал ли все корнер кейсы. Уровень коммуникации с командой. Задавал ли дополнительные вопросы команде разработки, менеджерам и совсем хорошо, если думал как выглядит задача с точки зрения бизнеса. Умение самостоятельно решать проблемы и работать в условиях неопределенности. Вообще самостоятельность, на мой взгляд — это самая главная метрика, которую стоит стараться всеми силами растить в вашем новичке. Чем больше ошибок он будет совершать и исправлять в маленьких задачах, тем проще ему будет работать над крупными проектами. Три момента, которые могут помочь начинающему дизайнеру расти и брать больше ответственности Помимо получения вашего ценного фидбэка и комментариев команды, будет хорошо если решение хоть как-то будет протестировано. Как минимум можно собрать прототип и  устроить коридорное тестирование или потестировать самостоятельно. Если вы работаете над мобильным приложением — пусть посмотрит на него с экрана мобильного телефона, порой тут случается масса незапланированных открытий. Покажите завершенный флоу вашей команде — разработчикам и менеджеру, вероятно они озвучат некоторые замечания. Если у вас есть другие дизайнеры, будет очень полезно получить комментарии по макетам и от них. На этом этапе полученная обратная связь поможет новичку улучшить текущее решение. Не нужно сразу заворачивать решения, которые не выстрелят — дайте человеку немного переварить самому это решение и понять, где его минусы. Более того нужно делать это максимально деликатно и аргументированно, чтобы подтолкнуть человека подумать над еще некоторыми вариантами решения, а не закрыться. Аккуратно подсветите минусы текущего решения и дайте развернутые комментарии, покажите примеры успешных решений схожей проблемы. На самом деле её не существует, но есть три важных пункта: С каждой решенной задачей погружение в продукт будет расти, облегчая вам жизнь. Здорово когда человек сам заинтересован в том, чтобы начать разбираться в тонкостях продукта, это нужно поощрять и быть готовым отвечать на вопросы, иногда на неудобные.На первых этапах важно подталкивать человека и помогать ему понимать ограничения продукта, рассказывать о контексте принятия тех, или иных решений и направления развития. Каждый новый самостоятельный шаг будет отвязывать от вас новичка, и он будет стремительно набирать очки опыта. Это классно и с каждым разом вы сможете всё меньше времени уделять на работу с новичком. Важный момент — одновременно с этим, вам стоит начать делегировать вашему подопечному более сложные задачи, а так же продемонстрировать готовность делегировать ответственность за эти задачи. На первых шагах вы можете помогать — вместе обсудите условия задачи и технические ограничения. Убедитесь, что человек понимает суть задачи и дайте ему свободу найти решение. Обсудите промежуточные результаты через пару дней, а если джун зашел не туда, скорректируйте вектор поиска решения. Тут вопрос на границе вашего эго (перфекционизма, если хотите) и ответственности за продукт.Даже если ваш подопечный спроектировал не самое оптимальное решение, которое в целом находится на достаточном уровне, для того чтобы стать частью продукта — принимайте его таким. Конечно вы всегда сможете с высоты своего опыта и знаний обосновать, почему можно сделать лучше, но если вы уверены, что текущее решение тоже решает поставленную задачу — примите его и отправьте в разработку!Получение результата станет мощной мотивацией для джуна. Даже если, макеты будут не идеальны, вам будет что обсудить и подсказать как сделать лучше в следующий раз. Будет совсем здорово, если через некоторое время вы сможете получить обратную связь от ваших пользователей или данные аналитики, как работает внедренное решение. Пусть ваш джун получит полезный опыт и сам улучшит свое же решение в следующей итерации. В основе любого качественного фидбека лежит честность. Обязательно подсветите моменты, которые получились хорошо. Размытые формулировки могут выглядеть неискренне.Подсвечивая слабые моменты сфокусируйтесь не на проблеме, а на цели. Аргументируйте, почему это не решает поставленную задачу, или решает, но недостаточно оптимальным способом (например, слишком дорого в разработке).Кстати, я считаю, что хвалить нужно и за просто хорошо выполненную работу, необязательно подсвечивать только выдающиеся моменты. Окей! Вы проработали некоторое время и у вашего протеже есть некоторые моменты, которые вы хотели бы подтянуть — смело назначайте встречу и обсудите это.Дайте рекомендации и обговорите сроки, когда будет следующая встреча по результатам работы.Если все прошло хорошо и джун уже в штате и успешно решает продуктовые задачи, фидбэк-сессии разумеется уместны! Обычно достаточно небольшого созвона раз в несколько недель или раз в месяц: узнайте как настроение у человека, есть ли вопросы или какие-то проблемы, как движется прогресс с задачами и персональными целями, есть ли замечания к вашей работе как руководителя (да, и такое тоже надо спрашивать). Внесите в чек-лист пункт с предложениями по улучшению продукта и текущих процессов без оглядки на бюджеты и сроки. Пусть даст волю фантазии. Не стоит недооценивать новичка только из-за отсутствия у него опыта. Работая долго над одним и тем же продуктом часто мы срастаемся с ним и не хотим вносить никакие изменения. Человек со стороны может привнести интересные идеи, просто потому что у него свежий взгляд и нет привязанности к текущим решениям, а отсутствие рамок может сделать их по-настоящему дерзкими и революционными. К сожалению иногда сработаться просто не получается.Человек не подошел в силу слабых навыков, недостаточного погружения в продукт, или по культурному несоответствию духу команды. Ну или компания не оправдала ожиданий новичка нездоровой атмосферой, отсутствием дизайн-культуры, выстроенных процессов и здравого смысла в целом. Разумеется этому есть причина и эту причину нужно честно озвучить вашему новичку — аккуратно, и исключительно по делу. Постарайтесь дать максимально развернутую обратную связь, указать на сильные и на слабые стороны, обязательно дать рекомендации над чем нужно работать. Надеюсь было полезно, спасибо за уделенное внимание! Senior Product Designer at H&B