— Привет! Мы решили нанять тебе помощника на текущий проект, нашли подходящего кандидата. Кстати, он выходит в понедельник.
— Эммм, окей.

Реакция

— Почему моего мнения не спросили!? Почему именно я буду им заниматься? Может я не хочу тратить свое время!?

— Я не готов! Не уверен, что у меня не получится.

— О боже, еще одна обязанность, за которую мне не платят!

Да, такое бывает, иногда бизнесу виднее как вести дела, масштабировать продукт и как растить команду, поэтому я предлагаю опустить рассуждения на эту тему и двинуться дальше — впереди самое интересное!

Без паники!

Представьте что перед вами вы, только в самом начале карьеры — постарайтесь сделать процесс взаимодействия и обучения максимально комфортным, ведь вы уже знаете, что важно в профессии, а что не очень, что можно пропустить и где можно срезать углы, а где наоборот — потребуется приложить больше усилий. Сейчас лучший момент чтобы воспользоваться этими знаниями.

При этом стоит учитывать, что у всех людей разный опыт — у кого-то в начале всё прошло гладко и он после учебы попал в хорошую компанию, а кто-то скитался по мелким студиям или галерам, где процесса онбординга не было в принципе, а к новичкам относились без должного уважения.

Ваш подопечный такой же дизайнер, как и вы — ваша задача помочь ему набраться опыта и периодически тюнить его направление развития, если он забредает не туда.

Онбординг легко

Круто когда есть документ в Ноушен (необязательно Ноушен, подойдет что угодно) с наиболее базовыми вопросами, например, как получить доступы, где лежат файлы, как создать аккаунт в Слаке, а так же, что делать, если заболел и как правильно уйти в отпуск и прочее. Если нет, то возможно, стоит подумать над этим, пригодится в будущем.

Совсем классно, когда у вас есть чек-лист для новичка, с пунктами которые нужно выполнить за первую неделю, месяц, или весь испытательный срок — просто и удобно контролировать.

Обозначьте ваши ожидания и принципы

После того как вы закрыли некоторые базовые вещи, важно проговорить свои ожидания от сотрудничества, озвучить критерии по которым вы будете оценивать работу специалиста, какую часть продукта должен закрывать новичок и за что быть ответственным, а так же ожидаемые сроки.
Посвятите человека в ваши личные принципы работы и принципы работы компании. Если у вас приняты специальные рабочие ритуалы, поделитесь и этим.

Знакомство с командой

Двигаемся дальше и знакомимся с командой — один созвон со всеми или серию один на один, не принципиально.
Обсудить что новый дизайнер предпочитает вы можете и на общем созвоне — окрошку на квасе или кефире, Marvel или DC.
Если вы ходите в офис, закажите пиццу и позвольте команде поболтать всем вместе, или возьмите человека на обед — тут уж что вам больше нравится.

Figma – ещё не всё!

Запульнуть в человека доступами в Фигму и сказать — давай разбирайся, недостаточно! Расскажите как у вас всё устроено в работе с макетами, расскажите про специфические процессы, может вы как-то по-особенному именуете файлы, или есть особенности в статусах задачи, или вы особым способом передаете файлы в разработку.

Полезно будет показать предыдущие итерации вашего продукта, это важно для понимания вектора развития и работы над последующими задачами.

Расскажите про культуру добавления новых компонентов в библиотеку, про работу со шрифтами и иконками.

После этого можно время взять человека на парочку рабочих встреч чтобы он мог своими глазами увидеть как устроены процессы, а так же начать погружаться в продукт.

Проверка на простых задачах

Для начала можно дать несколько простых заданий и посмотреть как человек справится — по результатам вы увидите где стоит подтянуть. Я бы обратил внимание на следующие критерии:

• Сроки. Команда разработки ожидает получить готовые макеты к определенному времени. Важно донести до джуна ценность сроков, чтобы не подводить команду.

• Необходимый и достаточный уровень проработки логики. Вы увидите понял ли человек задачу, нашел ли оптимальное решение или подумал над несколькими вариантами, может ли в деталях объяснить почему выбрал именно то, что выбрал.

• Как аккуратно собраны макеты. Интересно посмотреть как человек собрал экраны, использовал ли компоненты, обратил ли внимание на стили шрифтов и цветов, и как поладил с дизайн-системой в целом, обсудил новые компоненты с разработчиками, проработал ли все корнер кейсы.

• Уровень коммуникации с командой. Задавал ли дополнительные вопросы команде разработки, менеджерам и совсем хорошо, если думал как выглядит задача с точки зрения бизнеса.

• Умение самостоятельно решать проблемы и работать в условиях неопределенности. Вообще самостоятельность, на мой взгляд — это самая главная метрика, которую стоит стараться всеми силами растить в вашем новичке.

Чем больше ошибок он будет совершать и исправлять в маленьких задачах, тем проще ему будет работать над крупными проектами.

Работа над ошибками

Три момента, которые могут помочь начинающему дизайнеру расти и брать больше ответственности

1) Давайте тестировать решения

Помимо получения вашего ценного фидбэка и комментариев команды, будет хорошо если решение хоть как-то будет протестировано. Как минимум можно собрать прототип и устроить коридорное тестирование или потестировать самостоятельно.

Если вы работаете над мобильным приложением — пусть посмотрит на него с экрана мобильного телефона, порой тут случается масса незапланированных открытий.

