Дизайн
Продуктовый дизайнер или UI-дизайнер: кого нанимать на разных этапах продукта
Вакансия «продуктовый дизайнер» и вакансия «UI-дизайнер» на практике описывают два разных набора навыков. Нанять не того — дорогая, но частая ошибка.
Коротко
UI-дизайнер отвечает на вопрос «как это должно выглядеть и вести себя», продуктовый дизайнер — на вопрос «что вообще нужно построить и зачем», включая исследование пользователей и метрики. На стадии MVP с ещё не подтверждённой гипотезой продукта нужен продуктовый дизайнер (или сам фаундер с этими навыками); на стадии масштабирования с подтверждённым продуктом и растущим объёмом экранов эффективнее нанимать UI-дизайнеров под руководством одного продуктового дизайнера или продакт-менеджера.
Два разных вопроса под одинаково звучащими вакансиями
Разница между ролями — не в уровне квалификации (один не «выше» другого), а в том, на какой вопрос каждая роль отвечает. UI-дизайнер отвечает на вопрос «как это должно выглядеть и вести себя», работая внутри уже определённых требований: экран, набор состояний, взаимодействий. Продуктовый дизайнер отвечает на вопрос до этого — «что вообще нужно построить и зачем» — и для ответа на него нужны исследование пользователей, работа с метриками и понимание бизнес-контекста, а не только визуальное и интерфейсное мастерство.
Сравнение по фокусу работы
| Аспект | Продуктовый дизайнер | UI-дизайнер |
|---|---|---|
| Главный вопрос | Что строить и зачем | Как это должно выглядеть и работать |
| Исследование пользователей | Основная часть работы | Обычно не входит в роль |
| Работа с метриками | Да — оценка эффекта решений | Как правило нет |
| Визуальное мастерство | Средний-высокий уровень | Основная, углублённая специализация |
| Типичный масштаб задачи | Продукт или крупная фича целиком | Конкретный экран или компонент |
Кого нанимать на стадии MVP
На стадии MVP, когда гипотеза продукта ещё не подтверждена реальными пользователями, найм UI-дизайнера без продуктового мышления — риск получить красиво оформленный интерфейс для функциональности, которая может оказаться никому не нужна. На этой стадии критичнее продуктовый дизайнер (или фаундер, лично закрывающий эту функцию), способный быстро тестировать гипотезы через простые прототипы, а не полировать финальный визуальный слой того, что ещё не проверено на реальном спросе.
Кого нанимать на стадии масштабирования
После того как продукт подтверждён и растёт объём экранов, фич и команд, требующих дизайна, продуктовый мышление на каждом отдельном экране становится избыточным — решение «что строить» уже принято на уровне продуктовой стратегии. На этой стадии эффективнее структура с одним продуктовым дизайнером или продакт-менеджером, определяющим направление, и несколькими UI-дизайнерами, реализующими конкретные экраны в едином, уже выстроенном видении.
Почему один человек редко хорошо закрывает обе роли на масштабе
На очень раннем этапе один человек, совмещающий обе роли, — нормальная и часто неизбежная практика: команда маленькая, продукт простой, объём работы позволяет. Проблема возникает, когда продукт растёт, а найм не меняется вслед за ним: единственный дизайнер начинает разрываться между стратегическими решениями и производством десятков экранов, и одна из двух функций неизбежно страдает — либо продукт теряет продуктовую строгость, либо визуальное качество экранов падает из-за нехватки времени на каждый.
Частые вопросы
В чём главное отличие продуктового дизайнера от UI-дизайнера?
Продуктовый дизайнер отвечает на вопрос «что строить и зачем», используя исследование пользователей и метрики. UI-дизайнер отвечает на вопрос «как это должно выглядеть и работать» внутри уже определённых требований. Это разные фокусы работы, а не разные уровни одной и той же роли.
Кого нанимать на стадии MVP?
Продуктового дизайнера, способного быстро тестировать гипотезы через простые прототипы, а не UI-дизайнера, который отполирует визуал функциональности, ещё не проверенной на реальном спросе. Риск раннего найма чистого UI-дизайнера — красиво оформленный интерфейс для того, что может оказаться никому не нужно.
Когда пора нанимать UI-дизайнеров в дополнение к продуктовому?
Когда продукт уже подтверждён и растёт объём экранов и фич, требующих дизайна. На этом этапе продуктовое мышление на каждом отдельном экране избыточно — решение «что строить» уже принято на уровне стратегии, и эффективнее структура с одним продуктовым дизайнером и несколькими UI-дизайнерами под его руководством.
Может ли один человек совмещать обе роли?
На раннем этапе — да, это нормальная и часто неизбежная практика при маленькой команде и простом продукте. Проблема возникает при росте продукта без соответствующего роста найма: единственный дизайнер начинает разрываться между стратегией и производством экранов, и одна из функций неизбежно страдает.
Нужна помощь с этой задачей?
Мы делаем это на практике, а не только пишем об этом. Опишите задачу — разберём и пришлём смету по этапам.
Услуги по теме
- UX/UI дизайн сайтов и приложенийПроектируем интерфейсы, которые доходят до продакшена: от исследования и структуры до UI-кита и передачи в разработку. Всё живёт в Figma как компоненты с реальными состояниями и брейкпоинтами, а не как папка со статичными картинками. Один и тот же процесс работает для лендинга, корпоративного сайта, интернет-магазина, веб-приложения и мобильного продукта.
- CTO на аутсорсСтартапу на ранней стадии часто не по карману штатный технический директор, но без технического голоса в решениях компания рискует выбрать не тот стек, нанять не тех людей или неверно представить продукт инвестору. CTO на аутсорс закрывает эту роль на частичной занятости — ровно в том объёме, который нужен сейчас.
Читать дальше
- UX-исследования без бюджета лаборатории: что реально даёт результатБольшинству команд не нужен отдел исследований — им нужно перестать угадывать. Разбираем методы по стоимости и отдаче, объясняем правило пяти пользователей и его важную оговорку, показываем, как превратить находки в решения без отчёта на 60 страниц.
- Дизайн-система: когда она окупается, а когда это дорогая игрушкаБольшинству команд, которые просят дизайн-систему, нужны библиотека компонентов и дисциплина именования. Разбираем, где проходит граница, как посчитать окупаемость до старта и что входит в минимальную рабочую версию.
- CTO на аутсорс: когда стартапу нужен технический директорНетехнический фаундер регулярно принимает технические решения без права на ошибку. CTO на аутсорс — не роскошь для стадии roundА, а способ не платить за эти ошибки позже.