Как собрать кейс в портфолио, если нет коммерческого опыта

Какой проект вообще считается кейсом

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

Под это условие подходят четыре типа проектов:

• Редизайн существующего продукта. Не абстрактный «редизайн Aeroflot», а разбор конкретного сервиса с живыми данными: отзывами в сторе, обращениями в поддержку, реальными экранами, которые можно раскритиковать по делу.

• Волонтёрский проект. Сайт для соседского фонда, интерфейс для локального НКО, оформление мероприятия знакомых. Здесь есть настоящий заказчик с настоящими ограничениями — бюджетом, дедлайном, чужим мнением, которое нужно учитывать.

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

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

Общий признак всех четырёх — есть кто-то или что-то за пределами твоей головы, с чем можно свериться. Учебная задача, которую ты выдумал и сам же исполнил «на пятёрку», этому условию не отвечает: там нет второй точки зрения, которая могла бы сказать «нет, это не решает проблему».

Как найти реальную проблему, а не выдумать бриф

Самая частая ошибка — начинать с решения, а не с проблемы: «сделаю мобильное приложение для доставки цветов» вместо «пойму, почему конкретный локальный флорист теряет заказы на сайте». Бриф, придуманный из головы, выдаёт себя избыточной аккуратностью: у него нет противоречивых требований, нет ограничений, нет человека, которому что-то по-настоящему не нравится.

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

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

2. Посмотри отзывы и обращения в поддержку реального продукта — это готовый список настоящих проблем пользователей, а не твоих предположений о них.

3. Возьми открытую задачу от НКО или волонтёрской организации. Такие запросы есть в профильных сообществах и группах — это реальные ограничения по бюджету и времени, а не выдуманные тобой.

Во всех трёх случаях проблема формулируется не тобой, а тем, кто с ней живёт. Твоя задача на входе — записать её словами заказчика, а не сразу переводить в «удобный» бриф для дизайна.

Как оформить процесс, чтобы в него поверили

Работодатель отличает учебную поделку от серьёзного кейса не по красоте финального макета, а по видимости процесса. Три вещи, которые это показывают:

• Контекст и ограничения названы честно. «Бюджета не было, работал бесплатно, срок — три недели, заказчик хотел сохранить старый логотип» — такие детали не портят кейс, а объясняют, почему решение выглядит именно так.

• Показаны промежуточные шаги, а не только «было — стало». Черновые варианты, причина, по которой один из них отклонили, короткая цитата реакции заказчика или пользователя на прототип.

• Названы конкретные инструменты и методы, которыми пользовался: интервью с владельцем бизнеса, тест прототипа в Maze, сбор фидбэка через Figma-комментарии. Общие слова вроде «провёл исследование» ничего не доказывают — конкретика доказывает.

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

Вывод

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