Введение
Привет, повествует Демид! За неделю я провел интересный кейс: создал уникальное тестовое задание для дизайнеров. Почему оно уникальное, процесс создания, с чем профакапился и что получилось круто – всё ниже. Удачного прочтения.
Для чего тестовое
В работе мы ценим результат, который оцениваем в двух показателях: ttm и продуктовые метрики. Метрики – следствие работающего дизайна, а сроки зависят только от нас.
Эксцессы случаются. Когда человек резко по непредвиденным обстоятельствам берет оффдей – событие не один на миллион. Поэтому мы решили создать тестовое: вдруг такое случится в ближайшем проекте, а план действий заранее подготовлен.
Почему не отсечь дизайнеров по портфолио?
Портфолио нужны для первичного отбора. Выбирать между 2-3 кандидатами по картинкам из Behance или Dprofile – невозможно. У портфолио 3 существенных недостатка:
-
Отсутствие ограничений
Доподлинно не знает никто, сколько часов дизайнер решал задачу в рамках кейса, который вообще могли менторить. Пока владелец портфолио не сознается, то никто и не узнает подробностей, которые нам очень важны. -
Не соответствует нашим рабочим задачам
Опустим первый пункт и представим дизайнера, который имеет неплохой скиллсет и вписывается в бюджет. Но в портфолио нет решенных задач, схожие с нашими. И как такого взять в проект? -
Не свой кейс
То, что создавали в команде: нельзя хотя бы минимально объективно оценить скиллсет\значимость дизайнера. Про любое воровство (в чистом и привычном виде) даже говорить нет смысла.
На что опирался при составлении тестового
Первым делом я проанализировал референсы: почему топовые агентства и бигтехи «пишут» именно так – разбирал глобально и детально. К каким выводам пришел:
-
В основе лежит конкретная задача компании
Дизайнеру отдают то, что уже решали в продуктовом процессе. Это самое наглядное сравнение: как справился штатный дизайнер и соискатель. Тестовые-задачки текущего проекта в эту категорию не записываем – халтура со стороны работодателя) -
Расплывчатость формулировок
Задачу или результат называют четко, но конкретики «как и что» не дают. Осознать и составить план решения – лежит на тебе. Некоторая «размытость» дает простор дизайнеру, от чего в решении наблюдаем всю глубину и масштаб продуктового мышления. -
Ограничения
Поставленное «Формат сдачи – PDF» приучает к дисциплине: нарисовать презентацию и дополнительно аргументировать решение исследованиями, а не оставить рисовашки в Фигме. -
Сроки
Рассчитывают по тем же реальным таскам предыдущих кейсов (смотри п.1). Для дизайнера дедлайн – драйвер, так как всегда азартно проверить скилл и сделать задачу за время, а для работодателя – регулировщик. -
Привычная среда
Во многих тестовых приходится дизайнить то, чем зачастую пользуешься сам. Это позволяет быстрее вкатиться в процесс и потратить время только на решение. Но иногда это загубит дизайнера – онбординг проводить не требуется, в отличие от проектов работодателя.
Все эти пункты я возвел в абсолют и составил MVP вариант. Но пока что мы только на четверти процесса.
Поиск респондентов и подготовка
Определил ЦА – продукт джун-миддл. Порыскав чаты, отобрал 3 коммьюнити, куда заслал инвайт. Дело нехитрое: большинство участников ищут работу, делают портфолио или тренируют тестовые.
На этом я и сыграл: я получаю тестовое, вы получаете фидбек. Потом никто не отказался от ревью, что обрадовало еще сильнее. Может выручил аскетизм респондентов, которые вин-вином решили помочь и мне.
Шесть дизайнеров во всеоружии пилят тестовое, а я создаю презентацию и полностью расписываю свое решение. Заранее готовил и согласовывал со стейкхолдером тему и вопросы ревью, чтобы не профакапиться на месте. Прям как в реальных исследованиях)
Критерии оценки и само тестовое
Особенность нашего тестового в том, что используется для найма на текущий проект (а дальше как пойдет). Я наглядно показал проблему, обозначил задачу и дал полную свободу действий, ограничив только сроком.
Для продукта я выбрал Телеграм, в котором нужно провести работу над одной фичей – Папками:
-
Чтобы пользовались чаще. Многие действительно забывают и не пользуются этой функцией. Хотя Фолдеры я считаю неотъемлемой частью телеги – сортировка сильно ускоряет процесс и приоритизацию диалогов.
-
Оптимизировать и ускорить для тех, кто уже пользуется. Затруднения с сортировкой по Фолдерам увеличиваются с каждым новым чатом. Автоматизировать процесс нельзя – приходится вручную.
А теперь про критерии. Такие же будем использовать в реальной ситуации, а не на полигоне:
-
Анализ среды и задачи
Телеграм – готовый продукт, который можно долго изучать: как тут проводят онбординг, где и в каком флоу распределяют и компонуют фичи. Чем сильнее респондент вник в контекст, тем обоснованнее и увереннее решение. -
Продуктовость
Выстраивание процесса наглядно показывает, как мыслит дизайнер. Важны не столь сами методологии, сколь осознание целей и ограничений. Мыслить масштабно в рамках продукта и бизнеса, а также в проблемах и барьерах пользователя – вот, что действительно ценно. -
Оформление
Сторителлинг и аккуратность документа играют не второстепенную роль. Если дизайнер позаботился о том, чтобы я не уснул при прочтении – позаботится и об аргументации решений стейкхолдеру\клиенту.
Интервью
В гуглмите провел ревью с 6 дизайнерами, суммарно 6 часов – говорили не только про тестовое, но другие интересные темы и людей. Отмечу: важно было познакомиться и создать атмосферу, иначе разговор не пошел бы.
Само ревью состояло из двух смысловых частей – оценка решения респондента и мой вариант. Тут и первый факап: я больше рассказывал, нежели показывал. Мемно было и то, что спустя день вспомнил, что забыл рассказать важную деталь. Равносильно упущенному аргументу из спора пятилетней давности).
Факапы и инсайты
Меня приятно удивило, что дизайнеры реально вникли в процесс и прошли по предполагаемому мною пути. Изучили среду и сегментировали ца, взяли интервью и осознали потребности, рассматривали и выбирали решения в рамках продукта и бизнеса.
НЕприятно удивили факапы с моей стороны. Я вышел в неидеальную конверсию из-за некачественного поиска и обработки респондентов, да и первые ревью провел чуть неудачно.
Главное: после отработки очередной гипотезы (или уже концепта) сделать выводы и замерить результаты, переосмыслить и создать новую гипотезу. Отчаиваться и опускать руки – путь в никуда.
Хотите также?
Если вы студия. Статья полностью посвящена МВП версии тестового – с помощью него можно отсеять кандидатов, но оно не универсально и не адаптивно.
Например, отсутствие ограничений помогло респондентам, но усложнило задачу мне – я вынужден рассматривать и анализировать оба девайса. В реальном найме такие «усложнения» замедлят процесс.
Если вы дизайнер. Пишите в телеграм! Я поделюсь уже переработанным тестовым и также проведу ревью, только с полной презентацией, а не демо-версией. Итерациями собирать фидбек и тестировать гипотезы – основной принцип всего продуктового дизайна.
Прощаемся
Сейчас сложно измерить пользу, которую дает тестовое. Но три вещи я знаю наверняка: в реальном поиске сотрудника я не пропаду, кейс дал драйв и новый опыт, эту статью читаете прямо сейчас вы).
Подписывайтесь, впереди много интересного! Рабочий, а не только красивый дизайн делаем тут. Еще о дизайне пишем.
