Как собрать портфолио (для дизайнеров и разработчиков)

Выбор того, что войдёт

1. 1Перечислите каждый проект, который могли бы показать — работа, фриланс, пет-проекты, учебные работы, хакатоны, опенсорс.
2. 2Оцените каждый по: релевантности для нужных вам вакансий, какую часть результата вы можете себе присвоить и можете ли объяснить свой конкретный вклад.
3. 3Оставьте лучшие 3–5. Уберите всё, что пришлось бы сильно оговаривать или о чём нельзя говорить из-за соглашения о неразглашении.
4. 4Убедитесь, что набор показывает разнообразие — разные типы проблем, а не пять версий одного экрана.

Структура кейса

Кейс — это короткая история с фиксированной формой. Цельтесь в то, что читатель просмотрит за две минуты и прочитает целиком за пять.

1. Обзор (2–3 предложения)
   Что за продукт, для кого, каким был проект.

2. Моя роль
   Ваша должность, команда, сроки, за что вы отвечали, а во что вносили вклад.

3. Проблема
   Проблема пользователя или бизнеса и как вы знали, что она реальна (данные, исследования, жалобы).

4. Процесс
   3–4 ключевых шага, которые вы сделали. Покажите артефакты: наброски, потоки, прототипы, эксперименты, PR.
   Включите хотя бы один компромисс или тупик и почему вы сменили направление.

5. Решение
   Итоговый результат, с визуалами или рабочей ссылкой. Прокомментируйте решения, которые имеют значение.

6. Влияние
   Цифры, если они есть (конверсия, время загрузки, успешность задач, внедрение). Если нет — качественные результаты и что бы вы измерили дальше.

7. Чему я научился(лась)
   Одно-два честных размышления.

Если вы разработчик

• Каждый проект: ссылка на живое демо и ссылка на репозиторий, обе рабочие. Сломанное демо хуже, чем отсутствие демо.
• Напишите настоящий README: что делает, скриншот или GIF, стек технологий, как запустить локально, что бы вы сделали дальше.
• Закрепите свои 4–6 лучших репозиториев в профиле GitHub и добавьте README профиля.
• Выделите сигналы качества кода: тесты, CI, понятные коммиты, разумная структура. Проверяющие действительно открывают код.
• Вклад в опенсорс считается — дайте ссылки на смёрженные PR и коротко скажите, что сделал каждый.
• Для бэкенд- или дата-ролей, где нет ничего визуального, чёткая диаграмма архитектуры и письменный разбор заменяют скриншоты.

# Название проекта
Одно предложение о том, что делает и для кого.

![demo](demo.gif)

## Почему я это создал(а)
2–3 предложения.

## Стек
Языки, фреймворки, заметные библиотеки, хостинг.

## Запуск локально
Шаги.

## Заметные решения
- Решение и его причина
- Компромисс, на который вы пошли

## Что дальше
Короткий список.

Если вы дизайнер

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

Где это размещать

• Личный сайт на собственном домене — самый сильный вариант: полный контроль, выглядит как приверженность.
• Быстро опубликовать: шаблон на конструкторе сайтов или простой статический сайт на GitHub Pages, Vercel или Netlify.
• Дизайнеры могут дополнить охват Behance или Dribbble, но настоящие кейсы держите на своём сайте.
• Разработчики: GitHub не обсуждается; сайт-портфолио — плюс.
• Всегда имейте версию одного-двух кейсов в PDF или слайдах на случай, если кто-то попросит по почте.

Частые ошибки

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

Часто задаваемые вопросы