Разобрал больше 200 кейсов и посмотрел, из чего они состоят, какие фишки помогают показать свой уровень и что можно еще улучшить

В прошлый раз я проанализировал портфели продуктовых и UX/UI‑дизайнеров. Теперь изучаем кейсы. Главная страница портфеля заинтересовывает визуалом, стилем и красивыми превью проектов. Но чтобы понять, как дизайнер на самом деле работает, надо открыть кейс. И уже там смотреть:

• Как он погружается в задачу?

• Понимает ли проблему?

• Как принимает решения?

• Умеет ли работать с исследованиями?

• Как взаимодействует с командой?

• Может ли объяснить, почему решение получилось именно таким?

• И самое главное — что в итоге изменилось?

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

Я заметил повторяющийся паттерн и шаблон сборки кейса: Описание проекта → контекст → проблема или задача → роль дизайнера → процесс → решение → результаты → выводы.

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

• Карточка проекта

• Суть проекта

• Роль и вклад дизайнера

• Команда

• Контекст продукта

• Проблема

• Ограничения

• Цели

• Задачи, scope и требования

• Дизайн исследования

• Анализ продукта, процессов и данных

• Анализ рынка и конкурентов

• Тестирования и эксперименты

• Пользователи

• Артефакты

• Инсайты

• Подход и этапы работы

• Приоритизация и MVP

• Сценарии

• Информационная архитектура

• Прототипы

• Визуальное решение

• Дизайн‑система

• Демонстрация решения

• Запуск и дальнейшие итерации

• Результаты

• Ограничения результатов

Логичный процесс изучения кейса: Сначала была задача → потом работа → потом результат. Но артдир ещё не знает, стоит ли ему тратить на него следующие 15 минут.

Поэтому главный результат полезно показать уже в начале:

• Что изменилось?

• Для кого?

• В чём заключался вклад дизайнера?

Дизайнеры хорошо показывают последовательность действий: провёл интервью → собрал CJM → сделал прототип → протестировал → нарисовал интерфейс.

Но всё ещё непонятно, почему итоговое решение получилось таким. Какие варианты рассматривали? Почему выбрали этот? От чего отказались? и тд.

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

В кейсах есть контекст, описание и задача. Так выглядит задача: Нужно было переработать интерфейс оператора. А в чем проблема‑то? Почему нужно перерабатывать интерфейс?

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

Почувствуй разницу:

• UX‑проблема: сотрудник вынужден работать одновременно в двух сервисах.

• Бизнес‑проблема: ручной перенос данных между сервисами замедляет ответы и увеличивает количество ошибок.

Во втором случае уже понятно не только что болит у пользователя, но и зачем бизнесу вообще тратить ресурсы на эту доработку.

Тоже самое, о чем писал выше) когда понимаешь почему пользователю неудобно и во что это обходиться бизнесу — это логичнее, более ценно и зрело!

В кейсах много серьёзного текста: бизнес‑контекст, исследования, ограничения, процессы и метрики.. Шутки и самоирония помогают выдохнуть и расслабиться)) Заодно через приколы понятен вайб дизайнера.

Результаты в цифрах показывают довольно часто:

• Сократили время,

• Увеличили конверсию,

• Уменьшили количество ошибок

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

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

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

Это делает кейс намного живее и лучше показывают самого дизайнера.

Такие истории для меня выглядят взрослее, чем кейсы, где весь процесс — это последовательность исключительно правильных решений.

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

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

Не просто: «У нас было мало времени».

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

Отдельно мне понравились блоки с рефлексией. Например:

1. Что дизайнер сейчас сделал бы иначе?

2. Какое решение считает спорным?

3. Что хотел бы перепроверить?

4. Что понял во время проекта?

5. Что забрал из этой работы в следующие проекты?

Это хорошо показывают зрелость дизайнера и его способность критически оценивать собственную работу.

Почему‑то именно такие кейсы мне запомнились больше всего. Скорее всего из‑за такой откровенности

Сильный кейс — это не отчёт о количестве интервью, артефактов, прототипов и красивых экранов. Скорее сила в том, чтобы показать: проблема → что дизайнер узнал → какое решение принял → почему выбрал именно его → что изменилось после запуска.

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