Я делал тестовые в течение 10 лет. Опыт того, как делать тестовые в 2025 году

Я бы хотел сказать, что тестовые больше не актуальны. Что им на смену пришли вайтборд-задачи, интервью и быстрые практические сессии. И в чём-то это правда. В крупных компаниях всё чаще проверяют дизайнеров на мышление, а не на «пиксели».

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

Немного об авторе

Я продуктовый дизайнер,веду канал «Дизайн душнила», записываю подкаст «Дизайн и люди», менторю молодых дизайнеров и решаю тестовые. В начале я делал их в попытке устроиться хоть куда-то. Потом — чтобы попасть в компанию мечты. И вот уже два года я методично улучшаю свой процесс: от вопросов до выполнения к финальной презентации.

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

Как мои решения выглядели раньше

Сначала всё было просто:

Получал задачу → открывал редактор → делал решение → отправлял → надеялся

Презентация решения в 2016 г., цвет.

Один из экранов решения

Никакой логики, описания моего процесса и того, как я пришёл к решению. Только экраны и надежда. Иногда это работало, но чаще — нет.

Я не умел «продавать» ход мысли. А нанимателям именно это и важно.

Со временем всё начало меняться.

Тестовое в Контур, 2019 г.

На этом этапе стали появляться:

• Описание проекта и краткое саммари

• Подписи к элементам и логике

• Отдельные состояния и минорные элементы4. Адекватный к кейсу текст

Но всё ещё не было презентации и визуализации моих размышлений. Это всё ещё был один, правда длинный, экран.

Тестовое Мегамаркет 2024 г.

На этом этапе у меня уже выстроен процесс решения задач в тестовых.

Я включаю в него:

• Фазу погружения и исследования (Дискавери)

• Прототипы и финальный дизайн

• Локальную дизайн-библиотеку

• Ассеты в виде иконок, иллюстраций и прочих материалов

• Презентацию решения, так как дизайн ≠ презентации и те же кликабельные прототипы я отправляю в презентацию, чтобы показать путь пользователя

Организация файлов в Figma

Такая организация пространства не доступна в бесплатной версии, но вы можете поискать способы оформить студенческую Figma или купить студенческий аккаунт на сторонних ресурсах. Первое бесплатно, вам нужен только VPN и время на поиск, второй стоит в пределах 2 500 ₽

Из чего состоит хорошее тестовое

Я выработал систему. Простую, но устойчивую. Она работает в тестовых, вайтборде и реальных задачах. Выглядит она так:

• Погрузиться и понять задачу

• Показать процесс

• Изучить продукт и конкурентов

• Пообщаться с пользователями

• Выдвинуть гипотезы

• Составить карту пути или логику

• Прототипировать и сделать дизайн

• Собрать презентацию и презентовать

Теперь пройдёмся по каждому пункту.

Погрузиться и понять задачу

Всегда советую начинать с понимания задачи. Для начала ответь себе на эти вопросы:

• Что нужно сделать?

• Тебе хватает вводных?

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

При выполнении тестовых я задавал подобные вопросы (вырваны из контекста, но зато это наглядный пример):

«Правильно понимаю, что мы говорим о странице навигации именно в задании?»

«Можно делать хоть под веб хоть под мобилку?»

«Если есть какие-то ассеты, которые необходимо переиспользовать — пришлёшь? (шрифт или логотип) Я вижу, что используется шрифт #название_шрифта. У меня его нет)»

«Мы же затрагиваем и каталог и поиск, верно?»

Показать процесс

Процесс выполнения задачи

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

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

Изучить продукт и конкурентов

Если есть доступ к текущему решению — анализирую, как оно устроено и «где болит».

Анализ текущего решения

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

Где искать, похожие продукты?

• benchmarkee

• mobbin

• landbook

• lookslike

• pinterest

• dprofile

• behance

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

Решения в других продуктах

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

Не забывай — ты анализируешь решение, а не оцениваешь картинки.

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

Пообщаться с пользователями

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

Как провести опрос или интервью:

• Сформируй базовые гипотезы, которые хочешь подтвердить или опровергнуть

• Подбери к гипотезам вопросы. Если у тебя будет опрос, то закрытые вопросы ок. Если интервью — нет

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

• Проведи опрос или интервью

• Оформи результаты, запиши инсайты и сделай общие выводы

Результаты интервью

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

Выдвинуть гипотезы

Гипотезы могут звучать так:

• Решение поможет пользователю сделать то или иное действие.

• Повысит ту или иную метрику, если о них опять же говорилось.

• Пользователь может столкнуться со сложностями на этом этапе.

• Пользователю будет удобно решать свою задачу этим способом и тд.

Составить карту пути или логику

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

Простая блок-схема для тестового в банк

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

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

Кратко, быстро и доступно, чтобы не изучать всю проделанную работу, но быть в курсе основных моментов.

Прототипировать и сделать дизайн

Казалось бы, что дизайнеры начинают свою работу с рисования картинок, но на самом деле до начала «рисования» мы проходим долгий путь исследований и изучения.

Процесс до прототипирования

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

Прототипы с базовой логикой и описанием

Всё по-классике:

• Lo-fi прототипы

• Доработка логики на Lo-fi

• Тестирование различных вариантов

• Разработка UI

Переход от изучения к финальному дизайну

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

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

Дизайн — это важно

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

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

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

А ещё не забудь собрать свой UI-kit или библиотеку.

Собрать презентацию и презентовать

Кажется, что почти всё сделано, но хорошая презентация является одним из важных факторов защиты твоего решения. Сильная и уверенная презентация — огромный плюс к вашей защите.

Как презентовать

• Собираем презентацию
  Именно собираем, а не показываем сразу экран фигмы с секцией. Без «летаний» мышкой. Просто: текст, скрины, логика.Твоя презентация должна добавлять смыслы, помогать тебе в рассказе и заострять моменты на действительно важных вещах.

• Прогоняем
  Несколько раз вслух. Можно прогнать друзьям или родственникам. Это поможет отточить твоё повествование и уложиться в тайминг, так как рассказывать про свой кейс можно будет часами, а времени у тебя будет минут 10–15 на саму презентацию. Потом можно будет перейти к решению и уже ходить по экранам.

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

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

А как же вайтборды?

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

Хорошая новость: этот подход к решению работает и там, и там.

Вывод

Тестовое — это не способ «проверить тебя». Это возможность показать, как ты думаешь.

Если ты просто отдаёшь макет — это лотерея. Если рассказываешь, как к нему пришёл — это уже сильная позиция.

Поэтому повторю:

• Не бойся уточнять

• Пиши гипотезы и объясняй, почему ты делаешь именно так

• Документируй процесс

• Покажи, что ты не просто рисуешь, а проектируешь

• Презентуй и расскажи о всём своём процессе, так ты увеличишь ценность своей работы

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

Шаблон решения

Если этот материал оказался полезен — делись с друзьями-дизайнерами, которые сейчас собесах или хотят структурировать свой подход, а ещё подписывайся на мой канал. Там много полезного ;)