Разбор более 200 портфолио показал: сильные кейсы дизайнеров отличаются не количеством экранов, а умением объяснить, почему решение вообще появилось. По данным Habr / Карьера, автор изучил работы продуктовых и UX/UI-дизайнеров из Т-Банка, Яндекса, Альфы, РСХБ и Сбера и выделил повторяющиеся ошибки, которые мешают кандидатам показать реальный уровень.
Типовой дизайн-кейс почти всегда собирается по знакомому маршруту: описание проекта, контекст, задача, роль дизайнера, процесс, решение, результат и выводы. На бумаге схема выглядит здраво. Проблема в том, что многие кандидаты превращают ее в отчет о проделанной работе: провел интервью, собрал CJM, сделал прототип, протестировал, нарисовал интерфейс. Для найма этого мало. Арт-директору или дизайн-лиду нужно понять не только маршрут, но и качество навигации: какие варианты рассматривались, почему один сценарий выбрали, от каких идей отказались и чем это закончилось для продукта.
Главный вывод исследования неприятен, но полезен: кейсы дизайнеров часто показывают процесс, но прячут смысл. В них есть задача вроде «переработать интерфейс оператора», однако не объяснено, что именно сломано. Интерфейс устарел? Оператор тратит лишние минуты? Клиенты дольше ждут ответа? Растет число ошибок? Без этой связки кейс выглядит как упражнение в оформлении, а не как продуктовая работа.
Отдельная боль — разрыв между UX-проблемой и бизнес-проблемой. Формулировка «пользователю неудобно работать в двух сервисах» описывает симптом. Для бизнеса важнее другое: ручной перенос данных замедляет ответы, увеличивает риск ошибок и съедает рабочее время команды. Когда дизайнер умеет перевести пользовательскую боль в язык затрат, скорости, качества сервиса или конверсии, кейс сразу становится взрослее. Это уже не «мы сделали удобнее», а понятная история про влияние интерфейса на операционные показатели.
Автор также обращает внимание на порядок подачи. Многие дизайнеры ставят результат в финал, потому что так логично устроена хронология проекта: была задача, потом работа, затем итоги. Но человек, который открывает портфолио, еще не обязан читать лонгрид 15 минут. Поэтому сильнее работает короткий ответ в начале: что изменилось, для кого и каким был вклад дизайнера. Это не отменяет подробностей ниже, но дает нанимающему менеджеру причину продолжить.
Лучше всего в исследовании выглядят кейсы, где есть сравнение «до» и «после», ограничения, неудачные гипотезы и честная рефлексия. Для редизайна особенно важно показать старое решение: без него новый интерфейс может быть красивым, но масштаб работы неочевиден. Цифры вроде сокращения времени, роста конверсии или снижения ошибок полезны, но без исходного состояния они висят в воздухе. Работодатель хочет видеть не витрину, а разницу.
Ограничения тоже работают на кандидата, если описаны конкретно. Фраза «было мало времени» ничего не говорит. Формулировка «на проект было пять дней, поэтому команда отказалась от полноценного исследования, взяла существующие данные и сфокусировалась на критичном сценарии» показывает уже другой уровень мышления. В реальных продуктах редко бывает идеальная лаборатория с бесконечным бюджетом. Способность выбирать компромисс и понимать его цену для бизнеса — важнее идеальной картинки в Figma.
Интересная деталь: живее смотрятся кейсы, где дизайнер не изображает безошибочного героя. Если гипотеза не подтвердилась, первый вариант оказался слабым или тестирование заставило пересобрать сценарий, это не портит работу. Наоборот, такие эпизоды показывают, как человек думает под давлением фактов. Для команды это ценнее, чем идеально отполированный рассказ, где каждое действие с первой попытки ведет к правильному экрану.
Для русскоязычного IT-рынка этот разбор важен шире, чем только для дизайнеров. Продакты, тимлиды и HR в IT получают понятный чек-лист для оценки портфолио: искать не набор артефактов, а причинно-следственную цепочку. Проблема, данные, решение, аргументация, запуск, результат, выводы. Если этих звеньев нет, даже аккуратный визуал не доказывает, что кандидат умеет влиять на продукт.
Похоже, портфолио в дизайне окончательно перестает быть галереей экранов. Следующий стандарт — кейс как короткое расследование: что болело, почему это было важно, какие решения проверили, где ошиблись и что изменилось после запуска. Кто научится рассказывать так, будет выглядеть сильнее не из-за громкого бренда в шапке, а из-за прозрачной логики работы.