Тестовое задание для product designer: фреймворк решения, ошибки и примеры

Привет. Я Вова Кузин — продуктовый дизайнер. В прошлом году я переехал в Израиль и потратил больше 4 месяцев на поиск работы. В этой статье я расскажу про выполнение тестовых заданий, которые мне давали зарубежные и российские компании.

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

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

Статья будет максимально практичной. Разберем основные ошибки, которые я допускал, и успешные практики, которые можно переиспользовать, c примерами из реальных тестовых заданий.

Задание: В первом примере рассмотрим, как лучше не делать тестовые задания. Тестовое было от b2b стартапа, который помогает бизнесам презентовать свои продукты.

Ссылка на вложенный документ: discovery document (сейчас задание в этой компании немного отличается, но суть плюс-минус одинаковая).

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

Ошибка 1 — Понимание задания.

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

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

Ошибка 2 — Презентация решения.

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

Не стоит думать, что после тестового, вас точно ждет собеседование, где вы всё расскажете и объясните. В презентации отразите весь процесс: какие делали выводы на каждом этапе и как это повлияло на решение.

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

Мы разберем каждый пункт, с примерами из решений двух тестовых заданий.

1. Research (Why? Who?)

2. Problem-solving (What?)

3. Solution

4. Метрики успеха

5. Next steps (опционально)

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

Презентация решения

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

Презентация решения

Какие возможности для бизнеса это создает? Интервьюеры понимают, что вы ограничены в реальных данных, у вас нет доступа к планам и стратегии компании, поэтому на этом этапе нормально делать предположения. Два ваших помощника:

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

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

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

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

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

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

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

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

Если у вас не получается найти респондентов в соц сетях, то есть телеграм-каналы, например Кастдев-Чат, где можно запустить количественное исследование и найти респондентов на качественное интервью.

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

Не путайте потребности и возражения. Частая ошибка — фокус на самой проблемной аудитории, которая испытывает максимальное количество возражений. Разрешение возражений зачастую не является способом получить пользователя, и не имеет ничего общего с его потребностями. Постарайтесь понять, кто уже «платит» за решение проблемы, эти пользователи принесут наибольший эффект для бизнес-целей.

Видео про это: ABCDХ-сегментация

Персона в части Problem Solving — это инструмент, который поможет объяснить на какой группе пользователей вы сделали итоговый фокус перед генерацией идей. Сделайте персону более человечной, сфокусируйтесь на действиях пользователя, а не на социально демографическом портрете.

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

Для приоритизации обычно используют матрицу impact/effort, это позволяет в условиях недостатка информации сделать максимально быстрые выводы о том, какая идея будет наиболее дешевой в реализации и принесет максимальный эффект.

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

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

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

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

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

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

Объясню на примере. Мне необходимо было сделать функционал разделения покупок для клиентов банка. Но, помимо этого, можно предложить способ вовлечения неклиентов, что положительно отразится на финансовых показателях банка. Но не тратьте много времени на второстепенные сценарии, достаточно отобразить их на уровне идеи с минимальной визуализацией.

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

Я использую универсальный HEART фреймворк от Google. Фреймворк разбит на пять основных категорий: счастье, вовлеченность, принятие, удержание и успех выполнения задачи. Он объясняет с помощью каких метрик их измерить. Подробнее по ссылке: Инструкция по фреймворку HEART.

Этап позволяет проявить ваше стратегическое мышление и подготовиться к частому вопросу на собеседовании: "Что бы вы улучшили в предложенном решении?".

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

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

Если вы выполняете тестовое задание и нуждаетесь в обратной связи — пишите мне в телеграмм @Kuzin_V

Мои другие статьи:

Product designer — этапы собеседования за границей и их особенности