Разобрал больше 200 кейсов и посмотрел, из чего они состоят, какие фишки помогают показать свой уровень и что можно еще улучшить
В прошлый раз я проанализировал портфели продуктовых и UX/UI‑дизайнеров. Теперь изучаем кейсы. Главная страница портфеля заинтересовывает визуалом, стилем и красивыми превью проектов. Но чтобы понять, как дизайнер на самом деле работает, надо открыть кейс. И уже там смотреть:
Как он погружается в задачу?
Понимает ли проблему?
Как принимает решения?
Умеет ли работать с исследованиями?
Как взаимодействует с командой?
Может ли объяснить, почему решение получилось именно таким?
И самое главное — что в итоге изменилось?
Причины провести это исследование те же. Во‑первых, для себя как для дизайнера. Во‑вторых, я менторю дизайнеров и регулярно помогаю им собирать портфолио.
Из чего обычно состоит кейс
Я заметил повторяющийся паттерн и шаблон сборки кейса: Описание проекта → контекст → проблема или задача → роль дизайнера → процесс → решение → результаты → выводы.
А если копнуть глубже, то внутри кейсов встречается гораздо больше отдельных элементов.
Вводная часть
Карточка проекта
Суть проекта
Роль и вклад дизайнера
Команда
Постановка задачи
Контекст продукта
Проблема
Ограничения
Цели
Задачи, scope и требования
Исследование
Дизайн исследования
Анализ продукта, процессов и данных
Анализ рынка и конкурентов
Тестирования и эксперименты
Пользователи
Артефакты
Инсайты
Поиск решения
Подход и этапы работы
Приоритизация и MVP
Проектирование
Сценарии
Информационная архитектура
Прототипы
Визуальное решение
Дизайн‑система
Реализация
Демонстрация решения
Запуск и дальнейшие итерации
Завершение кейса
Результаты
Ограничения результатов
Точки роста
Результаты в самом конце
Логичный процесс изучения кейса: Сначала была задача → потом работа → потом результат. Но артдир ещё не знает, стоит ли ему тратить на него следующие 15 минут.
Поэтому главный результат полезно показать уже в начале:
Что изменилось?
Для кого?
В чём заключался вклад дизайнера?
«Я прошёл все этапы» встречается чаще, чем настоящая аргументация
Дизайнеры хорошо показывают последовательность действий: провёл интервью → собрал CJM → сделал прототип → протестировал → нарисовал интерфейс.
Но всё ещё непонятно, почему итоговое решение получилось таким. Какие варианты рассматривали? Почему выбрали этот? От чего отказались? и тд.
Умение провести интервью или собрать CJM важно. Но важнее, как дизайнер использует эту информацию и принимает решения.
Есть задача, но нет проблемы
В кейсах есть контекст, описание и задача. Так выглядит задача: Нужно было переработать интерфейс оператора. А в чем проблема‑то? Почему нужно перерабатывать интерфейс?
Есть UX‑проблема, но нет бизнес‑проблемы
Просто сказать, что пользователю неудобно, — мало. Хочется понимать, во что эта проблема обходится бизнесу.
Почувствуй разницу:
UX‑проблема: сотрудник вынужден работать одновременно в двух сервисах.
Бизнес‑проблема: ручной перенос данных между сервисами замедляет ответы и увеличивает количество ошибок.
Во втором случае уже понятно не только что болит у пользователя, но и зачем бизнесу вообще тратить ресурсы на эту доработку.
Что суперклёво
Разделение на UX‑проблемы и бизнес‑проблемы
Тоже самое, о чем писал выше) когда понимаешь почему пользователю неудобно и во что это обходиться бизнесу — это логичнее, более ценно и зрело!
Юмор и прикольчики
В кейсах много серьёзного текста: бизнес‑контекст, исследования, ограничения, процессы и метрики.. Шутки и самоирония помогают выдохнуть и расслабиться)) Заодно через приколы понятен вайб дизайнера.
Сравнение «до» и «после»
Результаты в цифрах показывают довольно часто:
Сократили время,
Увеличили конверсию,
Уменьшили количество ошибок
Но если проект связан с редизайном, хочется увидеть не только цифры, но и старое решение. Без него сложно оценить масштаб работы. Я вижу красивый новый интерфейс, но не понимаю, что именно дизайнер в нём изменил.
Возможность быстро прочитать кейс
Каждый кейс — лонгрид. Нужно показать контекст, проблему, исследования, процесс, решение и результаты. Но далеко не каждый человек готов сразу потратить на один проект 15–20 минут. Когда я увидел возможность изучить кейс через короткую версию, я почуствовал заботу и этот кейс сразу выделился среди остальных.
Неудачи
Когда всё идёт по плану — сложно понять, насколько человек умеет принимать решения. Интереснее посмотреть, что он делает, когда гипотеза не подтвердилась, первое решение оказалось слабым и тд.
Это делает кейс намного живее и лучше показывают самого дизайнера.
Такие истории для меня выглядят взрослее, чем кейсы, где весь процесс — это последовательность исключительно правильных решений.
Трудности и ограничения
В реальной работе никогда не бывает ситуации: вот тебе проблема, бесконечное время, любые ресурсы и делай идеальное решение.
Ограничения добавляет кейсу реализма. И показываем как дизайнер умеет принимать решения в ненормальных условиях и понимать, каким компромиссом за него пришлось заплатить.
Не просто: «У нас было мало времени».
А: «У нас было пять дней, поэтому мы отказались от полноценного исследования, использовали уже существующие данные и сфокусировались только на самом критичном сценарии».
Мысли после проекта
Отдельно мне понравились блоки с рефлексией. Например:
Что дизайнер сейчас сделал бы иначе?
Какое решение считает спорным?
Что хотел бы перепроверить?
Что понял во время проекта?
Что забрал из этой работы в следующие проекты?
Это хорошо показывают зрелость дизайнера и его способность критически оценивать собственную работу.
Почему‑то именно такие кейсы мне запомнились больше всего. Скорее всего из‑за такой откровенности
Вывод
Сильный кейс — это не отчёт о количестве интервью, артефактов, прототипов и красивых экранов. Скорее сила в том, чтобы показать: проблема → что дизайнер узнал → какое решение принял → почему выбрал именно его → что изменилось после запуска.
И еще добавлю — я увидел во время этого исследования, что мощные дизайнеры показывают не только то, что они сделали, а еще как и почему
