Короткий ответ
Сильное портфолио без клиентов лучше строить вокруг реальных ограничений и честно маркировать статус проекта: учебный, волонтёрский или неофициальный редизайн-концепт.
Почему одних учебных проектов может быть недостаточно
Nielsen Norman Group предупреждает: убедительное портфолио труднее собрать, если всё, что кандидат может показать, — студенческие работы, потому что у таких работ часто бывают выдуманные ограничения, пользователи и персоны, из-за чего они слабее демонстрируют работу с реальными условиями. NN/g рекомендует получить хотя бы один реальный проект через стажировку, а для уже завершённых учебных работ — честно обозначить нереалистичные элементы в описании кейса, чтобы читатель понимал границы доказательности.
Interaction Design Foundation описывает похожую практику иначе: «гипотетический проект» может строиться на анализе существующего продукта, а может быть полностью выдуманным — оба варианта ресурс называет хорошей стратегией именно для новичков. С предупреждением NN/g это совпадает не во всём: IxDF отдельно уточняет, что реальные проекты — волонтёрские, студенческие, общественные, хакатонские — часто ценнее гипотетических, но не запрещает выдумывать сам продукт. Расхождение здесь не в фактах, а в акценте: NN/g в первую очередь советует искать реальный проект и только при его отсутствии — реалистичные ограничения с честной оговоркой об условности; IxDF допускает и полностью придуманный продукт, хотя реальные проекты считает часто более ценными. Из этого редакция выводит рабочий принцип для трёх заданий ниже: не «придумайте бренд с нуля», а «возьмите реальный продукт и реальное, проверяемое ограничение» — это решение редакции, которое опирается на предупреждение NN/g и на то, что сама IxDF ставит реальные проекты выше гипотетических, а не общая позиция, которую формулируют оба источника.
Три задания вместо одного придуманного бренда
Каждое из трёх заданий строится вокруг реального, проверяемого ограничения — существующего сервиса, реального волонтёрского запроса или продукта другой компании, — а не вокруг вымышленного бренда с вымышленными метриками. Ограничение в каждом задании своего типа: техническая платформа и уже существующая навигация в первом, бюджет времени и отсутствие оплаты во втором, чужая уже сложившаяся визуальная система в третьем. Критерий оценки тоже меняется от задания к заданию и не сводится к тому, понравилась картинка или нет.
Общее правило для всех трёх: результат — это не отзыв клиента и не показатель продаж, которых не существует, а проверяемый артефакт (макет, прототип, редизайн-концепт) и открыто указанный статус проекта. Три формулировки для трёх заданий: «учебный проект, не заказ клиента», «волонтёрский проект для (тип организации), без оплаты» и «редизайн-концепт: неофициальная работа над продуктом другой компании, не заказ и не одобрение владельца». Источники не сравнивают вес таких формулировок с весом выполненного заказа на собеседовании: NN/g называет учебный проект малоубедительным доказательством способности работать в реальных условиях, а IxDF реальные, в том числе волонтёрские, проекты ставит выше гипотетических (см. выше) — то есть сам по себе учебный статус весит меньше выполненного заказа. Практический принцип здесь уже редакционный: чтобы не создавать ложного впечатления о клиентской работе, статус лучше назвать в кейсе до описания результата, а не оставлять его неясным до собеседования.
Первое задание: аудит существующего сервиса и одно обоснованное решение
Возьмите сервис или интерфейс, которым вы пользуетесь сами, — не абстрактный «стартап», а конкретное приложение, сайт или форму с реальными экранами, которые можно открыть и заскриншотить. Сформулируйте один узкий вопрос: какой шаг в этом интерфейсе создаёт больше всего трения и почему. Ограничение здесь техническое и реальное: вы работаете внутри уже существующей навигации, шрифтовой системы и размеров экрана, а не в вакууме, — и это нужно объяснить, прежде чем предлагать изменения. Nielsen Norman Group советует перед началом любого редизайна зафиксировать исходное состояние — скриншотами или другими данными, — чтобы потом было с чем сравнить итоговое решение.
Interaction Design Foundation называет такой формат — анализ существующего продукта с предложенным улучшением — рекомендуемой стратегией именно для начинающих. Структуру кейса стоит выстраивать по схеме «контекст и роль автора → процесс → результат с рефлексией», которую описывает отдельная методическая статья того же ресурса: сначала — какой вопрос вы задали и почему, затем — какие варианты рассматривали и почему отклонили, в конце — что сделали бы иначе, если бы вернулись к задаче сейчас.
Результат: прототип одного шага и минимум один отклонённый вариант
Проверяемый результат этого задания — не полный редизайн сервиса, а макет или прототип одного конкретного шага, скриншот или запись исходного состояния этого шага «до» и короткое описание минимум одного варианта решения, который вы рассмотрели и отклонили, с причиной отказа. Срок в одну-две недели — не норма источников, а ориентир редакции: его достаточно, чтобы пройти путь «вопрос → варианты → решение», не растягивая учебную задачу на месяцы.
Критерий проверки: можно ли пересказать проблему без макета
Критерий самооценки простой: сможет ли читатель кейса пересказать, какую именно проблему вы решали, не глядя на макет. Статус проекта в этом случае — «учебный проект, не заказ клиента»; его стоит указывать прямо в описании кейса, а не мелким шрифтом внизу страницы — в том же духе, в каком NN/g советует открыто оговаривать нереалистичные элементы учебных проектов.
Второе задание: волонтёрский проект с реальным, но неоплачиваемым запросом
Второй тип реального ограничения — не гипотеза, а живой запрос от организации, которой нужна дизайн-работа, но нет бюджета на неё. Interaction Design Foundation прямо называет источником таких, не придуманных, ограничений благотворительные и некоммерческие организации, студенческие и общественные проекты, хакатоны — и отдельно предупреждает: обмен труда на «опыт» нередко превращается в эксплуатацию молодых дизайнеров, поэтому стоит выбирать именно такие, этичные варианты из этого списка, а не любой бесплатный заказ от кого угодно.
Отличие этого задания от первого — в объёме обратной связи: у волонтёрского запроса есть представитель организации, который может подтвердить или отклонить решение, даже если оплаты нет. Ограничение стоит формулировать заранее и письменно, в виде брифа: что нужно сделать, к какому сроку, в каком формате нужен результат. Это тот же навык, что и работа над брифом на платный заказ, — разница в том, что бриф в этом случае пишете вы сами вместе с представителем организации, а не получаете готовым от клиента студии.
Результат: бриф, решение и реакция представителя организации
Проверяемый результат — письменный бриф с задачей и сроком, сам макет или прототип и короткая реакция представителя организации на предложенное решение, пусть даже это отказ от части идей: важен сам факт обратной связи от живого человека, а не только собственная оценка автора. Срок в несколько недель — ориентир редакции, а не норма источника.
Критерий проверки: учёт ограничений именно этой организации
Критерий оценки для кейса: видно ли в нём, что решение принято с учётом ограничений именно этой организации — аудитории, ресурсов на поддержку макета после сдачи, — а не перенесено из абстрактного шаблона. Статус проекта — «волонтёрский проект для (тип организации), без оплаты», с указанием, для кого он сделан, без придумывания результата, которого организация не подтверждала.
Третье задание: редизайн-концепт чужого продукта с открытым статусом
Третий формат — самый рискованный этически: он предполагает взять реальный продукт другой компании и переработать его визуально, а здесь легче всего подать результат так, будто это выполненный заказ этой компании. Прямого запрета на этот счёт ни один из проверенных источников не формулирует — это методическая позиция редакции, опирающаяся на совет NN/g честно обозначать нереалистичные элементы учебных проектов в описании: тот же принцип редакция распространяет на работу с чужим продуктом — статус должен быть виден сразу, а не угадываться нанимающей стороной.
С точки зрения редакционной прозрачности такой кейс нельзя подавать как заказ компании: продукт или интерфейс берётся как объект самостоятельного анализа, а в первом же предложении нужно прямо указать, что работа неофициальная и не была заказана или одобрена владельцем. Но честная пометка сама по себе не решает правовой вопрос. По ст. 1270 ГК РФ перевод или иная переработка охраняемого произведения, а также доведение произведения до всеобщего сведения относятся к способам использования, охватываемым исключительным правом. Это нормы российского права: за пределами России режим охраны авторских прав и товарных знаков может отличаться, и его стоит проверять отдельно. Применимо ли это к конкретному интерфейсу, логотипу или отдельным элементам и существует ли законное исключение, зависит от объекта и обстоятельств. Права на товарные знаки регулируются отдельно и в этой статье полноценно не разобраны. Поэтому материал не даёт универсального разрешения публиковать чужой логотип или его редизайн; практический минимум — не создавать ложного впечатления о заказе или одобрении и отдельно проверить права на используемые элементы перед публикацией.
Результат: редизайн-концепт с открытой пометкой статуса
Проверяемый результат — сам редизайн-концепт (макет, прототип или система) и пояснение в первом абзаце описания: что именно переработано, что это неофициальная работа и что компания не заказывала и не одобряла её. Само упоминание компании в описании нужно отделять от использования её логотипа или иного обозначения: правомерность такого использования зависит от конкретного контекста и прав на соответствующий объект, а эта статья не заменяет юридическую проверку.
Критерий проверки: не намекает ли текст на согласие компании
Критерий самопроверки перед публикацией: перечитайте описание кейса и отметьте каждое место, где случайный читатель может подумать, что компания в курсе этой работы или одобрила её, — и перепишите такие места прямо. Тот же принцип касается логотипа отдельно от интерфейса: право показывать в портфолио логотип, сделанный по реальному заказу, и право показывать переработку чужого уже существующего логотипа — разные вещи с разными правовыми последствиями, и разбираться в этой разнице стоит до публикации, а не после вопроса на собеседовании.
Как собрать кейс, чтобы было видно ход мысли, а не только картинку
Для всех трёх кейсов полезно сохранять один и тот же набор вопросов — контекст, роль автора, процесс, альтернативы, результат и рефлексия, — но не загонять разные проекты в одинаковый визуальный шаблон. Interaction Design Foundation описывает базовую последовательность «начало — процесс — заключение»: сначала контекст задачи и роль автора, затем путь решения и альтернативы, в конце — результат и рефлексия о том, что стоило бы сделать иначе. Финальный макет в такой логике показывает итог процесса, но формат самого кейса можно адаптировать под материал.
Похожий акцент звучит в видеоподборке Interaction Design Foundation с несколькими дизайн-руководителями и нанимающими менеджерами, среди которых на странице по имени названы креативный лид (Creative Lead) Smashing Magazine Виталий Фридман и продакт-дизайн-лид Netflix Ниваль Шейх; текст расшифровки видео на странице недоступен для чтения, поэтому в этой статье им не приписаны конкретные отдельные слова. Итоговый текстовый вывод IxDF по результатам подборки — показывать в портфолио ход мышления и быть конкретным, а не расплывчатым. Сравнение с отполированной финальной картинкой прямо формулируют другие методические статьи того же ресурса — та, что описывает структуру кейса, и та, что перечисляет типичные ошибки портфолио. Практический вывод для кейса: пишите не только «что получилось», но и какие варианты вы отклонили и почему — эта часть структуры кейса требует внимания в любом формате, не только в учебном.
Как маркировать статус проекта, чтобы не выдать его за заказ
Три статуса, использованные выше, нужны прежде всего для прозрачности: читатель кейса сразу понимает, где был учебный проект, где волонтёрская работа, а где самостоятельный редизайн-концепт. Nielsen Norman Group советует поступать так уже с готовыми учебными проектами — прямо оговаривать в описании их нереалистичные элементы, чтобы у нанимающего не сложилось впечатление, что автор просто не видит разницы с реальным проектом. Редакция предлагает раскрывать статус уже в первом предложении описания кейса, чтобы визуальная подача не создавала впечатления реального заказа до появления оговорки.
Формулировка должна быть настолько же конкретной, как и сам кейс: не «проект для тренировки», а «учебный проект, не заказ клиента, выполнен для отработки конкретного интерфейсного решения»; не «помогал организации», а «волонтёрский проект для локальной некоммерческой инициативы, без оплаты, срок — несколько недель»; не «редизайн бренда», а «редизайн-концепт для (компания): инициатива автора, без заказа и без одобрения владельца». Сами формулировки — предложение редакции, а не цитата источника: готового языка для такой маркировки ни один из проверенных материалов не даёт, хотя саму необходимость раскрывать условность учебного проекта формулирует NN/g.
Что убрать из портфолио, если оно уже собрано
Если несколько учебных проектов уже лежат в портфолио, для них есть отдельный набор проверок. Interaction Design Foundation перечисляет типичные ошибки, которые обесценивают даже сильную работу: время уходит на второстепенные детали вроде личного логотипа вместо самих кейсов; отсутствие отбора, когда в портфолио попадает всё подряд вместо кураторской подборки лучших работ; использование готового шаблона без адаптации под содержание; слабая документация процесса принятия решений; обычные технические огрехи вроде неработающей адаптивности вёрстки, проблем с доступностью или опечаток в тексте кейса.
Nielsen Norman Group и Interaction Design Foundation сходятся в соседнем совете, полезном ещё на этапе работы над проектом, а не только при чистке готового портфолио: документировать процесс по ходу дела, пока детали не забылись. IxDF формулирует это как отдельный принцип — документировать как можно больше и включать в кейс черновики, наброски, фотографии и голосовые заметки; NN/g отдельно советует сохранять любые рабочие артефакты для будущих кейсов. При этом кейсы не выигрывают от пространной прозы: нанимающие менеджеры пролистывают портфолио быстро, а не читают его подряд. Для заданий с реальным ограничением документирование по ходу работы дополнительно работает как доказательство: черновик показывает, что решение не было единственным очевидным вариантом с самого начала.
Как описывать учебные проекты в резюме отдельно от портфолио
Резюме и портфолио решают разные задачи. Nielsen Norman Group советует не заводить в резюме отдельных разделов под конкретные проекты вовсе: пройденную учебную программу и курсы там стоит описать в двух-трёх предложениях на языке навыков — какие темы изучали, какой инструментарий освоили, — а сами проекты со всеми деталями, альтернативами и статусом раскрывать в портфолио, адаптированном под неакадемического читателя, а не во внутреннем отчёте учебной программы.
Это правило работает и для трёх заданий из этой статьи: в резюме — общая строка о пройденной программе или самостоятельной практике и ключевых навыках, а не отдельный пункт про конкретный кейс с сервисом, логотипом или организацией. Полная версия — с исследованием, альтернативами, статусом проекта и рефлексией — остаётся в портфолио; нанимающая сторона, которая захочет подробностей, откроет его сама.
Практический чеклист
- В описании каждого кейса статус проекта указан в первом предложении, а не спрятан в конце текста.
- Ограничение сформулировано конкретно: уже существующая навигация и вёрстка сервиса, бюджет времени волонтёрского проекта или чужая визуальная система — не абстрактная свобода.
- В тексте кейса есть абзац минимум об одном отклонённом варианте и причине отказа от него.
- Исходное состояние сервиса или продукта зафиксировано скриншотом или другими данными до того, как в кейсе появится готовое решение.
- Ни в одном кейсе нет отзыва клиента, показателя продаж или упоминания деловых отношений с компанией, которых не было.
- Если кейс — редизайн-концепт чужого продукта или логотипа, статус описан честно в первом предложении, а формулировки нигде не намекают, что компания его заказала или одобрила; правовой риск публикации переработки чужого знака одной подписью не снимается.
- В резюме учебная программа и курсы описаны в двух-трёх предложениях на языке навыков; отдельного раздела под конкретный проект в резюме нет — подробности остаются в портфолио.
Вопросы и ответы
Можно ли показать в портфолио редизайн-концепт логотипа реальной компании без её ведома?
Однозначного «да» здесь нет. Статья 1270 ГК РФ относит переработку охраняемого произведения и доведение произведения до всеобщего сведения к способам использования, входящим в сферу исключительного права. Поэтому публикация конкретного редизайна может потребовать разрешения правообладателя или опоры на применимое законное исключение — это зависит от того, что именно переработано и охраняется ли соответствующий элемент. Отдельные права на товарные знаки здесь не анализируются. Речь идёт о нормах российского права: в других странах правила защиты авторских прав и товарных знаков могут отличаться, и их стоит проверять отдельно. В любом случае нельзя представлять работу так, будто компания её заказала или одобрила, если этого не было.
Сколько кейсов нужно, чтобы отправить портфолио на первую вакансию?
Источники называют разные, но близкие диапазоны: Nielsen Norman Group советует выбрать 3–5 проектов для подробных кейсов и подчёркивает, что само число не так важно, как разнообразие показанных навыков; Interaction Design Foundation называет ориентиром диапазон от трёх до шести кейсов. Данных о числе, которое гарантирует приглашение на собеседование, нет — ни у редакции, ни в проверенных источниках.
Нужно ли писать в резюме, что проект был неоплаченным или учебным?
По совету Nielsen Norman Group отдельных разделов под конкретные проекты в резюме заводить не стоит вовсе: курсы и учебную программу там достаточно описать в двух-трёх предложениях на языке навыков, а сами проекты со статусом, деталями и рефлексией раскрывать в портфолио. Статус — «учебный», «волонтёрский», «редизайн-концепт» — указывается именно там, а не в резюме.
Что делать, если единственный доступный волонтёрский проект не по специальности, в которой хочется работать дальше?
Interaction Design Foundation советует подбирать методы и типы кейсов под целевую роль и сочетать разные форматы в одном портфолио, а не полагаться на единственный проект. Если волонтёрский проект не по профилю, редакционный вариант — использовать его только тогда, когда в нём видны методы, полезные для целевой роли, а профиль портфолио усилить первым или третьим заданием, которые проще выбрать ближе к желаемой специализации.
Лучше сделать один подробный кейс или три коротких?
Источники говорят в пользу отбора, а не объёма: NN/g отмечает, что кейсы не выигрывают от пространной прозы, потому что их и так бегло просматривают, а при нехватке времени советует сосредоточиться на одном-двух проектах вместо распыления. Три задания из этой статьи закрывают три разных типа ограничений и рассчитаны не на распыление, а на разные навыки; если времени объективно мало, разумнее сначала довести до конца одно-два задания, чем начинать все три поверхностно.