Бриф для продуктового дизайнера: бесплатный шаблон и 7 вопросов, которые я задаю фаундерам на первом созвоне

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

За 12 лет работы со стартапами я видела много брифов. Самые длинные редко оказываются самыми полезными. Документ на 20 страниц со списком всех фич обычно значит, что никто ещё не решил, что такое этот продукт. А полстраницы с честным разделом «этого мы не делаем» значит, что фаундер уже сделал самую трудную часть работы, и моя задача превратить это в продукт.

Вот шаблон, который я прошу заполнить.

Что должно быть в брифе на дизайн приложения?

Десять блоков. Если на какой-то вопрос ответа нет, так и пишите: «пока не знаем». Это тоже информация, и она намного полезнее уверенной догадки.

# Бриф на продуктовый дизайн

## 1. Продукт одним предложением
[Кто] с помощью [продукта] делает [что], вместо того чтобы [как сейчас].

## 2. Пользователь и его задача (job to be done)
- Основной пользователь (конкретный человек, а не «все»):
- Какую задачу он «нанимает» продукт решить:
- Чем пользуется сейчас (приложение, таблица, чат, ничем):
- Почему этого недостаточно:

## 3. Момент первой ценности
- Момент, когда пользователь впервые думает «о, это полезно»:
- Сколько шагов / минут до него сейчас:
- Что должно произойти раньше (регистрация, разрешения, данные, приглашение):

## 4. Что уже есть
- Прототип (Lovable / v0 / Cursor / другое), ссылка:
- Файлы в Figma, ссылка:
- Живое приложение (сторы, веб):
- Аналитика (какой инструмент, есть ли доступ: да/нет):
- Исследования, интервью, обращения в поддержку, отзывы:

## 5. Метрика, которая важна
- Одна цифра, по которой поймём, что дизайн сработал:
- Текущее значение (если известно):
- Цель и срок:

## 6. Ограничения
- Дедлайн и почему он жёсткий (запуск, встреча с инвестором, ревью в сторе):
- Бюджет (вилка):
- Команда (кто разрабатывает, кто решает, кто тестирует):
- Стек и платформы (iOS / Android / веб, фреймворки):
- Что нельзя менять (бренд, юридические требования, текущие пользователи):

## 7. Вне рамок проекта
- Чего НЕ будет в этой версии:
- Что сознательно откладываем на потом:

## 8. Кто принимает решения
- Кто даёт финальное «да»:
- Чьё мнение ещё важно:
- Как быстро приходит обратная связь (часы / дни):

## 9. Референсы и антиреференсы
- 2–3 продукта, которые нравятся, и чем именно:
- 2–3 продукта, на которые НЕ хотим быть похожи, и почему:

## 10. Коммуникация
- Ваш часовой пояс и рабочие часы:
- Удобный канал (Slack, Telegram, почта):
- Ритм (ежедневный асинхронный апдейт, созвон раз в неделю):

Как заполнить бриф и не утонуть в нём?

Несколько комментариев к блокам, на которых фаундеры обычно спотыкаются.

Одно предложение. Если в нём есть слова «платформа», «экосистема» или «всё в одном», перепишите. Назовите человека и действие.

Задача пользователя. Людям нужен не ваш продукт, а прогресс в какой-то части их жизни. Идея не новая, её хорошо объясняет статья Кристенсена в HBR про jobs to be done. Для брифа хватит одной честной строки: что человек пытается сделать, когда открывает ваше приложение?

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

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

Антиреференсы. «Как Linear, только теплее» мне кое-что говорит. «Не как банковское приложение и не как дейтинг» часто говорит больше.

Что подготовить перед наймом продуктового дизайнера?

Кроме брифа, соберите заранее, чтобы первая неделя ушла на решения, а не на запросы доступов:

• Ссылки на всё, что уже есть, с открытым доступом.
• Доступ к аналитике, хотя бы на чтение. Для начала подойдёт и скриншот воронки.
• 5–10 реальных цитат пользователей: отзывы, обращения в поддержку, заметки с интервью.
• Список того, что уже пробовали и бросили, и почему.
• Вилку бюджета. Если её скрыть, цена лучше не станет, зато предложение будет на неправильный объём работы.

7 вопросов, которые я задаю фаундерам на первом созвоне

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

