Как оформить кейс в портфолио

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

Выберите проект под будущую задачу заказчика

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

Запишите, кому был нужен результат и какое действие человек должен был выполнять. Если настоящий заказчик не участвовал, заменять его вымышленным предпринимателем нельзя. В учебной работе допустима постановка: «Я выбрала задачу мастерской и собрала демонстрационный сайт». Это показывает инициативу и оставляет читателю возможность правильно оценить доказательства.

Не пытайтесь одним кейсом доказать всё сразу. Страница о форме обращения не обязана доказывать способность построить складскую систему. Обозначьте границы: сайт, отдельный интерфейс, прототип или работающий сервис. Даже в большом проекте можно выбрать один законченный участок, если объяснить его связь с остальной системой.

В руководстве NN/g по дизайнерскому портфолио предлагается показывать задачу, собственную роль, ход решения и результат, а не только финальные экраны. Материал опубликован в 2019 году и посвящён UX-портфолио; здесь этот подход служит редакторским ориентиром, а не обещанием получить заказы.

Соберите основания для каждого утверждения

До написания текста откройте материалы проекта: исходную задачу, согласованные изменения, рабочую версию и результаты проверок. Сделайте короткий реестр. В первой колонке — что Вы хотите сказать, во второй — чем это подтверждается, в третьей — что можно показать посетителю. Так сразу обнаружится разница между выполненной работой и красивым предположением.

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

Отделяйте внутреннее основание от публичного доказательства. Рабочая переписка помогает восстановить задачу, но публиковать её целиком обычно не нужно. Для описания достаточно разрешённого фрагмента, собственного объяснения или обезличенного образца. Если допустимость раскрытия не выяснена, не выкладывайте материал и не рассчитывайте, что замена имени автоматически решает все ограничения.

Назовите свою роль и статус работы

Читателю нужно понимать, какие решения принимали Вы. Вместо «мы создали платформу» напишите, что сделали лично: собрали страницы, описали сценарий, настроили форму или проверили формулы. Если работа командная, обозначьте вклад других участников по согласованному описанию. Не присваивайте себе дизайн, разработку или исследование только потому, что участвовали в обсуждении.

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

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

Укажите существенные ограничения Вашего участия. Если текст и фотографии передал заказчик, это не уменьшает ценность сборки сайта. Если Вы использовали готовую библиотеку интерфейса, можно объяснить, какие части адаптировали. Честная роль помогает будущему клиенту понять, какую работу он сможет поручить именно Вам.

Покажите связь между задачей и решением

Самая полезная часть кейса отвечает на вопрос «почему сделано так». Выберите несколько решений, действительно повлиявших на сценарий. Например, отдельная страница услуги понадобилась, чтобы человек видел её состав до обращения. Короткая форма оставляет вопросы, без которых нельзя начать ответ. Подтверждение после отправки объясняет, что произошло дальше.

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

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

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

Собрать исходную постановку помогает разбор технического задания на корпоративный сайт. Кейс решает другую задачу: объясняет уже выполненную работу. Не превращайте его в копию будущего задания или в перечень всех возможных функций сайта.

Разделите выполненную работу и эффект для бизнеса

Результат разработки и результат бизнеса — разные сведения. Опубликованный сайт, работающий расчёт и проверенная доставка тестового обращения относятся к созданному продукту. Выручка, число обращений и время сотрудников относятся к использованию. Первое не позволяет автоматически утверждать второе. Если бизнес-эффект не измерялся, скажите это спокойно.

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

Если измерение есть, укажите предмет и условия. Что считали, за какой период, с каким исходным состоянием сравнивали, менялось ли что-то ещё? Сравнение нескольких тестовых действий нельзя выдавать за экономию рабочего времени всей команды за месяц. Прогноз будущего результата подписывайте прогнозом и показывайте допущения отдельно от наблюдения.

Отзыв клиента также имеет границы. Фраза о понятном интерфейсе подтверждает впечатление автора отзыва, но сама по себе не доказывает рост продаж. Не дописывайте к отзыву удобные цифры и не превращайте собственную оценку в чужую цитату. Если отзыва нет, оставьте раздел без него: описание проверки полезнее выдуманного одобрения.

Подберите изображения с понятными подписями

Для реального кейса выбирайте изображения, показывающие именно выполненную работу: экран, фрагмент пути пользователя или разрешённый рабочий материал. Подпись должна объяснять, на что смотреть. «Форма запроса после проверки обязательных полей» полезнее подписи «современный интерфейс». Не публикуйте служебные адреса, токены и настоящие клиентские заявки.

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

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

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

Проверьте кейс глазами нового посетителя

Дайте описание человеку, который не участвовал в работе, и попросите назвать предмет проекта, Вашу роль и подтверждённый результат. Не объясняйте текст заранее. Если собеседник принимает учебный сайт за внедрение у клиента, поправьте статус в первом экране. Если не может назвать услугу, замените абстрактные слова конкретным действием.

Пройдите все публичные ссылки без своей административной сессии. Проверьте открытие на телефоне, читаемость подписей и способ возвращения к портфолио. Для демо объясните, какие действия безопасно пробовать. Не приглашайте отправлять настоящие персональные сведения в учебную форму и не обещайте ответ оператора, если его нет.

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

Вопросы об оформлении кейса

Можно ли показать незавершённую работу

Да, если обозначить стадию и объяснить, что уже сделано. Не называйте прототип опубликованным продуктом и не приписывайте ему результаты использования. Покажите законченный участок, который можно оценить.

Что написать вместо имени закрытого заказчика

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

Нужно ли указывать стоимость проекта

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

Как описать проект, который больше не работает

Укажите его актуальный статус и дату доступной версии. При наличии допустимых материалов покажите архивные экраны с подписью. Не оставляйте кнопку «попробовать», ведущую на неработающий сервис.

Можно ли объединить несколько заказов в один кейс

Можно написать обзор подхода, ясно отделив проекты. Не собирайте из разных клиентов историю одного внедрения и не приписывайте совокупные показатели одному результату.

Что делать, если нашли ошибку в старом описании

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