Не люблю тестовые задания. Проверить и дать фидбэк иногда может занять столько же времени, сколько сделать само задание. Сейчас есть чем заменить тестовые, особенно при найме старших дизайнеров или лидов. Но если вы мидл или джун, и за вас ещё не говорят ваши предыдущие места работы в резюме, рекомендации бывших коллег и невероятное портфолио, то без тестового задания будет сложно и компании, и вам.
Привет, я Лёша! Сейчас я руковожу командами эмоционального дизайна и UX-редакторов в Альфе. Последние 5 лет я проверял тестовые задания, но до этого больше 7 лет я их выполнял (даже будучи старшим дизайнером). Без тестового просто невозможно было никуда откликнуться.
Тестовые задания всегда были предметом споров среди дизайнеров: делать или не делать, бесплатно или за деньги (кстати, бывало у вас такое?), слишком большое или непонятное, ничего не ответили или фидбек невнятный… Предположим, что вы всё равно решили сделать.
Хочу поделиться, как я сейчас подходил бы к выполнению тестовых заданий и на что я обычно обращаю внимание при их проверке.
🤫 Кстати, отказаться от выполнения тестового задания тоже нормально.
Что такое тестовое задание
Под тестовым заданием я имею в виду задачу, которую вы решаете самостоятельно в заранее оговоренный период времени дома, а не white board challenge в онлайн- или офлайн-формате, хотя в подходах может быть много общего.
Тестовое задание — это пробный период на работу с вами, но решить задачу и презентовать решение — вещи разные. И тестовое задание в первую очередь — презентация и рассказ, а не подготовка макетов к разработке. Это рассказ о ходе ваших мыслей в реальной дизайн-задаче, но при этом это не реальные условия.
В рабочей задаче вас не оставят в одиночестве на неделю что-то изобретать и проводить коридорные тестирования без контекста и понимания специфики продукта. Поэтому нет смысла ограничивать себя условиями, которые явно не прописаны в задании. Например, вы можете менять UI, если при этом сохраните узнаваемость бренда.
😲 Кстати, однажды дизайнер пришёл на интервью с выполненным тестовым заданием, которое он сам себе придумал.
Зачем
Итак, вы внимательно прочитали задание и поняли, что именно нужно сделать (на этом этапе тоже можно отказаться, если что). Но зачем вообще понадобилось делать тестовое? Причины могут быть разные, но я вижу смысл в тестовом, если портфолио и резюме не рассказали всё о ваших возможностях. То есть в вас верят, но вопросы остались.
Например, у вас 3 кейса в портфолио: лендинг для веба, концепт приложения и приложение pet-проект. Всё красиво, но что будет с более сложными продуктами? Или наоборот — вы работали со сложным B2B-проектом, где не было возможности сильно развернуться в плане UI, а будущие задачи это предполагают.
Тестовое задание не единственный критерий для принятия решения. Для меня важна совокупность: где вы работали, какие проекты делали и как о них рассказываете, есть ли рекомендации от знакомых, как прошла встреча с вами — у каждого нанимающего менеджера свои любимые критерии, но тестовое задание — только один из них и не всегда главный. Поэтому можно даже сделать акцент в тестовом задании на том, чего не хватает в вашем портфолио.
🤔 Кстати, нормально задать вопросы в процессе выполнения тестового задания.
Время
Самое важное ограничение в рамках тестового задания — время. Зависит от договоренностей, но в среднем у вас неделя.
Подумайте, что вы сможете сделать на высоком уровне за эту неделю (то, что обеспечит вам 80% результата при 20% усилий). Решите, на чём вы можете сэкономить, чтобы лучше проработать само решение. Подумайте, сколько потребуется на ресёч, проработку решения и его презентацию.
Помните, что если ваше решение слабое, скучное, непродуманное, то его упаковка или проведённые тестирования — делу не помогут. Также и отправка задания раньше срока поможет только в случае, если результат хороший. У каждого свой темп работы, но я бы закладывал 60% времени на проработку решения, 25% на его упаковку, а остальные 15% — на всё остальное.
🤯 Кстати, нормально попросить ещё немного времени, заранее предупредив, ведь непредвиденные обстоятельства бывают у всех.
Решение
Решением тестового задания будет не только экран фичи, которую вы делаете, а вообще всё от ресёча и анализа конкурентов до финальной упаковки в презентацию, прототипа или скринкаста.
😏 Кстати, в тестовом задании нет одного правильного решения, до которого вам нужно додуматься.
Любую дизайн-задачу можно решить разными способами, которые будут по-своему хороши и иметь недостатки. Как сказал бы любой дизайнер: всё зависит от задачи.
В реальности вы не будете одиноки в поиске решения, а будете двигаться более частыми итерациями обсуждений с коллегами. Удобно, когда есть несколько поверхностно проработанных направлений, из которых можно выбрать наиболее перспективные, доработать их детальнее, проверить на пользователях, а потом добить до финального решения то, которое пойдёт в разработку.
В тестовых заданиях я бы действовал так же. Сохраняйте все черновики других менее проработанных решений, а потом расскажите, почему и как вы выбирали лучший вариант. Так у вас будет план Б на случай, если что-то пойдёт не так с основным решением, и больше тем для обсуждения на презентации.
Подача
☝️ Кстати, то, как именно презентовать решение, решаете тоже вы.
Всё зависит от ваших возможностей. Видео, анимации, кликабельный прототип, отдельные экраны, презентация с пояснениями — всё подходит (если это явно не обозначено в задании), главное объясните, как работает ваше решение, и расскажите, почему вы так решили. То, как вы презентуете результат, — важно. Если вы замахнулись на сложный анимированный прототип и не смогли собрать его достойно — это повлияет на общее впечатление, поэтому лучше выбрать формат, который вы сможете собрать быстро и качественно.
Хороший формат наглядности и просторы, чтобы продемонстрировать механику работы — это саджесты фичей в Телеграме:
Разумеется, нужно дополнить это ходом своих мыслей, показать процесс, ресёч, макеты и черновики и собрать в складный рассказ. К примеру, вы можете записать короткий скринкаст со всеми пояснениями (что ещё знаете кроме Лума?). Такую видеопрезентацию удобно переслать коллегам и лишний раз не созваниваться.
База рассказа
- Погрузите в контекст. Обязательно кратко расскажите, какая была задача, потому что не все в курсе, какое было задание.
- Ресёч — недооценённый инструмент в тестовых заданиях. Несложный и не займёт много времени, но очень полезен для всех. Например, вы делаете онбординг для клиентов банка: расскажите, какие онбординги делают прямые конкуренты, какие типы онбордингов в целом бывают и какие есть лучшие практики. На мой взгляд, это универсальный способ добавить ценности проделанной работе. Тем более, что есть сервисы, которые уже собрали всё за вас (накидайте в комменты ваши любимые).
- Проанализируйте. Расскажите про основные направления решений. Например, вы наресёчили, что многие конкуренты делают онбординги в виде сторис, насколько это подходит вам? Стоит ли делать так же или это возможность отстроиться?
- Решение. Что в итоге получилось, как работает и почему вам кажется, что сработает? Какие были ещё варианты?
- Заключение. Сюда я бы выносил всё, что вы хотели ещё рассказать, но это не относится к предыдущим пунктам. Например, вы провели исследование прототипа на друзьях и делитесь результатами или говорите, что для вас было самым сложным/интересным, или, может, у вас остались вопросы.
Что цепляет
Инициатива и вовлечённость сразу заметны. Когда вы действительно включились в задачу, а не подходите формально к её выполнению, это отражается и на решении. У вас появляется больше идей, черновиков, вопросов, желания что-то предложить или поменять.
И, конечно, цепляет смелость. Если у вас получилось слишком смелое, на ваш взгляд, решение, то обязательно покажите и его, вдруг именно из-за него вас и запомнят.
Дизайн — это живой процесс, поиск решений, постоянные изменения и копии фреймов, поэтому не стесняйтесь демонстрировать этот процесс, он важен.
❤️ Кстати, у вашего тестового задания тоже есть пользователи, которые хотели бы узнать, что вы сможете привнести в продукт своим дизайном.
Автор:
Алексей Григорьев, арт-директор в Альфа-Банке
