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

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

2. Контекст задачи: что было в продукте до того, как вы начали работу.

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

4. Какой сегмент аудитории продукта затрагивает ваша задача.

5. Какие проблемы аудитории она решает или каких целей помогает достигать.

6. Какие технические ограничения были в работе над задачей (например, надо было максимально быстро запуститься, поэтому резали всё, что не критично).

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

8. Покажите, как рассуждали в процессе проектирования — например, как от схемы шли к макетам.

9. Если было UX-тестирование, расскажите о результатах. Что взяли в работу и как починили, а что не стали трогать и почему.

10. Покажите финальные макеты в формате было / стало.

11. Расскажите о том, как разрабатывалась задача, как вы взаимодействовали с командой разработки. Чем пришлось пожертвовать и почему.

12. Расскажите о результате внедрения, если знаете. Если не знаете, лучше так и напишите, — но не изобретайте метрики с результатом. Не стесняйтесь писать о провалах, потому что это тоже результат.

Примерно по этой же схеме можно двигаться на вайтбордах и в описании тестовых заданий.

Всем удачи в поиске классной, интересной и стабильной работы!