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

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

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

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

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

Пытаетесь ли вы узнать цели пользователя/бизнеса
Фокусируетесь ли вы на пользователе и на контексте, в котором он сталкивается с проблемой
Делаете ли вы обоснованные гипотезы
Задаете ли «правильные» вопросы
Выходите ли вы за рамки интерфейса и думаете о сценарии целиком

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

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

Заторможенность
На WB от дизайнера ждут динамики, генерации и быстрых решений. Если у вас не получается соответствовать ожиданиям — нужно больше тренироваться.
Молчание
Наверное, самое худшее, что можно делать на WB — это молчать. Одной из целей WB является проверка того, как вы думаете и приходите к каким-то заключениям. И если вы будете думать у себя в голове — вы донесете не очень много ценности тому, кто проводит челлендж. Короче, Think aloud.
Бесконечный диалог
Это обратная сторона молчания, когда дизайнер забывает про конечную цель и демонстрирует исключительно свои софты. Софты это хорошо, но на них далеко не уедешь. Так что не забывайте записывать ответы на вопросы и успевать реализовывать идеи в виде набросков или заметок.
Уход в защиту
Вопросы по ходу вашей работы не стоит воспринимать как придирки. Они задаются для понимания того, как вы мыслите и какую логическую цепочку хотите выстроить. Не всегда нужно уходить в защиту до презентации решения (да и там не всегда нужно). А еще вопросы иногда могут быть наводящими: если процесс идет тяжеловато, то интервьюер немного помогает.

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

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

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

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

Есть ли метрики успеха? Какие?
Какая цель у бизнеса?
Существуют ли какие-то ограничения?
Будем ли мы решать задачу целиком, или есть набор проблем для выбора?

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

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

Какими могут быть пользователи?
Какие пользовательские особенности стоит учесть?
Есть ли важные вещи в их поведении и проблемах?
В каком контексте пользователь сталкивается с проблемой?
Есть ли важные детали в контексте?

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

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

Решение можно реализовать
Проблема решается в полной мере или в бОльшей степени
Новое решение лучше существующего

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

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

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

Что еще нужно учесть?
А если контекст немного изменить?
Можно ли упростить решение?
Нет ли логических ошибок?

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

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

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

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

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

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

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

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

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

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

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