Top.Mail.Ru
Колонки

«Это — мантра, которую я выучила за полгода найма дизайнеров». Кто нужен и не нужен в вашей команде

Колонки
Наталья Стурза
Наталья Стурза

Сооснователь ANGRY

Софья Федосеева

Наталья Стурза, сооснователь ANGRY, рассказала о том, как надо нанимать дизайнеров.

«Это — мантра, которую я выучила за полгода найма дизайнеров». Кто нужен и не нужен в вашей команде

Вот, о чем я говорю, когда нужно рассказать на собеседованиях о нас.

Это – мантра, которую я уже выучила наизусть за полгода активного найма дизайнеров в команду. Мы очень быстро росли, подбирались идейные классные люди, которые хотят развиваться, которым интересно делать сложное.

Набивались шишки, процессы постоянно совершенствовались. Сейчас работа для дизайнера в нашей команде выглядит так.


Команда и спецы

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


Есть возможность роста

Сейчас у нас идет наем и джунов, и мидлов, и лидов. Смышленые растут быстро. У нас есть сильные люди, но их надо еще больше. До конца лета мы вырастем в два раза, а к концу года – страшно подумать.


Вкладываем в 1-2 месяц

Один год опыта или десять лет в дизайне – на рынке очень мало людей с нормальным опытом проектирования и самостоятельного продумывания логики сложных продуктов.

Бэкграунд имеет значение – нет смысла брать людей без задротства в хорошем смысле слова, без хорошего владения инструментами и аналитического склада ума, умения разобраться во всем и изучить тонны внутренней и внешней информации.

Был и опыт неудачного найма за эти полгода.

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

У этих ошибок есть основная причина – мы брали людей без навыка разбираться в сложном и без аналитического склада ума. К этому выводу мы дошли сами только через полгода. И, наверное, это основная причина того, что люди либо не прогрессируют вообще, либо прогрессируют очень медленно. А проверить наличие этого навыка можно лишь косвенно – на тестовом задании или встрече. Теперь на этапе собеседования мы обращаем внимание на эти софт-скилы.


Наставник и онбординг

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

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

И у наставника, и у новичка есть критерии прохождения испытательного срока и хорошо проведенного онбординга.

Вот что наставник делать не должен:

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

Обучение – чему и как?

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

Каждый вечер четверга посвящен обучению. Есть несколько форматов.

  1. Читаем лекции – о банковской сфере, продуктах для бизнеса (это наша основная ЦА проектов), типичных портретах пользователей, принципах текстов в интерфейсах, критериях качества проектирования и построении логики.
  2. Делаем что-то типа воркшопов – показываем прием в инструменте и тут же даем задание применить.
  3. Материалы: еще на этапе испытательного срока наставник показывает все наши наработки и материалы, которыми можно пользоваться. Их много, все в разных форматах: есть большие подробные презентации и отчеты, нарезки и записи тестов и интервью, наборы хороших решений в интерфейсах к конкретным задачам, борды текстов и дизайна. Этим нужно научить пользоваться, а не просто выдать доступ и показать, где оно лежит.
  4. Домашки даются обычно на выработку каких-то скилов: тексты, типографика, сетки.
  5. Погружение в UX – это то, чего сильно не хватает. Но мы стараемся вовлекать дизайнеров в юзабилити-тесты или интервью. Посадить сотрудника посмотреть со стороны на свой проект или провести парочку тестов – это сильно меняет взгляд на потребителя и подход к проектированию. Люди начинают смотреть на продукт глазами пользователя.

Критерии

Что мы хотим увидеть по истечении месяца – измерение прохождения испытательного срока:

  • Новый человек способен изучить тему самостоятельно, а не просто задать все вопросы про все элементы. Нужен не поверхностный, а глубокий подход к задачам.
  • Человек не просто приходит и все расспрашивает, но и приносит решения на основе самостоятельного изучения.
  • Умение брать на себя ответственность, а не переносить ее на наставника – субъективная штука, будет оцениваться именно им.
  • Построение логики и соответствие критериям проектирования – либо овладел, либо есть прогресс в течение месяца.
  • Детальная проработка задач, умение хорошо разобраться и структурировать сложные по функциональности процессы. Отсутствие логических грубых ошибок – таких, когда для того, чтобы ее исправить, надо потратить ⅓ и больше заложенного времени на задачу.

Уровни роста и скилы

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

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

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


Личное развитие

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

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

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

Например, сотрудник работает один месяц и говорит: «Мне кажется, что я очень медленно делаю задачи, меня это напрягает». А мы знаем, что войти в область финтеха в принципе сложно, и все – независимо от опыта – первый месяц работают медленно. На этом этапе важнее наработать скилл детальной проработки и погружения, а скорость придет потом. Нужно просто двигаться и обладать уровнем самосознания.


Есть внутренняя команда, а есть внешняя

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

А есть внутренняя команда – это дизайнеры всех уровней и исследователи. Они делают, а не общаются с заказчиком. И аргументируют, почему так сделали.

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


