Как дизайнеру успешно пройти Whiteboard

Может быть совпадение, но после моей первой статьи про WB в некоторых российских компаниях стали появляться первые версии этого челленджа (и у меня даже появился опыт его прохождения), чему я безусловно рад.
Сегодня я расскажу о том, как оценивается whiteboard со стороны интервьюера и как правильно его проходить. Погнали!

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

В процессе проведения WB интервьюер ищет следующие признаки, показывающие, что вы понимаете основную базу в дизайне и опираетесь на принципы «дизайн-мышления»:

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

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

Совет: на этапе, когда вы только узнали о том, что предстоит пройти WB, стоит поинтересоваться, что это такое и в чем его суть, а также поискать примеры задач.

За все проведенные челленджи дизайн-лиды из Cloud. ru не встретили ни одного одинакового паттерна у тех, кто успешно прошел WB. Это говорит о том, что каждый дизайнер и его подход к работе уникален. Однако есть одна черта, которая объединила всех тех, кто завалил тестирование — предложение решений до погружения в контекст.

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

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

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

Работа с контекстом и пользователями
На этом этапе можно сделать какие-то обоснованные предположения и попытаться ответить на вопрос «Кто является конечным пользователем?».

Хорошим артефактом после этого блока может стать Userflow / CJM в супер-сжатом формате, чтобы в дальнейшем можно было предлагать идеи и гипотезы с оглядкой на существующее решение (или его отсутствие).

Генерация и скоринг идей
Теперь нужно подумать о решениях, которые вы могли бы спроектировать (или вообще о решениях, которые могут закрыть проблему). Именно на этом этапе вы показываете, как полученные данные синтезируются во что-то, что может работать. Вы не берете идеи с потолка, а основываетесь на потребностях и контексте пользователя, которые узнали раньше. Можно сгенерировать N решений, но хотя бы одно из них должно соответствовать критериям для дальнейшей проработки:

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

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

Альтернативы и улучшения
Если у вас осталось время — можно посвятить время генерации альтернатив и улучшений. Задавайте вопросы сами себе:

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

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

Обратная связь — супер-ценный ресурс, который человек может вынести со встречи. Если у вас не получилось пройти WB — именно фидбек поможет вам понять, что было не так, и где нужно подрастить скиллы.

UPD от 11 марта 2024: я сделал сервис с примерами задач для WB. Там также можно забронировать время на консультацию со мной

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

Рефлексия над серией проведенных WB показала:

Но файл-шаблон все так же остается публичным (на память).

UPD от 11 марта 2024: я собрал базу в notion c большим количеством материалов для подготовки к WB

В своем телеграм-канале пишу всякое про дизайн, продукты, мышление и процессы на основе своего опыта.

#дизайн #whiteboard #карьера #продуктовыйдизайн #интервью #собеседование #найм #туториал #руководство