Как оформить UX/UI-кейс в портфолио: структура и пример учебного проекта

Хороший UX/UI-кейс помогает понять, какую задачу решал дизайнер, на какие данные опирался и почему выбрал конкретный интерфейс. Красивые экраны важны, но без объяснения решения читателю трудно отличить осознанную работу от аккуратного повторения референса.

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

Чем UX/UI-кейс отличается от галереи экранов

Галерея показывает, как выглядит результат. Кейс объясняет путь к нему: задачу, ограничения, наблюдения, варианты, решения и проверку. По нему должно быть понятно, что сделали лично вы и что ещё осталось неизвестным.

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

Структура не обязана повторять все этапы дизайн-мышления. Если вы не проводили интервью, не добавляйте декоративный раздел с интервью. Если решали задачу визуальной иерархии, подробно покажите именно её. Кейс должен соответствовать реальной работе, а не списку популярных UX-артефактов.

Сначала определите, кому вы показываете проект

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

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

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

Структура UX/UI-кейса: восемь смысловых блоков

Эти блоки можно объединять. В коротком кейсе роль и контекст удобно вынести в первый экран, а проверку — показать рядом с конкретным решением. Главное, чтобы читатель не искал ключевую информацию среди длинных вступлений.

1. Первый экран: объясните проект за несколько предложений

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

Для нашего примера первый экран мог бы выглядеть так: «Запись на занятия в районной студии. Учебный концепт мобильного сайта. Задача — спроектировать путь от выбора занятия до подтверждения записи. Моя работа: сценарий, вайрфреймы, прототип и визуальное оформление. Разработка и запуск не выполнялись».

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

2. Проблема: отделите данные от предположений

Фраза «пользователям неудобно записываться» слишком широкая. Лучше описать конкретный момент: человек сравнивает занятия, но не видит продолжительность и правила отмены до заполнения формы. Затем объяснить, как вы это выяснили.

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

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

Для учебного примера сформулируем гипотезу: «Если заранее показать условия занятия, человек сможет выбрать подходящий вариант до ввода персональных данных». Гипотеза задаёт направление работы, но ещё не является доказанным результатом.

3. Сценарий: покажите, какую часть пути вы решили

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

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

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

4. Решения: выберите три эпизода для подробного объяснения

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

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

Если сравнение вариантов происходило только на уровне вашей оценки, так и напишите. Не называйте два нарисованных экрана A/B-тестированием. Для A/B-теста нужны подходящий эксперимент, распределение пользователей и измерение результата. В портфолио вполне уместно показать обоснованный выбор без такого теста.

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

5. Интерфейс: покажите поведение вместе с визуальным стилем

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

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

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

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

6. Проверка: расскажите, что произошло на самом деле

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

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

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

Если тестов ещё не было, раздел не нужно заполнять вымышленными результатами. Покажите план проверки и назовите неподтверждённые решения. Умение видеть границы собственных выводов помогает обсуждать проект предметно.

Как описать результат без коммерческих метрик

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

Разделяйте результат работы и эффект для продукта. «Собрал прототип записи» — проверяемый результат вашей деятельности. «Повысил конверсию записи» — утверждение об эффекте, для которого нужны данные. Если продукт не запускался, второй вывод делать нельзя.

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

Как выбрать площадку для UX/UI-портфолио

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

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

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

Чек-лист перед публикацией кейса

• Из первых абзацев понятно, что это за продукт, какой тип проекта и что сделали лично вы.
• Проблема описана конкретно; данные отделены от гипотез и личной оценки.
• Есть хотя бы один пример решения с объяснением выбора и ограничений.
• Экраны можно рассмотреть без увеличения крошечных мокапов.
• Показаны важные состояния, а не только идеальный путь.
• Исследования, тесты, сроки и метрики соответствуют реально выполненной работе.
• Ссылки работают, материалы разрешено раскрывать, персональные данные убраны.
• В конце понятно, что удалось сделать и что вы проверили бы следующим шагом.

Если проект ещё не выбран, начните с ограниченной повседневной задачи: запись на занятие, выбор услуги или оформление заявки. Общий путь обучения разобран в материале «Как стать UX/UI-дизайнером с нуля». А для дополнительной проверки структуры портфолио пригодятся рекомендации Nielsen Norman Group: важен не только итоговый UI, но и понятное объяснение работы дизайнера.