Карточка в портфолио может заинтересовать одной картинкой. Но страница кейса должна ответить на более сложный вопрос: что именно в этой работе было задачей дизайнера? Без ответа любой проект рискует остаться набором эффектных изображений.

Когда мы собирали шаблон кейса для TRUE VISUAL, главным требованием стала понятная последовательность. Не нужно заставлять посетителя читать длинную вводную, чтобы добраться до результата. Но и оставлять картинки без контекста тоже нельзя.

Сначала увидеть, потом разобраться

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

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

Не путать задачу, решение и процесс

Для кейса полезно разделять три вопроса. Задача: что требовалось изменить или создать? Решение: почему выбран именно такой визуальный подход? Процесс: какие рабочие варианты и ограничения на него повлияли?

Например, при проектировании сайта можно показать не только готовую страницу, но и изменение структуры навигации. В упаковке - связь между плоской разверткой и тем, как продукт выглядит на полке. Такие детали объясняют работу лучше, чем универсальная фраза "создали современный дизайн".

Не каждому проекту нужен раздел "Процесс / За кадром". Мы включаем его там, где действительно есть что показать: промежуточные состояния, сравнение вариантов или нестандартное ограничение.

Результат нельзя придумывать

Особенно осторожно мы относимся к финальному блоку. Если нет подтвержденных данных о росте продаж, конверсии или узнаваемости, нельзя подменять их красивым процентом. Можно точно назвать созданные материалы, показать утвержденный макет, описать исправленную проблему интерфейса. Это проверяемые результаты самой работы.

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

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