Как дизайнеру успешно пройти Whiteboard
Может быть совпадение, но после моей первой статьи про WB в некоторых российских компаниях стали появляться первые версии этого челленджа (и у меня даже появился опыт его прохождения), чему я безусловно рад.
Сегодня я расскажу о том, как оценивается whiteboard со стороны интервьюера и как правильно его проходить. Погнали!
На что смотрят люди, которые проводят whiteboard
Задача дизайнера на WB заключается вовсе не в том, чтобы предложить много wow-идей для решения задачи и не в том, чтобы глубоко проработать прототип. В первую очередь оценивается то, как вы подступаетесь к проблеме и работаете в команде.
То, как вы работаете во время челленджa, определяет то, как вы будете работать с командой, и именно это оценивает интервьюер.
В процессе проведения WB интервьюер ищет следующие признаки, показывающие, что вы понимаете основную базу в дизайне и опираетесь на принципы «дизайн-мышления»:
- Пытаетесь ли вы узнать цели пользователя/бизнеса
- Фокусируетесь ли вы на пользователе и на контексте, в котором он сталкивается с проблемой
- Делаете ли вы обоснованные гипотезы
- Задаете ли «правильные» вопросы
- Выходите ли вы за рамки интерфейса и думаете о сценарии целиком
Можно пойти чуть дальше и показать, что вы понимаете процесс разработки продукта, например, учесть технические ограничения в своем решении и предложить возможные исследования или верхнеуровневый roadmap по реализации своей идеи.
Ошибки, которые часто встречаются
Все ошибаются, и это нормально. Но мы ведь с вами преследуем цель минимизировать количество ошибок при прохождении WB, не так ли? Для этого нужно знать, чего избегать, и развивать те места, в которых вы чувствуете наличие проблемы.
- Заторможенность
На WB от дизайнера ждут динамики, генерации и быстрых решений. Если у вас не получается соответствовать ожиданиям — нужно больше тренироваться. - Молчание
Наверное, самое худшее, что можно делать на WB — это молчать. Одной из целей WB является проверка того, как вы думаете и приходите к каким-то заключениям. И если вы будете думать у себя в голове — вы донесете не очень много ценности тому, кто проводит челлендж. Короче, Think aloud. - Бесконечный диалог
Это обратная сторона молчания, когда дизайнер забывает про конечную цель и демонстрирует исключительно свои софты. Софты это хорошо, но на них далеко не уедешь. Так что не забывайте записывать ответы на вопросы и успевать реализовывать идеи в виде набросков или заметок. - Уход в защиту
Вопросы по ходу вашей работы не стоит воспринимать как придирки. Они задаются для понимания того, как вы мыслите и какую логическую цепочку хотите выстроить. Не всегда нужно уходить в защиту до презентации решения (да и там не всегда нужно). А еще вопросы иногда могут быть наводящими: если процесс идет тяжеловато, то интервьюер немного помогает.
Совет: на этапе, когда вы только узнали о том, что предстоит пройти WB, стоит поинтересоваться, что это такое и в чем его суть, а также поискать примеры задач.
Рекомендации для прохождения WB
За все проведенные челленджи дизайн-лиды из Cloud. ru не встретили ни одного одинакового паттерна у тех, кто успешно прошел WB. Это говорит о том, что каждый дизайнер и его подход к работе уникален. Однако есть одна черта, которая объединила всех тех, кто завалил тестирование — предложение решений до погружения в контекст.
Прежде всего, стоит отнестись к WB как к реальной рабочей задаче и идти по понятному и привычному вам фреймворку. У меня нет универсальной формулы, поэтому я буду говорить о тех шагах, которые предпринимаю сам (и они работают).
Уточнение задачи, проблемы и цели
Еще до предложения решения или проектирования нужно понять, в чем именно состоит задача, и куда мы хотим прийти в итоге. Для этого нужно задать себе «рамки»:
- Есть ли метрики успеха? Какие?
- Какая цель у бизнеса?
- Существуют ли какие-то ограничения?
- Будем ли мы решать задачу целиком, или есть набор проблем для выбора?
Можно еще уточнить про цели пользователя и плавно перейти к следующему шагу.
Работа с контекстом и пользователями
На этом этапе можно сделать какие-то обоснованные предположения и попытаться ответить на вопрос «Кто является конечным пользователем?».
- Какими могут быть пользователи?
- Какие пользовательские особенности стоит учесть?
- Есть ли важные вещи в их поведении и проблемах?
- В каком контексте пользователь сталкивается с проблемой?
- Есть ли важные детали в контексте?
Хорошим артефактом после этого блока может стать Userflow / CJM в супер-сжатом формате, чтобы в дальнейшем можно было предлагать идеи и гипотезы с оглядкой на существующее решение (или его отсутствие).
Генерация и скоринг идей
Теперь нужно подумать о решениях, которые вы могли бы спроектировать (или вообще о решениях, которые могут закрыть проблему). Именно на этом этапе вы показываете, как полученные данные синтезируются во что-то, что может работать. Вы не берете идеи с потолка, а основываетесь на потребностях и контексте пользователя, которые узнали раньше. Можно сгенерировать N решений, но хотя бы одно из них должно соответствовать критериям для дальнейшей проработки:
- Решение можно реализовать
- Проблема решается в полной мере или в бОльшей степени
- Новое решение лучше существующего
В результате, для проработки можно выбрать идею, которая лучше всего балансирует между простотой реализации и эффективностью.
Реализация
Если идея подразумевает интерфейсное решение — набросайте ключевые экраны, а затем инвестируйте время в их проработку и описание. Если же решение лежит за рамками интерфейса, то можно объяснить логику реализации любым удобным способом (я предпочитаю схемы).
Альтернативы и улучшения
Если у вас осталось время — можно посвятить время генерации альтернатив и улучшений. Задавайте вопросы сами себе:
- Что еще нужно учесть?
- А если контекст немного изменить?
- Можно ли упростить решение?
- Нет ли логических ошибок?
Такой подход указывает на ваш навык работы с итерациями и с постоянным улучшением продукта.
Запрос обратной связи
Вне зависимости от успешности прохождения WB обязательно запросите обратную связь. Интервьюеру это показывает ваше неравнодушие к тому, что вы делаете.
Обратная связь — супер-ценный ресурс, который человек может вынести со встречи. Если у вас не получилось пройти WB — именно фидбек поможет вам понять, что было не так, и где нужно подрастить скиллы.
Саммари по тому, как проходить Whiteboard
- Расслабьтесь, будьте открыты и дружелюбны
- Тренируйтесь: здесь тяжело сделать хорошо с первого раза
- Используйте привычный для себя фреймворк
- Выстраивайте диалог с интервьюером
- Проявляйте гибкость: мыслите за рамками задачи, предлагайте нестандартные решения
- Следите за временем и грамотно им управляйте
UPD от 11 марта 2024: я сделал сервис с примерами задач для WB. Там также можно забронировать время на консультацию со мной
P. S.
Когда мы ввели Whiteboard в Cloud.ru, мы намеренно сделали его проще: я подготовил публичный файл-шаблон и описал в нём фреймворк. Спустя время, мы решили немного изменить подход, приведя его к стандарту — теперь не будет описанного фреймворка, а в файле будет лежать только задача.
Рефлексия над серией проведенных WB показала:
- Если дизайнер не идет по нашему фреймворку — обычно получается живее, скиллы раскрываются лучше
- Если дизайнер идет по нашему фреймворку — задача сильно упрощается, и наша конечная оценка не всегда объективна в некоторых параметрах
Но файл-шаблон все так же остается публичным (на память).
UPD от 11 марта 2024: я собрал базу в notion c большим количеством материалов для подготовки к WB
В своем телеграм-канале пишу всякое про дизайн, продукты, мышление и процессы на основе своего опыта.
Спасибо, очень познавательно. В файле фигмы, в тэмпле ошибка в слове multilanguage)
спасибо!
поправлю)
Интересно, спасибо за материал