Одна из самых частых проблем в казахстанских продуктовых командах — конфликт между PM и дизайнером. PM говорит: «Сделай красиво», дизайнер делает красиво, а потом PM говорит: «Я не это имел в виду». Три итерации, потерянная неделя, испорченные отношения.
Как правильно ставить задачу дизайнеру
- 1Не говорите «как» — говорите «зачем». Вместо «Сделай кнопку зелёной и большой» → «Нам нужно увеличить конверсию в регистрацию. Сейчас 3%, цель 8%. Пользователи не замечают кнопку — вот тепловая карта».
- 2Предоставьте контекст: персона, сценарий использования, бенчмарки конкурентов.
- 3Определите constraints: платформа, дедлайн, технические ограничения.
- 4Покажите примеры — не для копирования, а для уровня качества.
Процесс работы PM + дизайнер: Бриф (PM пишет, дизайнер уточняет) → Исследование (дизайнер изучает конкурентов, PM предоставляет данные) → Wireframes (low-fi, обсуждение структуры, не визуала) → UI-дизайн (hi-fi, 2 варианта) → Ревью (PM проверяет по AC, а не по вкусу) → Handoff (Figma → разработка). Частая ошибка: пропускать этап wireframes и сразу делать hi-fi дизайн — это дорого переделывать.
Как давать фидбэк
- 1Конкретно, а не абстрактно. «Мне не нравится» — плохо. «Кнопка CTA теряется на фоне, пользователь не видит следующий шаг» — хорошо.
- 2Привязывайте к данным и пользователям, а не к личным предпочтениям.
- 3Используйте комментарии в Figma, а не голосовые в WhatsApp — дизайнеру нужна конкретная привязка к элементу.
- 4Хвалите хорошие решения — дизайнеры тоже люди.
Визуализация ключевых концепций
Предпросмотр кода
flowchart TD
subgraph Процесс["PM + Дизайнер"]
BRIEF["1. Бриф"]
RES["2. Исследование"]
WIRE["3. Wireframes"]
UI["4. UI-дизайн"]
REV["5. Ревью"]
HAND["6. Handoff"]
end
BRIEF --> RES --> WIRE --> UI --> REV --> HAND
subgraph Пра...