1. Для кого продукт и чем этот человек пользуется сейчас?

Почему это важно: реальный конкурент обычно не другой стартап, а привычка, чат в WhatsApp или таблица. Дизайн должен выиграть именно у них.

Хороший ответ: «Родители детей 7–12 лет, которые сейчас звонят ребёнку по пять раз в день». Тревожный ответ: «Все, кто хочет быть продуктивнее».

2. Когда новый пользователь впервые получает пользу и как далеко это от установки?

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

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

3. Чего в продукте не будет?

Почему это важно: когда я какое-то время строила продукт с ИИ, заметила, что он ни разу не сказал «это плохая идея». Он просто делает всё. Плохое решение, сделанное хорошо, выглядит как прогресс. Кто-то должен говорить «нет», и лучше сделать это на первом созвоне, чем через месяц разработки.

Хороший ответ: конкретный список, в идеале с фичами, которые кто-то в команде очень хотел. Тревожный ответ: «Давайте сделаем всё, а пользователи выберут».

4. Что уже есть и чему это вас научило?

Почему это важно: многие фаундеры приходят с MVP, собранным за выходные в Lovable или v0. Такие прототипы часто красивые и при этом похожи друг на друга как близнецы. Это хорошее доказательство намерения и слабое техзадание. Мне важно, что вы узнали, когда показали его людям.

Хороший ответ: «Показали двенадцати пользователям, все застряли на одном и том же шаге». Тревожный ответ: «Он почти готов, надо просто сделать покрасивее».

5. По какой одной цифре мы поймём, что всё сработало?

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

Хороший ответ: «Доля новых пользователей, которые завершили настройку в первой сессии». Тревожный ответ: «Скачивания» или пять метрик сразу.

6. Что происходит, когда что-то идёт не так?

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

Хороший ответ: «Не думали об этом, можете разложить?» (честно и решаемо) Тревожный ответ: «Пользователи так делать не будут».

7. Кто говорит финальное «да» и как быстро?

Почему это важно: большинство редизайнов случается не потому, что было некрасиво. А потому, что решение так и не приняли, и человек с правом вето увидел работу слишком поздно.

Хороший ответ: «Я. Фидбек в течение суток». Тревожный ответ: «Соберём мнения инвесторов, эдвайзеров и пары друзей, потом решим».

Частые ошибки в брифах

• Список экранов вместо задачи. «Нужно 25 экранов» ничего не говорит о том, какие пять из них важны.
• «Все» в роли пользователя. Интерфейс для всех не подходит никому конкретно.
• Нет раздела «вне рамок». Объём работ растёт сам. Остановить его может только записанное «нет».
• Только референсы, без антиреференсов. Получится среднее по интернету с вашим логотипом.
• Метрика ради отчёта. Скачивания и регистрации измеряют маркетинг. Активация и удержание измеряют продукт.
• Прототип вместо ТЗ. Работающий прототип показывает, что собрали, а не что решили.
• Ни слова про тексты в интерфейсе. Одна фраза на кнопке может сдвинуть конверсию сильнее, чем перерисованный экран. Если тексты пишет «кто-то другой», укажите кто.
• Скрытый человек с правом вето. Если того, кто может зарубить работу, нет на созвоне, бриф не закончен.

Частые вопросы

Что такое бриф на дизайн приложения?

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

Какого объёма должен быть бриф для дизайнера?

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

Нужно ли указывать бюджет в брифе?

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

Нужен ли прототип до найма продуктового дизайнера?

Нет, но если он есть, покажите. Прототип из Lovable, v0 или Cursor хорошо показывает, чего вы хотите. Только не считайте его готовым дизайном: состояния, граничные случаи и логика онбординга там обычно ещё не продуманы.

Есть ли пример брифа на UX-дизайн для стартапа?

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

---

Алла Кучинская (Alla Kuchynskaya), Senior Product Designer и AI Product Designer & Builder, 12+ лет в стартапах, сильнее всего в онбординге, активации и удержании. В Findmykids (55M+ скачиваний) переделала онбординг и флоу подключения ребёнка к родителю, что помогло поднять удержание на 18%. Живёт на Бали (GMT+8), работает удалённо с командами по всему миру: частичная занятость, фултайм или проект. Портфолио: alla.studio, Telegram: @aladesigner.