Как продакту работать с дизайнером

Что делает дизайнер и что не делает

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

Что делает дизайнер:

• Превращает проблему пользователя в интерфейс.
• Проектирует все состояния и сценарии, включая редкие.
• Учитывает дизайн-систему и продуктовые паттерны.
• Тестирует решения с пользователями.
• Работает над визуальным языком и тональностью.

Что не делает (и не должен):

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

Когда роли понятны, общение становится сильно проще.

Хороший бриф

Бриф — это документ, с которого начинается работа. Чем лучше бриф, тем меньше итераций.

Минимум, который должен быть в брифе для дизайнера:

1. Контекст и проблема. Какая боль, у какого сегмента, почему сейчас.
2. Целевая метрика. Как поймём, что решение работает.
3. Ограничения. Технические, временные, бизнесовые. Что точно нельзя.
4. Что уже пробовали. Если до этого была версия — что в ней не работало.
5. Релевантные данные. Аналитика, исследования, юзер-тесты.
6. Открытые вопросы. Что ещё не решено и кто это решает.

Чего НЕ должно быть в брифе:

• Готовых макетов или скетчей. Это работа дизайнера. Если он попросит вашу зарисовку — окей, но не навязывайте.
• Указания «как должно выглядеть». Цвета, шрифты, расположение — не ваше дело.
• Списка из 50 требований, половина из которых противоречит друг другу.

Бриф — это про задачу и контекст. Решение — за дизайнером.

Ревью макетов

Ревью — это не «принять или отклонить», это диалог. Хорошее ревью двигает проект вперёд, плохое порождает обиды.

Структура хорошего ревью:

1. Сначала проверьте, решает ли макет задачу из брифа. Если нет — обсуждайте на этом уровне, не лезьте в детали.
2. Пройдитесь по сценариям: дефолт, error, empty, loading, граничные случаи.
3. Проверьте критичные нефункциональные требования: адаптив, локализация, доступность.
4. Только потом — детали. И то — задавайте вопросы, а не приказывайте.

Хорошие комменты:

• «Что произойдёт, если у юзера 100 элементов в списке?»
• «Я не уверен, что юзер поймёт, что эта кнопка — фильтр. Можно проверить на тесте?»
• «Тут получается два разных цвета у одного типа кнопки — это намеренно?»

Плохие комменты:

• «Не нравится, переделай.»
• «Сделай вот тут синее.»
• «Поправь отступы.»

Если ревью затягивается — назначьте встречу. На встрече с шарингом экрана 30 минут решают то, что в комментах ходит неделю.

Дизайн-система и ограничения

Дизайн-система — это библиотека готовых компонентов и правил. Хорошая дизайн-система ускоряет работу всех: дизайнер быстрее собирает экраны, разработчик быстрее имплементит, продакт быстрее видит, что в скоупе.

Что важно понимать продакту:

• Использование готового компонента — это часы. Создание нового — это недели.
• Если в макете появляется новый компонент, это должно быть осознанным решением, а не случайностью.
• Дизайн-система требует отдельного бюджета времени. Если её не поддерживать — она устаревает и перестаёт быть источником правды.
• Технические ограничения дизайн-системы (скажем, библиотека на iOS не умеет в кастомный селектор) — реальность, с которой нужно считаться.

Если дизайнер говорит «это потребует обновления дизайн-системы» — отнеситесь серьёзно. Это значит, что задача не на спринт, а на квартал.

Когда дизайнер прав, а вы нет

Бывают ситуации, когда продакт давит на решение, а дизайнер сопротивляется. В большинстве случаев — стоит послушать.

Дизайнер прав чаще всего, когда вопрос про:

• Расположение элементов на экране, иерархию.
• Тональность текста, формулировки кнопок.
• Подходит ли паттерн интерфейса для задачи.
• Восприятие пользователем.

Продакт прав чаще всего, когда вопрос про:

• Бизнес-цель и приоритеты.
• Скоуп — что в MVP, а что нет.
• Метрики успеха.
• Сегмент пользователей.

Если ловите себя на том, что навязываете дизайн-решение — стоп. Сформулируйте проблему, а не решение. «Юзеры не находят функцию» — это проблема. «Сделай кнопку красной» — это уже решение, и не ваше.

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

• Указывать дизайнеру, как рисовать. Это работа дизайнера, не ваша.
• Делать ревью без контекста брифа. Если забыли, в чём была задача — перечитайте.
• Менять задачу в середине работы. Если меняется цель — остановите работу, перепишите бриф, начните заново.
• Звать дизайнера на этап, когда «уже всё готово» и нужен только полишинг. Дизайнер — это партнёр на дискавери, а не финальный лак.
• Игнорировать его предложения по продукту. Дизайнеры много общаются с пользователями и видят паттерны, которых вы не видите.
• Не отстаивать дизайнера перед стейкхолдерами. Если CEO «хочет, чтобы кнопка была фиолетовая» — ваша задача защитить решение, если оно обосновано.
• Не давать дизайнеру времени на исследования. Хороший дизайн без понимания пользователя не получается.

Связанные темы

• Figma для продакта
• Как продакту работать с разработчиками
• Как продакту работать с QA
• Как продакту ставить задачи команде

FAQ

Нужно ли продакту уметь рисовать?

Нет. Достаточно уметь чётко формулировать задачу и читать макеты.

Что делать, если макет не нравится, но не знаю почему?

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

Кто принимает финальное решение по дизайну?

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

Как быстро дизайнер должен делать макет?

Зависит от сложности. Простая фича в дизайн-системе — день-два. Сложный новый флоу — неделя-две. Если кажется, что долго — спросите, что блокирует.

Можно ли просить дизайнера сделать «как у Apple»?

Можно как референс, но не как требование. Apple проектирует под свой контекст, у вас другой продукт и другая аудитория.

Что делать, если дизайнер не успевает?

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

---

Готовьтесь к собесу на продакта — откройте тренажёр с 1500+ вопросами по аналитике и продукту.