2) Покажите решение команде

Покажите завершенный флоу вашей команде — разработчикам и менеджеру, вероятно они озвучат некоторые замечания. Если у вас есть другие дизайнеры, будет очень полезно получить комментарии по макетам и от них. На этом этапе полученная обратная связь поможет новичку улучшить текущее решение.

3) Давайте совершать ошибки

Не нужно сразу заворачивать решения, которые не выстрелят — дайте человеку немного переварить самому это решение и понять, где его минусы. Более того нужно делать это максимально деликатно и аргументированно, чтобы подтолкнуть человека подумать над еще некоторыми вариантами решения, а не закрыться. Аккуратно подсветите минусы текущего решения и дайте развернутые комментарии, покажите примеры успешных решений схожей проблемы.

Секретная формула

На самом деле её не существует, но есть три важных пункта:

Погружение

С каждой решенной задачей погружение в продукт будет расти, облегчая вам жизнь. Здорово когда человек сам заинтересован в том, чтобы начать разбираться в тонкостях продукта, это нужно поощрять и быть готовым отвечать на вопросы, иногда на неудобные.
На первых этапах важно подталкивать человека и помогать ему понимать ограничения продукта, рассказывать о контексте принятия тех, или иных решений и направления развития.

Делегирование

Каждый новый самостоятельный шаг будет отвязывать от вас новичка, и он будет стремительно набирать очки опыта. Это классно и с каждым разом вы сможете всё меньше времени уделять на работу с новичком. Важный момент — одновременно с этим, вам стоит начать делегировать вашему подопечному более сложные задачи, а так же продемонстрировать готовность делегировать ответственность за эти задачи.

На первых шагах вы можете помогать — вместе обсудите условия задачи и технические ограничения. Убедитесь, что человек понимает суть задачи и дайте ему свободу найти решение. Обсудите промежуточные результаты через пару дней, а если джун зашел не туда, скорректируйте вектор поиска решения.

Смирение

Тут вопрос на границе вашего эго (перфекционизма, если хотите) и ответственности за продукт.
Даже если ваш подопечный спроектировал не самое оптимальное решение, которое в целом находится на достаточном уровне, для того чтобы стать частью продукта — принимайте его таким. Конечно вы всегда сможете с высоты своего опыта и знаний обосновать, почему можно сделать лучше, но если вы уверены, что текущее решение тоже решает поставленную задачу — примите его и отправьте в разработку!
Получение результата станет мощной мотивацией для джуна. Даже если, макеты будут не идеальны, вам будет что обсудить и подсказать как сделать лучше в следующий раз.

Будет совсем здорово, если через некоторое время вы сможете получить обратную связь от ваших пользователей или данные аналитики, как работает внедренное решение. Пусть ваш джун получит полезный опыт и сам улучшит свое же решение в следующей итерации.

Не забывайте поддерживать

Давайте экологичный фидбек

В основе любого качественного фидбека лежит честность. Обязательно подсветите моменты, которые получились хорошо. Размытые формулировки могут выглядеть неискренне.
Подсвечивая слабые моменты сфокусируйтесь не на проблеме, а на цели. Аргументируйте, почему это не решает поставленную задачу, или решает, но недостаточно оптимальным способом (например, слишком дорого в разработке).
Кстати, я считаю, что хвалить нужно и за просто хорошо выполненную работу, необязательно подсвечивать только выдающиеся моменты.

Направляйте прогресс

Окей! Вы проработали некоторое время и у вашего протеже есть некоторые моменты, которые вы хотели бы подтянуть — смело назначайте встречу и обсудите это.
Дайте рекомендации и обговорите сроки, когда будет следующая встреча по результатам работы.
Если все прошло хорошо и джун уже в штате и успешно решает продуктовые задачи, фидбэк-сессии разумеется уместны! Обычно достаточно небольшого созвона раз в несколько недель или раз в месяц: узнайте как настроение у человека, есть ли вопросы или какие-то проблемы, как движется прогресс с задачами и персональными целями, есть ли замечания к вашей работе как руководителя (да, и такое тоже надо спрашивать).

Развяжите джуну руки

Внесите в чек-лист пункт с предложениями по улучшению продукта и текущих процессов без оглядки на бюджеты и сроки. Пусть даст волю фантазии.

Не стоит недооценивать новичка только из-за отсутствия у него опыта. Работая долго над одним и тем же продуктом часто мы срастаемся с ним и не хотим вносить никакие изменения. Человек со стороны может привнести интересные идеи, просто потому что у него свежий взгляд и нет привязанности к текущим решениям, а отсутствие рамок может сделать их по-настоящему дерзкими и революционными.

Как правильно расставаться

К сожалению иногда сработаться просто не получается.
Человек не подошел в силу слабых навыков, недостаточного погружения в продукт, или по культурному несоответствию духу команды. Ну или компания не оправдала ожиданий новичка нездоровой атмосферой, отсутствием дизайн-культуры, выстроенных процессов и здравого смысла в целом.

Разумеется этому есть причина и эту причину нужно честно озвучить вашему новичку — аккуратно, и исключительно по делу. Постарайтесь дать максимально развернутую обратную связь, указать на сильные и на слабые стороны, обязательно дать рекомендации над чем нужно работать.

Надеюсь было полезно, спасибо за уделенное внимание!