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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. benchmarkee

2. mobbin

3. landbook

4. lookslike

5. pinterest

6. dprofile

7. behance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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

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

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

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

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

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

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