Как мы тестовые для найма создавали

Привет, повествует Демид. За неделю я провел интересный кейс: создал уникальное тестовое задание для дизайнеров. Почему оно уникальное, процесс создания, с чем профакапился и что получилось круто – всё ниже. Прагматичного прочтения!

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

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

Портфолио нужны для первичного отбора. Выбирать между 2-3 кандидатами по картинкам из Behance или Dprofile – невозможно. У портфолио 3 существенных недостатка:

• Отсутствие ограничений
  Доподлинно не знает никто, сколько часов дизайнер решал задачу в рамках кейса, который вообще могли менторить. Пока владелец портфолио не сознается, то никто и не узнает подробностей, которые нам очень важны.
  
  
• Не соответствует нашим рабочим задачам
  Опустим первый пункт и представим дизайнера, который имеет неплохой скиллсет и вписывается в бюджет. Но в портфолио нет решенных задач, схожие с нашими. И как такого взять в проект?
  
  
• Не свой кейс
  То, что создавали в команде: нельзя хотя бы минимально объективно оценить скиллсет\значимость дизайнера. Про любое воровство (в чистом и привычном виде) даже говорить нет смысла.

Первым делом я проанализировал референсы: почему топовые агентства и бигтехи «пишут» именно так – разбирал глобально и детально. К каким выводам пришел:

1. В основе лежит конкретная задача компании
   Дизайнеру отдают то, что уже решали в продуктовом процессе. Это самое наглядное сравнение: как справился штатный дизайнер и соискатель. Тестовые-задачки текущего проекта в эту категорию не записываем – халтура со стороны работодателя)
   
   
2. Расплывчатость формулировок
   Задачу или результат называют четко, но конкретики «как и что» не дают. Осознать и составить план решения – лежит на тебе. Некоторая «размытость» дает простор дизайнеру, от чего в решении наблюдаем всю глубину и масштаб продуктового мышления.
   
   
3. Ограничения
   Поставленное «Формат сдачи – PDF» приучает к дисциплине: нарисовать презентацию и дополнительно аргументировать решение исследованиями, а не оставить рисовашки в Фигме.
   
   
4. Сроки
   Рассчитывают по тем же реальным таскам предыдущих кейсов (смотри п.1). Для дизайнера дедлайн – драйвер, так как всегда азартно проверить скилл и сделать задачу за время, а для работодателя – регулировщик.
   
   
5. Привычная среда
   Во многих тестовых приходится дизайнить то, чем зачастую пользуешься сам. Это позволяет быстрее вкатиться в процесс и потратить время только на решение. Но иногда это загубит дизайнера – онбординг проводить не требуется, в отличие от проектов работодателя.

Все эти пункты я возвел в абсолют и составил MVP вариант. Но пока что мы только на четверти процесса.

Определил ЦА – продукт джун-миддл. Порыскав чаты, отобрал 3 коммьюнити, куда заслал инвайт. Дело нехитрое: большинство участников ищут работу, делают портфолио или тренируют тестовые.

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

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

Особенность нашего тестового в том, что используется для найма на текущий проект (а дальше как пойдет). Я наглядно показал проблему, обозначил задачу и дал полную свободу действий, ограничив только сроком.

Для продукта я выбрал Телеграм, в котором нужно провести работу над одной фичей – Папками:

• Чтобы пользовались чаще
  Многие действительно забывают и не пользуются этой функцией. Хотя Фолдеры я считаю неотъемлемой частью телеги – сортировка сильно ускоряет процесс и приоритизацию диалогов.
  
  
• Оптимизировать и ускорить для тех, кто уже пользуется
  Затруднения с сортировкой по Фолдерам увеличиваются с каждым новым чатом. Автоматизировать процесс нельзя – приходится вручную.

А теперь про критерии. Такие же будем использовать в реальной ситуации, а не на полигоне:

• Анализ среды и задачи
  Телеграм – готовый продукт, который можно долго изучать: как тут проводят онбординг, где и в каком флоу распределяют и компонуют фичи. Чем сильнее респондент вник в контекст, тем обоснованнее и увереннее решение.
  
  
• Продуктовость
  Выстраивание процесса наглядно показывает, как мыслит дизайнер. Важны не столь сами методологии, сколь осознание целей и ограничений. Мыслить масштабно в рамках продукта и бизнеса, а также в проблемах и барьерах пользователя – вот, что действительно ценно.
  
  
• Оформление
  Сторителлинг и аккуратность документа играют не второстепенную роль. Если дизайнер позаботился о том, чтобы я не уснул при прочтении – позаботится и об аргументации решений стейкхолдеру\клиенту.

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

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

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

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

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

Если вы студия. Статья полностью посвящена МВП версии тестового – с помощью него можно отсеять кандидатов, но оно не универсально и не адаптивно.

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

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

Сейчас сложно измерить пользу, которую дает тестовое. Но три вещи я знаю наверняка: в реальном поиске сотрудника я не пропаду, кейс дал драйв и новый опыт, эту статью читаете прямо сейчас вы).

Подписывайтесь, впереди много интересного! Рабочий, а не только красивый дизайн делаем тут. Еще о дизайне пишем.