Опыт нельзя перечислить — его нужно доказать

Самые любимые кейсы продуктовых дизайнеров — это те, где для Тильда-странички провели глубинки, тесты, собрали CJM, JTBD, карту эмпатии и обвязали метриками в 146%. Не везде так плохо, конечно, но прецеденты есть.

Всё начинает сыпаться на этапе простых вопросов про кейс: а зачем тут CJM? А что изменилось после неё? Как исследование повлияло? Кандидат либо начинает пересказывать учебник, либо просто не может объяснить, зачем для ямки, в которой нужно похоронить жука под стёклышком, вызвали экскаватор и группу геодезистов.

Зачем вообще нужно портфолио

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

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

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

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

Компания тоже должна понимать, кто ей нужен. Странно просить кандидата показать запуск нового продукта с нуля, если после найма он будет годами развивать знакомые сценарии внутри готовой системы. Получается, что на собеседовании мы проверяем человека для одной работы, а потом даём ему другую.

Портфолио здесь просто открывает дверь. Дальше всё равно будут вопросы.

Где собирать кейс

Да где угодно.

Можно сделать свой сайт, можно написать кейс в Notion, собрать презентацию в Figma Slides, а можно красиво оформить на Dprofile.

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

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

Почему текст всё-таки нужен? Экран показывает результат, но не объясняет, почему он выглядит именно так. По картинке я не узнаю, какое было ограничение, что предложил дизайнер, с чем спорила разработка и почему один вариант выбрали вместо другого.

Есть мнение, что длинные кейсы никто не читает. Да, подтверждаю: целиком с первой до последней строчки, скорее всего, не прочитают. Я сам сначала быстро скроллю страничку и ищу задачу, роль человека, главное решение и результат. Если работа зацепила, то возвращаюсь и читаю подробнее.

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

А если не вернётся — у вас хотя бы останется нормальное доказательство собственной работы, а не десять картинок, которые вы каждый раз будете заново объяснять голосом на собеседовании.

А ещё я постоянно вижу командное «мы»: «Мы провели исследование, собрали прототип, протестировали и запустили».

Отлично! А что сделали конкретно вы?

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

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

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

И вроде всего лишь плашка, но под собой она хранила бездну вопросов:

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

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

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

А вот ещё 30 экранов того, какая у вас вышла прекрасная CRM, точно размазали бы эту работу и обезличили её.

Перед тем как собирать кейс, попробуйте закончить одну фразу:

После этого кейса должно быть понятно, что я умею…

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

CJM, JTBD и другие обязательные разделы

Онлайн-школы приучили дизайнеров, что в хорошем кейсе обязательно должны быть исследования, CJM, JTBD, карты эмпатии, персоны и ещё какой-нибудь замудрённый фреймворк.

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

Если вы показываете CJM, то будьте добры рассказать, как вы её собрали и что изменили после. Если CJM собирал продакт, то рассказать всё равно придётся, иначе непонятно, что вы проектировали, не зная того контекста, который продакт замыслил.

Если проводили интервью, то расскажите, кто участвовал, что вы хотели узнать, какие ответы повлияли на продукт.

Если делали тест, то какую гипотезу проверяли и что сделали с результатом.

Для небольшой формы заявки иногда достаточно посмотреть текущее поведение, сформулировать несколько причин низкой конверсии, выбрать дешёвый способ проверить гипотезы и после запуска посмотреть на результат.

Можно ли провести двадцать интервью, собрать CJM, описать персоны и потом сделать юзабилити-тест? Конечно можно! Только расскажите, пожалуйста, зачем ради одной формы понадобилась вся исследовательская лаборатория и были ли у команды на неё время и деньги.

Ну и что там у вас получилось?

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

Ну и что?

Вы рассказали, куда ходила команда, но теперь расскажите, зачем она туда ходила и чем всё закончилось.

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

Можно написать честно и прямо:

Я ушёл до запуска, поэтому итогового эффекта не видел. До этого мы успели проверить вот это.

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

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

Главное — написать, что именно вы увидели, а не придумать хеппи-энд и циферки задним числом.

С концептами всё ещё проще. Если ваш продукт существует только в Фигме, он не мог увеличить продажи или сократить время на 40%. Не выдумывайте. Просто покажите, как вы сформулировали проблему, какие предположения сделали, что учли и как собирались это проверить.

Как я проверяю кейс на собеседовании

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

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

Что вы можете проверить сами

Сам кейс я бы проверил вопросами:

• какая задача была в начале;
• что именно делали вы;
• почему выбрали это решение;
• что изменилось после;
• чего вы не знаете и не можете доказать.

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

Если ничего — уберите её хотя бы на время и посмотрите, развалился ли рассказ. Потом быстро пролистайте весь кейс, как это сделал бы менеджер между двумя встречами с булкой во рту, потому что не успел пообедать, и посмотрите: понятно ли, какая была задача; видна ли ваша роль; можно ли найти главное решение?

Кейс не обязан ответить на все вопросы до собеседования, но после него хотя бы должно быть понятно, о чём вас спрашивать дальше.

Мой первый вопрос обычно простой:

А что здесь сделали вы?