Основное – это проектирование

Из чего состоит типичная задача? 40% – изучить и спроектировать логику и взаимодействие, еще 40% – отрисовать детальный прототип, а только 20% – натянуть на это дизайн. Тексты в интерфейсах и в каналах взаимодействия с продуктом – это тоже проектирование. Это – основа, на которую легче нарастить дизайнерские скилы.


Дизайнер в западном понимании

Так сложилось (и в других сферах почему-то так тоже бывает), что дизайнер в России – это человек, который рисует, «делает красиво». Ты ему говоришь, как рисовать, рассказываешь про структуру, ответвления, текст, а он рисует. Но в классическом понимании это человек, который «дизайнит» процесс. Перевод и применение слова «дизайн» гораздо шире слова «рисует».

У нас в России недавно придумали для этих скилов новое название «продуктовый дизайнер», по сути, подтверждая, что никто у нас нормально дизайнить и продумывать взаимодействие не может, и поэтому надо придумывать отдельное название профессии.

У нас дизайнер, в первую очередь, тот, кто может продумать и придумать все взаимодействие, спроектировать логику и инфосхему, а потом уже про красоту.


Проекты – только хардкор

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

Срок проектирования и дизайна одного проекта занимает от двух до четырех месяцев.

80% наших клиентов – это финтех, 80% из них – продукты для предпринимателей. Топ-20 банков были или есть наши клиенты. Раньше нам казалось, что придется тратить много времени и средств на привлечение, но оказалось, что у клиента заканчивается один проект, но начинаются другие, потом запускаются следующие версии, потом появляются внутренние стартапы…

Если к нам приходят, то остаются. Или уходят сразу.


Взяли задачу и пошли

Мы стараемся не перебрасывать людей с проекта на проект. Если сформировали команду под конкретную задачу, то больше ничего туда вклинивать уже не будем. Стараемся, по крайней мере. But sometimes shit happens!

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

  • Есть dayly по проектам.
  • Есть груминги – декомпозиция, оценка, обсуждение и назначение исполнителей на задачи.
  • Есть интро по проекту – про нашу позицию, продуктовую концепцию и вовлечение, про целевые портреты, про то, как использовать материалы и принимать на их основе решение.
  • Есть ретро – плюсы и минусы и по проектам, решения по улучшению и ответственные. Аджайл, как любит Греф.

Позиция и знания

Мы держим перед клиентом другую позицию. Последнее слово о том, как функция должна выглядеть для клиента, за нами. А у нас есть цифры из нескольких источников и многолетний опыт качественных исследований.

Там, где известно, как себя ведет клиент, мы создаем проект сразу, а тестируем потом. Там, где сфера или ЦА для нас нова, мы исследуем, а потом проектируем и снова тестируем.

Да, в некоторых проектах сделать идеально нельзя – куча технических ограничений, куча запретов от СБ или «не в этой версии». Но и убеждать с точки зрения KPI и бизнесовых целей мы тоже можем.

А еще есть стандартизация процессов для клиента. У нас не жесткие дедлайны, а еженедельные статусы по выполненным задачам. При этом есть роадмап, сроки и эпики.

В среду показали, что сделали за неделю, до пятницы подождали правки от всех пяти подразделений заказчика, решили, что делаем, а что – нет, и почему, поставили задачи и за вторник сделали правки.


Только качественные исследования

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

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


Исследовательский бэкграунд

Очень круто, что у нас команда выросла из бывших исследователей. Мы уже на уровне инстинктов повернуты лицом к пользователю. Хуже было бы просто нанять исследователя в дизайнерскую команду с целью пропаганды UX.

Всю команду дизайнеров мы пытаемся пропустить через этот опыт: «а как пользуются тем, что я или коллеги спроектировали». Это работает лучше всяких лекций про UX и наставлений «делать нормально». Если получить эту призму восприятия один раз, каждый дальнейший проект пойдет уже через нее.


Оригинал


Материалы по теме:

Как сделать понятный дизайн финтех-сервиса

«VR — это способ запрограммировать мозг». Как построить качественный UX в виртуальной реальности

UX/UI – что это? Разбираемся в терминах

6 книг не про дизайн, которые должен прочитать каждый UX-дизайнер

Все, что нужно знать о работе UX-дизайнера: главные вопросы


Фото на обложке: Unsplash

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 «Яндекс» в 1 квартале нарастил чистую прибыль на 47%, выручку — на 40%
  2. 2 Холодный старт: как начать бизнес, когда данных нет
  3. 3 «Тинькофф» ищет разработчиков в Узбекистане для развития нескольких сервисов
  4. 4 PDCA или цикл Деминга: этапы по улучшению процессов в бизнесе в целом, и в IT-сфере в частности
  5. 5 ERP и Agile: тест на совместимость
DION
Что ждет рынок корпоративных коммуникаций в 2024 году?
Подробнее