На собесе почти всегда просят рассказать, как вы работаете. Интервьюер слушает не названия моделей, а то, как вы думаете: начинаете ли с проблемы, проверяете ли решения и смотрите ли на результат после запуска.
Двойной алмаз
Модель британского Design Council делит работу на два «алмаза»: сначала разбираемся в проблеме, потом ищем решение. В каждом алмазе есть фаза расширения (diverge) и сужения (converge).
- Discover. Собираем факты: аналитика, интервью, обращения в поддержку, конкуренты, ограничения.
- Define. Сужаем до ясной формулировки проблемы и критерия успеха.
- Develop. Генерируем варианты решения, прототипируем, проверяем.
- Deliver. Доводим выбранное до запуска и смотрим на результат.
Главная мысль: первый алмаз заканчивается не макетом, а формулировкой проблемы. Частая ошибка джуна в том, что он сразу прыгает во второй алмаз и рисует экраны по просьбе заказчика.
Дизайн-мышление
Стэнфордская d.school описывает похожий цикл из пяти шагов: Empathize, Define, Ideate, Prototype, Test. Названия разные, суть одна: понять людей, сформулировать проблему, придумать много вариантов, проверить дешёвыми прототипами, повторить.
Формулировка проблемы и HMW
Хорошая формулировка проблемы отвечает: кто пользователь, что он пытается сделать, что мешает и почему это важно.
Новые клиенты бросают заказ на шаге доставки, потому что не видят итоговую стоимость. Это 30% потерь воронки.
Из неё делают вопросы «Как мы могли бы...» (How Might We): «Как мы могли бы показать человеку итоговую сумму ещё до выбора доставки?» В вопросе нет готового решения, но есть направление.
Гипотезы и Lean UX
В продуктовой команде решения оформляют как проверяемые гипотезы:
Мы верим, что показ стоимости доставки в корзине для новых клиентов снизит отказы на шаге доставки. Мы поймём это, когда конверсия шага вырастет на 5%.
В гипотезе есть изменение, аудитория, ожидаемый результат и сигнал. «Нужна кнопка экспорта» это не гипотеза, а пожелание.
Discovery и Delivery
Discovery отвечает на вопрос «что делать и стоит ли», delivery на вопрос «как сделать хорошо». В зрелых командах они идут параллельно: пока разработка делает текущую задачу, дизайнер с продактом исследуют следующую.
Роль дизайнера
Продуктовый дизайнер отвечает за то, как пользователь решит задачу: участвует в постановке, исследует, выбирает решение, проверяет и смотрит на метрики. Продакт отвечает за то, что и зачем делать, разработчик за то, как это реализовать. Границы размыты, но на собесе важно показать, что вы приносите аргументы о пользователях, а не просто исполняете.
Когда сроки режут, лучше урезать ширину, а не глубину: один ключевой сценарий целиком, со всеми ошибками и состояниями, полезнее пяти недоделанных.
Частые ошибки
- Начинать с макета, не поняв проблему и цель.
- Описывать процесс как идеальный учебник: «всегда делаю 20 интервью». Реальный процесс гибкий, и это нормально.
- Не говорить о результате: что изменилось после запуска.
- Путать дизайн-мышление и двойной алмаз с обязательной бюрократией.
Что спросят на собесе
- Расскажите о своём процессе на примере последней задачи.
- Что делаете, если нет времени на исследование?
- Как вы понимаете, что задача решена?
- Как поступите, если руководитель настаивает на решении, которое вредит пользователям?
- Чем продуктовый дизайнер отличается от исполнителя?